502 khi chuyển hướng từ http sang https trên GCP

Tôi muốn bắt đầu bằng cách nói rằng tôi biết thực sự có hàng trăm chủ đề về vấn đề này mà tôi đã theo dõi trước đây để mọi thứ hoạt động hiệu quả. Tuy nhiên, cấu hình này, mà tôi đã làm việc trong nhiều tháng, không hoạt động trong một môi trường khác.

Yêu cầu khá đơn giản: Đưa người dùng từ trang trên cổng 80 đến cùng một trang trên cổng 443.

Chúng tôi đã nói trang web, với Apache ở phía trước và với các phiên bản Tomcat cho các dịch vụ thực tế của chúng tôi. Các dịch vụ này được lưu trữ trên hai máy khác nhau, một máy ảo trên GCP Compute Engine và một máy ảo khác mà cuối cùng chúng tôi sẽ loại bỏ.

Chúng tôi có miền của chúng tôi, example.com, chứa chỉ mục của các dịch vụ. Nó được phục vụ tĩnh bởi Apache 2.4. Chúng tôi có thể truy cập nó bằng Http và Https. Từ chỉ mục này, chúng tôi chuyển hướng bằng proxy_mod sang app1, app2 và app3. App2 và App3 đang ở trong máy chủ baremetal. Chúng tôi sử dụng DNS để đưa người dùng đến họ theo tên miền phụ app2.example.com/app2 và app3.example.com/app3 của họ. Tôi sẽ giải quyết sự dư thừa trong tương lai. Do một số hạn chế nhất định và thực tế là app2 và app3 chưa được công bố rộng rãi nên chúng tôi chỉ truy cập chúng bằng http.

App1 có cùng chứng chỉ SSL với máy chủ Apache khi chúng được lưu trữ trong cùng một máy ảo. Một lần nữa, chúng ta có thể truy cập cả example.com và example.com/app1 bằng Http và Https.

Bây giờ các vấn đề:

Như đã nêu trong tiêu đề, tôi gặp sự cố với lỗi 502 bất cứ khi nào tôi sử dụng cấu hình mà tôi đã thử trước đây và cấu hình đó đang hoạt động trong một môi trường khác. Cho biết cấu hình đại khái như sau:

<VirtualHost *:80>
    Redirect permanent /  https://bar.com/
</VirtualHost>
<VirtualHost *:443>
        ServerAdmin webmaster@localhost
        DocumentRoot /var/www/html
        ErrorLog ${APACHE_LOG_DIR}/error.log
        CustomLog ${APACHE_LOG_DIR}/access.log combined
 
        #SSL stuff
        SSLEngine On
        SSLCertificateFile /file.pem
        SSLCertificateKeyFile /file.key
        SSLVerifyClient none

        #Proxies
        ProxyRequests Off
        SSLProxyEngine on
        SSLProxyVerify none
        SSLProxyCheckPeerCN off
        SSLProxyCheckPeerName off
        SSLProxyCheckPeerExpire off
        ProxyPass        /api/          https://localhost:8443/api/
        ProxyPassReverse /api/          https://localhost:8443/api/
</VirtualHost>

bar.com là môi trường thử nghiệm của tôi. Mình lấy cấu hình này và tinh chỉnh như sau ví dụ.com

<VirtualHost *:80>
    Redirect permanent /  https://example.com/
</VirtualHost>

<VirtualHost *:443>
        
        ServerAdmin webmaster@localhost
        DocumentRoot /var/www/html
        ErrorLog ${APACHE_LOG_DIR}/error.log
        CustomLog ${APACHE_LOG_DIR}/access.log combined
 
        #SSL stuff
        SSLEngine On
        SSLCertificateFile      /etc/letsencrypt/live/example.com/fullchain.pem
        SSLCertificateKeyFile   /etc/letsencrypt/live/example.com/privkey.pem
        SSLVerifyClient none

        #Proxies
        SSLProxyEngine on
        SSLProxyVerify none
        SSLProxyCheckPeerCN on
        SSLProxyCheckPeerExpire on

        Redirect permanent      /app2      http://app2.example.com/app2
        Redirect permanent      /app3      http://app3.example.com/app3

        <Location /app1>
                ProxyPass               https://localhost:8443/app1
                ProxyPassReverse        https://localhost:8443/app1
        </Location>

</VirtualHost>

Nhưng điều này dẫn đến lỗi 502. Nhắc lại là hiểu vhost trên port 80 là ok. Tôi thậm chí đã đọc đó là cách được đề xuất (Hiện đang tìm nơi tôi đọc cái này). Tôi chưa thử với mod_rewrite vì tôi tin rằng lỗi không phải do cấu hình mà là sự kết hợp giữa các mod SSL và Proxy với GCP.

Về phía GCP, chúng tôi có các quy tắc tường lửa cơ bản và vì chúng tôi có thể truy cập Https hoặc Http với cấu hình cơ bản (Tức là vhost tôi có cho 443 nhưng nghe trên cổng 80, không có vhost đầu tiên). Tôi đã thiết lập bộ cân bằng tải, nhưng chủ yếu là để tận dụng CDN của Google. Nó có một nhóm phụ trợ với VM nơi lưu trữ Apache và app1. Đối với giao diện người dùng, tôi có các quy tắc cho cả cổng 80 và 443, nghĩa là tôi có một chứng chỉ SSL khác dành riêng cho bộ cân bằng tải do Google quản lý. Tôi đã thiết lập trình kiểm tra tình trạng cho cả hai cổng, vô hiệu hóa và kích hoạt các giao diện người dùng để chắc chắn rằng bản thân các cổng không phải là thứ gì đó và cho đến nay dường như đó không phải là vấn đề.

Tôi vẫn đang tìm hiểu về toàn bộ hệ sinh thái GCP, vì vậy dự đoán tốt nhất của tôi là tôi đang thiếu thứ gì đó trong phần đó của phương trình vì bản thân cấu hình Apache có vẻ phù hợp với tôi.

Những gì tôi chưa thử:

• Đã tắt bộ cân bằng, đặt VM không có IP tĩnh và thử ở đó.
• Sử dụng cùng một chứng chỉ ở giao diện người dùng và trong VM.
• Vô hiệu hóa cổng 80 ở giao diện người dùng và thiết lập Apache để nghe cổng 443 (Tôi không muốn làm điều này, vì đây là một vụ hack; bản thân cấu hình sẽ hoạt động như thể nó là http)

Tại sao tôi chưa thử những thứ này? Chà, như bạn có thể đoán, tìm hiểu về cấu hình trong máy chủ trực tiếp không thực sự là một lựa chọn. Tôi không có quyền truy cập vào bar.com vì vậy tôi không thể thử nội dung mình muốn và việc sử dụng WSL, mặc dù hữu ích nhưng chưa được chứng minh là gần với thực tế (Đây cũng có thể là thứ gì đó trên máy của tôi .). Vì tôi chỉ có thể làm việc lúc gần nửa đêm, nên tôi không thể thực sự thử nhiều thứ một cách cẩn thận như mong muốn.

Có ai biết điều gì có thể gây ra lỗi 502 không?

Nếu bạn có ý tưởng nhưng cần thêm thông tin, vui lòng tiếp tục và hỏi. Tôi sẽ trình bày chi tiết nhất có thể, nhưng hãy nhớ rằng tôi vẫn đang tìm hiểu cách thức hoạt động của IaaS.

CHỈNH SỬA:

Sau một thời gian, tôi có thể tiếp tục làm việc này. Tôi đang sử dụng cấu hình giống như mã khối thứ hai mà tôi đã đăng ban đầu.

Đáp lại @John Hanley (Xin lưu ý rằng tôi đã thay đổi tên miền và IP thành giá trị 'chung'):

sử dụng cuộn tròn -l -v vào miền, tôi nhận được như sau:

* Đang thử 1.1.1.1:80...
* Bộ TCP_NODELAY
* Đã kết nối với cổng example.com (1.1.1.1) 80 (#0)
> NHẬN / HTTP/1.1
> Máy chủ: Exampole.com
> Tác nhân người dùng: curl/7.68.0
> Chấp nhận: */*
>
* Đánh dấu gói là không hỗ trợ đa dụng
< HTTP/1.1 502 Cổng Xấu
< Loại nội dung: văn bản/html; bộ ký tự = UTF-8
< Chính sách người giới thiệu: không giới thiệu
< Độ dài nội dung: 332
< Ngày: CN, 21 tháng 11 năm 2021 08:57:31 GMT
<

<html><đầu>
<meta http-equiv="content-type" content="text/html;charset=utf-8">
<title>Lỗi máy chủ 502</title>
</head>
<body text=#000000 bgcolor=#ffffff>
<h1>Lỗi: Lỗi máy chủ</h1>
<h2>Máy chủ gặp lỗi tạm thời và không thể hoàn thành yêu cầu của bạn.<p>Vui lòng thử lại sau 30 giây.</h2>
<h2></h2>
</body></html>
* Kết nối #0 đến máy chủ example.com còn nguyên vẹn

và

* Đang thử 1.1.1.1:443...
* Bộ TCP_NODELAY
* Đã kết nối với cổng example.com (1.1.1.1) 443 (#0)
* ALPN, cung cấp h2
* ALPN, cung cấp http/1.1
* đặt thành công vị trí xác minh chứng chỉ:
* Tệp CA: /etc/ssl/certs/ca-certificates.crt
  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), bắt tay TLS, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), bắt tay TLS, Tiện ích mở rộng được mã hóa (8):
* TLSv1.3 (IN), bắt tay TLS, Chứng chỉ (11):
* TLSv1.3 (IN), bắt tay TLS, xác minh CERT (15):
* TLSv1.3 (IN), bắt tay TLS, Đã hoàn thành (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), bắt tay TLS, Đã hoàn thành (20):
* Kết nối SSL sử dụng TLSv1.3/TLS_AES_256_GCM_SHA384
* ALPN, máy chủ chấp nhận sử dụng h2
* Chứng chỉ máy chủ:
* chủ đề: CN=example.com
* ngày bắt đầu: 4 tháng 10 13:25:53 2021 GMT
* ngày hết hạn: 2 tháng 1 13:25:52 2022 GMT
* chủ đềAltName: máy chủ "example.com" khớp với "example.com" của chứng chỉ
* tổ chức phát hành: C=US; O=Google Trust Services LLC; CN=GTS CA 1D4
* Chứng chỉ SSL xác minh ok.
* Sử dụng HTTP2, máy chủ hỗ trợ đa dụng
* Trạng thái kết nối đã thay đổi (đã xác nhận HTTP/2)
* Sao chép dữ liệu HTTP/2 trong bộ đệm luồng sang bộ đệm kết nối sau khi nâng cấp: len=0
* Sử dụng ID luồng: 1 (xử lý dễ dàng 0x55b622463820)
> NHẬN / HTTP/2
> Máy chủ: example.com
> tác nhân người dùng: curl/7.68.0
> chấp nhận: */*
>
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* ID phiên SSL cũ đã cũ, đang xóa
* Trạng thái kết nối đã thay đổi (MAX_CONCURRENT_STREAMS == 100)!
< HTTP/2 502
< kiểu nội dung: văn bản/html; bộ ký tự = UTF-8
< chính sách giới thiệu: không giới thiệu
< độ dài nội dung: 332
< ngày: CN, 21 tháng 11 năm 2021 08:57:56 GMT
< alt-svc: xóa
<

<html><đầu>
<meta http-equiv="content-type" content="text/html;charset=utf-8">
<title>Lỗi máy chủ 502</title>
</head>
<body text=#000000 bgcolor=#ffffff>
<h1>Lỗi: Lỗi máy chủ</h1>
<h2>Máy chủ gặp lỗi tạm thời và không thể hoàn thành yêu cầu của bạn.<p>Vui lòng thử lại sau 30 giây.</h2>
<h2></h2>
</body></html>
* Kết nối #0 đến máy chủ example.com còn nguyên vẹn

Tôi nghĩ rằng yêu cầu https không thành công ở đây do thiếu tiêu đề, vì tôi có thể truy cập trang web trên trình duyệt của mình. Từ đây, tôi thấy rằng yêu cầu đang được LoadBalancer xử lý đúng cách (Hoặc ít nhất đó là những gì tôi hiểu), nhưng điều đó Giai đoạn kết nối đã thay đổi tin nhắn đang làm phiền tôi, ĐẶC BIỆT vì phải mất vài giây ở đó, như thể đang chờ phản hồi.

Từ apachectl -S

Cấu hình máy chủ ảo:
*:80 vm-name.region.gcp-project.internal (/etc/apache2/sites-enabled/0080-default.conf:1)
*:443 example.com (/etc/apache2/sites-enabled/0443-secured.conf:6)
ServerRoot: "/etc/Apache2"
Tài liệu chínhRoot: "/var/www/html"
Nhật ký lỗi chính: "/var/log/apache2/error.log"
Mutex watchdog-callback: using_defaults
Mutex ssl-stapling-refresh: using_defaults
Mutex ssl-stapling: using_defaults
Mutex proxy: using_defaults
Mutex ssl-cache: using_defaults
Mutex mặc định: dir="/var/run/apache2/"cơ chế=mặc định 
PidFile: "/var/run/apache2/apache2.pid"
Xác định: DUMP_VHOSTS
Xác định: DUMP_RUN_CFG
Người dùng: name="www-data" id=33
Nhóm: name="www-data" id=33

Điều này là thú vị. Trong khi Vhost cho cổng 80 tham chiếu đến phiên bản VM của chính GCP, Vhost cho cổng 443 thì không. Tôi không chắc phải lấy cái gì từ cái này... Tôi đã thử truy cập VM bằng IP bên ngoài của nó với curl. Http hiển thị trạng thái phù hợp cho chuyển hướng vĩnh viễn, trong khi HTTP gây ra lỗi do CN và SAN không khớp (Điều này có ý nghĩa vì chứng chỉ dành cho miền chứ không phải IP). Với điều này, tôi phần nào chắc chắn rằng việc thay đổi IP máy ảo thành IP tĩnh mà chúng tôi có và để Apache thực hiện cân bằng tải sẽ đáp ứng yêu cầu của tôi, nhưng chúng tôi sẽ thêm ít nhất một máy ảo nữa trong tương lai gần, vì vậy hãy làm điều đó tại điểm này có vẻ ... xấu. Tôi vẫn nghĩ rằng CDN là một tính năng tốt và nên sử dụng nó sau tất cả.

Giới thiệu về Cân bằng tải:

Điều này hơi khó giải thích, vì vậy tôi sẽ cố gắng trình bày chi tiết nhưng trực tiếp nhất có thể (Có điều gì đó trong GCP CLI để hiển thị cấu hình này không? Chưa sử dụng CLI):

Bản thân bộ cân bằng tải:

Giao diện người dùng:

phụ trợ |Giao thức endpoind|Cổng được đặt tên|Hết giờ|kiểm tra tình trạng| |-|-|-|-| |HTTP|http|30 giây| hc-1 (Không đạt)| |HTTP/2|https|30 giây| hc-2 (Đi qua)|

* Cả hai phần phụ trợ đều trỏ đến cùng một nhóm, nhưng các cổng khác nhau. Nhóm này chứa VM duy nhất của chúng tôi.

Quy tắc máy chủ/đường dẫn:

Tất cả không được sửa đổi chuyển đến phụ trợ HTTP.Yêu cầu /* chuyển đến chương trình phụ trợ HTTPS.

Trong khi hc-1 không thành công, nó thực sự chuyển sang trang chính. Nhưng khi tôi cố gắng truy cập app1 thì không thành công (Điều này hợp lý vì Vhost không chứa ánh xạ proxy tới app1 để bắt đầu). Mặt khác, hc-2 vượt qua, nhưng truy cập trang web dưới dạng https://example.com ném 502 lỗi.

Cuối cùng, liên quan đến cách tôi kích hoạt các trang web, tôi đã sử dụng a2ensite cho 0080-default.conf và 0443-secured.conf.

Ồ, và ngoài ra, tuần này trang web của chúng tôi không hoạt động. Tôi nghĩ đó là vào thứ Ba, cùng ngày Spotify gặp sự cố. Tôi đã phải mở bộ cân bằng tải, thực hiện bất kỳ thay đổi nào, lưu, hoàn tác thay đổi đã nói và lưu lại để nó hoạt động trở lại, nhưng hc-1 đã bị lỗi kể từ đó.

Tôi đã thử nhiều hoán vị cấu hình của mình, bắt đầu từ cấu hình mà tôi biết là hoạt động (Tức là, chỉ một bộ cân bằng tải cho HTTP và một Vhost trên cổng 80).