Một máy chủ công khai cho VPN và web: cách chia vai trò

Một máy duy nhất có thể đáp ứng cả ba nhu cầu cùng lúc: kết thúc đường hầm, trả lời HTTPS và chuyển tiếp giữa hai mạng LAN riêng. Việc đó có hợp lý hay không phụ thuộc vào ba điều bạn có thể quyết trên giấy: ai sở hữu địa chỉ công khai, ai sở hữu từng cặp cổng và giao thức, và tiến trình nào được phép chuyển tiếp gói tin. Nếu đúng, máy chủ dùng chung không có gì đặc biệt. Nếu sai, bạn sẽ mất cả cuối tuần với một dịch vụ khởi động sạch sẽ và không bao giờ trả lời.

Phần tiếp theo là một quy trình quyết định, không phải bản vẽ thi công. Mỗi bước kết thúc bằng kiểm tra chứng minh vai trò vừa thêm thực sự được cô lập.

Chọn chủ sở hữu địa chỉ trước khi chọn cổng

Điểm cuối của đường hầm và một máy chủ web có thể dùng chung một nhân; dùng chung một địa chỉ, cổng và giao thức cùng lúc là điều thất bại. WireGuard thường dùng UDP 51820, OpenVPN dùng UDP 1194 hoặc TCP 443, còn máy chủ web dùng TCP 443. Cặp gây đau là OpenVPN trên TCP 443 bên cạnh HTTPS, vì cả hai đều muốn cùng một socket và nhân trao nó cho bên liên kết trước. Chỉ một bộ phân kênh phía trước, như sslh hay proxy hiểu TLS, mới cho phép chúng dùng chung cổng đó, và nó thêm một thành phần mà khi hỏng trông giống hệt sự cố tường lửa.

Hãy xem chủ sở hữu trước khi thay đổi bất cứ điều gì: ss -lntup in ra địa chỉ cục bộ, cổng và tiến trình của mọi socket đang lắng nghe. Hai dòng hiển thị 0.0.0.0:443 nghĩa là dịch vụ thứ hai chưa bao giờ liên kết, dù script init của nó vui vẻ đến đâu. Cầu nối cũng di chuyển chủ sở hữu. Khi eth0 tham gia br0, IP chuyển sang br0 và mọi quy tắc tường lửa nêu tên eth0 không còn khớp nữa, vì vậy hãy liên kết dịch vụ trên cầu và xác nhận bằng ip -br addr.

Cùng quy tắc sở hữu đó giải thích một điều bất ngờ xuất hiện với máy ảo. Máy chủ đường hầm chạy trong một khách trên cùng LAN giữ địa chỉ của khách, nên các kết nối nhắm tới địa chỉ của chính máy chủ vẫn ở lại máy chủ và đường hầm của khách không bao giờ thấy chúng, bất kể hồ sơ máy khách nói gì.

Định tuyến giữa hai LAN hoặc NAT một phía

Hai mạng LAN không thấy nhau đều có thể gọi máy chủ công khai, máy này sau đó chuyển tiếp giữa các đường hầm. Thiết kế định tuyến đó cần ba thứ: bật chuyển tiếp, tuyến đường tới từng tiền tố từ xa và chính sách chuyển tiếp cho phép lưu lượng đi qua. sysctl -w net.ipv4.ip_forward=1 bao gồm điều thứ nhất, ip route add 10.20.0.0/24 dev wg1 điều thứ hai, và một dòng nftables như nft add rule inet filter forward iifname "wg0" oifname "wg1" accept điều thứ ba.

NAT nguồn dễ thêm hơn và khó gỡ lỗi hơn. Masquerading viết lại địa chỉ máy khách, nên phía xa thấy hub thay vì máy chủ thật, và các quy tắc truy cập cùng nhật ký của nó không còn hữu ích cho việc quy nguồn. Khi cả hai mạng là của bạn, hãy định tuyến. Khi một phía thuộc bên thứ ba không thêm tuyến quay lại, NAT là lựa chọn có thể giao tuần này. Dù thế nào, hãy viết kế hoạch địa chỉ, vì hai dải /24 chồng lấn không thể định tuyến bằng bất kỳ cấu hình nào.

Không có gì trong việc chiếc máy đóng vai trò cửa ra internet cho laptop ngăn chính chiếc máy đó kết thúc các đường hầm đi vào. Chỉ địa chỉ chồng lấn mới ngăn được, và đó là lý do kế hoạch địa chỉ là tài liệu quan trọng.

Kiểm tra việc chia tách khi hai vai trò đã dừng

Phép thử hữu ích là phép trừ: dừng hai vai trò và xác nhận vai trò thứ ba vẫn trả lời. Yêu cầu web phải hoàn tất khi dịch vụ đường hầm tắt, và bắt tay đường hầm phải hoàn tất khi máy chủ web đã dừng. Nếu cả hai chỉ hoạt động khi mọi thứ chạy, bạn có phụ thuộc ngoài ý muốn, như bảng tường lửa dùng chung, tuyến đường lạc hoặc tên trỏ sai địa chỉ.

Ba lệnh làm phép thử đó cụ thể. curl -sk --resolve example.test:443:203.0.113.10 https://example.test/ chứng minh trình lắng nghe cục bộ trả lời mà không cần DNS ngoài, wg show trên máy khách chứng minh bắt tay đã hoàn tất, và tcpdump -ni any port 51820 trên hub tách sự cố định tuyến khỏi sự cố khóa. Một cuộc bắt tay không bao giờ xuất hiện trong bản ghi đã chết trước máy chủ: tường lửa nhà cung cấp, địa chỉ công khai sai hoặc quy tắc NAT trên đường.

Lặp lại phép trừ cho các LAN được chuyển tiếp. Khi một peer bị ngắt, ping qua hub phải thất bại; khi nối lại, ping phải phục hồi mà không chạm vào quy tắc nào. Ping chỉ phục hồi sau khi khởi động lại đường hầm là chỉ vào chính sách chứ không phải khả năng tiếp cận, và đó là một cách sửa khác.

Giữ bộ quy tắc dễ đọc trong khi bạn bớt vai trò. nft list ruleset nên hiển thị một quy tắc chấp nhận cho mỗi hướng bạn thực sự cần, và chuỗi chuyển tiếp chấp nhận mọi thứ không phải là tách biệt, đó là bản demo đang chạy.

Đường truy cập chỉ IPv6 và dịch vụ IPv4

Một số đường truy cập chỉ cấp khả năng tiếp cận IPv6, và dịch vụ vẫn phải được công bố qua IPv4. Bản thân đường hầm đi qua họ giao thức còn truyền lưu lượng, trong khi dịch vụ đã công bố nằm trên một địa chỉ bên trong đường hầm. Điều này đảo ngược giả định thông thường và âm thầm phá vỡ giám sát: một quy tắc tường lửa hay kiểm tra thời gian hoạt động viết cho đường IPv4 giờ canh một giao diện không mang gì.

Kiểm tra từng họ riêng với curl -4 và curl -6, vì một yêu cầu thành công không nói gì về con đường bạn chưa thử. Quyền sở hữu cổng không đổi giữa các họ, nhưng trình lắng nghe thì đổi: ss -lntup liệt kê socket IPv4 và IPv6 thành các dòng riêng, và 0.0.0.0:443 không bao phủ [::]:443 trừ khi tiến trình yêu cầu socket dual-stack.

Dịch vụ trả lời trên một họ và từ chối trên họ kia thường là sự cố trình lắng nghe, không phải định tuyến. Trước khi tuyên bố thiết kế hoàn tất, hãy xác nhận mỗi vai trò có địa chỉ hoặc cổng riêng, việc chuyển tiếp được bật và cho phép, và mỗi vai trò vẫn trả lời khi hai vai trò kia đã dừng.