NAT kép và VPN của bạn: máy khách chạy được, máy chủ thì không

Bộ định tuyến của bạn nằm sau một bộ định tuyến khác, địa chỉ WAN là riêng tư, vậy mà máy khách VPN vẫn kết nối. Sự kết hợp đó khiến những người mong NAT kép phá vỡ đường hầm phải ngạc nhiên, nhưng chính các kết nối đi ra là thứ mà việc dịch địa chỉ xử lý tốt nhất. Lưu trữ máy chủ VPN sau cùng hai lớp đó là trường hợp thường thất bại. Hãy vẽ hướng của kết nối trước khi bạn thay đổi bất cứ điều gì.

Trước tiên hãy vẽ hướng của kết nối

Mở trang trạng thái của bộ định tuyến bên trong và ghi lại địa chỉ WAN của nó, sau đó so sánh với địa chỉ mà một dịch vụ công khai báo cho bạn. Nếu hai địa chỉ khác nhau, có ít nhất một bộ dịch nằm giữa bộ định tuyến của bạn và internet. Nếu địa chỉ WAN nằm trong 100.64.0.0/10, bộ dịch bên ngoài nhiều khả năng thuộc nhà cung cấp của bạn, và bạn không kiểm soát nó. Hai sự thật này quyết định bước nào trong các bước sau có thể hoạt động.

curl -s https://ifconfig.me
ip -brief address
traceroute -n 1.1.1.1

NAT kép không phải VPN kép. Việc dịch địa chỉ viết lại địa chỉ và cổng; nó không thêm một đường hầm mã hóa thứ hai và không mã hóa bất cứ thứ gì. Giữ tách biệt hai ý tưởng này rất quan trọng vì các giải pháp hoàn toàn khác nhau, và một trong số đó cần trao đổi với nhà cung cấp thay vì một trang cài đặt.

Đi ra: máy khách hỏi, các bộ dịch ánh xạ

Một đường hầm đi ra bắt đầu bằng gói tin từ máy của bạn, nên mỗi bộ dịch có thể tạo một ánh xạ và cho phản hồi quay vào. Giao thức, cổng và bộ đếm thời gian nhàn rỗi quyết định ánh xạ đó có tồn tại đủ lâu để hữu ích hay không. Hầu hết bộ định tuyến tiêu dùng xử lý việc này mà không cần cấu hình gì.

Những lỗi thực sự xuất hiện thường liên quan đến thời gian chờ và hỗ trợ giao thức, không phải số lượng bộ định tuyến. Một đường hầm rớt sau vài phút im lặng là một ánh xạ đang hết hạn, và keepalive là câu trả lời tiêu chuẩn. IPsec có các phần mở rộng NAT-traversal tiêu chuẩn, nên khẳng định nó không thể đi qua việc dịch địa chỉ là hoàn toàn sai. Nếu đường hầm không hề được thiết lập, hãy xem điểm cuối và thông tin đăng nhập trước khi đổ lỗi cho cấu trúc mạng.

wg show
ping -c3 10.8.0.1

Hãy dừng lại nếu đường hầm đi ra hoạt động từ mạng này mà không từ mạng khác. So sánh đó là về các mạng, không phải về số lượng bộ định tuyến.

Đi vào: chuyển tiếp chỉ bao phủ thiết bị bạn sở hữu

Lưu trữ máy chủ là hướng ngược lại: một kết nối mới đến từ internet và phải tới được máy của bạn qua từng lớp. Một quy tắc chuyển tiếp cổng trên bộ định tuyến bên trong chỉ hữu ích nếu bộ dịch bên ngoài cũng chuyển lưu lượng đó đến bạn. Việc lặp lại quy tắc cục bộ không cho bạn quyền kiểm soát thiết bị của nhà cung cấp.

nc -vz 203.0.113.10 51820
ss -lunp 'sport = :51820'

So sánh địa chỉ WAN của bộ định tuyến bên trong với địa chỉ công khai bạn đã quan sát, và ghi lại nguồn gốc của từng giá trị. Nếu địa chỉ WAN là riêng tư hoặc nằm trong dải dùng chung, lớp ngoài đang thực hiện việc dịch mà bạn không thể cấu hình. Hãy hỏi nhà cung cấp xem họ hỗ trợ khả năng tiếp cận vào nào trước khi bạn dành cả buổi tối cho những quy tắc không thể có hiệu lực. Gỡ bỏ bộ định tuyến hay tắt tường lửa một cách rộng rãi không phải là chẩn đoán, và đó là một sự đánh đổi tồi cho một cổng mở.

Hãy dừng lại nếu lớp ngoài thuộc nhà cung cấp và nó không chuyển tiếp. Khi đó các câu trả lời được hỗ trợ là một phương thức truy cập khác hoặc một bộ chuyển tiếp, không phải thêm một quy tắc phía bạn.

Hãy thử một biến mỗi lần

Thay đổi một thứ mỗi lần thử và ghi lại kết quả, vì một đường đi NAT kép có nhiều biến hơn đường đi một bộ định tuyến. Giữ nguyên hồ sơ và thiết bị, sau đó so sánh với một mạng truy cập khác. Ghi nhận xem thương lượng có thất bại không, phiên có rớt sau khi nhàn rỗi không, hay chỉ các đích riêng tư thất bại. Ba quan sát đó chỉ ra ba lớp khác nhau.

journalctl -u wg-quick@wg0 -n 30 --no-pager
ip route get 10.20.30.40

Các mạng con riêng tư chồng lấn là một cái bẫy riêng mà không lượng dịch địa chỉ nào sửa được. Nếu mạng nhà bạn và mạng từ xa dùng cùng một dải, xung đột tuyến sẽ xuất hiện bất kể có bao nhiêu bộ dịch ở giữa. Đánh số lại một bên là câu trả lời bền vững duy nhất.

Cổng từ xa cũng đáng được quan tâm như vậy, vì các quy tắc chuyển tiếp và tuyến quay về của nó có thể là mảnh còn thiếu. Một đường hầm đã xác thực vẫn có thể không có đường dẫn ứng dụng dùng được, và lỗi đó trông giống hệt từ phía máy khách. Cuộc dạo chơi kết thúc khi bạn có thể nói hướng nào thất bại và lớp nào chịu trách nhiệm.