NAT hairpin: vì sao điểm cuối VPN thất bại từ bên trong

Một máy chủ VPN trả lời từ mạng di động nhưng hỏng khi ngồi trên ghế sofa thường không phải lỗi chứng chỉ. Máy khách bên trong LAN đang yêu cầu router dịch một gói tin có đích là chính địa chỉ công cộng của router, nghĩa là gói tin phải đi ra rồi quay ngay vào. Thao tác đó gọi là hairpinning, và nhiều router hoặc không triển khai nó hoặc chỉ làm khi một hộp kiểm được bật. Chính việc bài kiểm tra từ ngoài thành công khiến mọi thứ khó hiểu, vì nó chứng minh trình lắng nghe và quy tắc chuyển tiếp đều ổn.

Gói tin đi ra và quay vào

Hãy theo dõi gói tin. Máy khách phân giải tên công cộng, kết nối tới địa chỉ công cộng, và NAT đích của router ghi lại đích thành máy chủ nội bộ. Phản hồi của máy chủ được gửi tới địa chỉ LAN của máy khách, nên nó quay về qua giao diện LAN của router mà không bao giờ đi qua quy tắc NAT lẽ ra phải dịch ngược nguồn.

Giờ máy khách nhận một gói tin từ địa chỉ mà nó chưa từng gửi gì tới, và loại bỏ nó. Chính sự bất đối xứng đó là toàn bộ lỗi.

RFC 4787 mô tả hành vi mà một NAT được kỳ vọng có trong trường hợp này, và bản ngắn gọn là trên thực tế nó là tùy chọn ngay cả ở nơi nó được quy định về lý thuyết. Một số router gọi thiết lập này là NAT loopback, số khác gọi là hairpin NAT hoặc NAT reflection, và một số không hiển thị gì cả. Một router không có nó không bị cấu hình sai; nó đang làm việc bình thường, và cách khắc phục thuộc về nơi khác. Đừng kết luận từ một bài kiểm tra nội bộ thất bại rằng quy tắc chuyển tiếp công cộng là sai.

Kiểm tra 1: thử hai đường đi riêng biệt

Từ bên ngoài LAN, kết nối bằng đúng hồ sơ mà người dùng thật sẽ dùng và xác nhận phiên được thiết lập. Từ bên trong, kết nối tới địa chỉ công cộng bằng cùng hồ sơ và ghi lại lỗi chính xác cùng thời điểm.

Một bài kiểm tra nội bộ chính xác giữ nguyên tên máy chủ và chỉ thay địa chỉ: curl -v --resolve vpn.example.com:443:203.0.113.10 https://vpn.example.com/ gửi yêu cầu tới địa chỉ công cộng trong khi vẫn trình bày đúng tên máy chủ. Điều đó tách vấn đề phân giải tên khỏi vấn đề dịch địa chỉ, vốn dễ nhầm lẫn khi cùng một tên hoạt động từ một quán cà phê. Hãy ghi nhận máy khách hỏng ở kết nối TCP hay muộn hơn ở TLS, vì cái đầu chỉ vào việc dịch địa chỉ còn cái sau chỉ vào danh tính.

Kiểm tra 2: đọc những gì máy chủ thấy

Quan sát hữu ích nhất là góc nhìn của máy chủ. Chạy một bản bắt gói trên máy chủ VPN được lọc theo địa chỉ LAN của máy khách và theo địa chỉ LAN của router, rồi lặp lại lần thử nội bộ. Nếu không có gì đến, gói tin đã không sống sót qua việc dịch.

Nếu một kết nối đến từ địa chỉ LAN của router thay vì của máy khách, hairpinning đang xảy ra và nguồn đã bị ghi lại. Đó là một cấu hình hoạt động, không phải lỗi.

Kiểm tra 3: khắc phục mà không chạm vào đường đi bên ngoài

Có ba dạng được hỗ trợ, theo bán kính ảnh hưởng tăng dần. Hẹp nhất là DNS chia tách: công bố một bản ghi nội bộ để cùng tên máy chủ phân giải thành địa chỉ nội bộ cho máy khách trong LAN, điều này tránh hoàn toàn đường đi công cộng. Tiếp theo là bật tùy chọn loopback hoặc reflection đã được ghi tài liệu của router, nếu có, và chỉ áp dụng cho dịch vụ này. Rộng nhất là một quy tắc source-NAT trên router ghi lại lưu lượng từ LAN tới máy chủ để phản hồi quay về qua router; trên một router Linux đó là quy tắc MASQUERADE trong POSTROUTING khớp với địa chỉ và cổng của máy chủ. Cả ba đều để đường đi bên ngoài không bị chạm tới, và đó là thuộc tính cần giữ.

Đừng mở rộng việc chuyển tiếp cổng không liên quan để đường đi nội bộ giống đường đi bên ngoài, và đừng chuyển dịch vụ sang cổng khác để né vấn đề. Cả hai thay đổi đều thay đổi cái mà thế giới bên ngoài có thể chạm tới để sửa một thứ chỉ thế giới bên trong nhìn thấy.

DNS chia tách có một cái bẫy đáng nêu tên. Việc thay một tên máy chủ bằng một IP tùy ý làm thay đổi cái mà máy khách xác thực, nên bản ghi nội bộ vẫn phải khớp với tên trong chứng chỉ.

Kiểm tra 4: xác minh cả hai đường đi sau đó

Lặp lại lần thử bên ngoài từ ngoài LAN, lặp lại lần thử bên trong với cùng hồ sơ, và xác nhận nhật ký máy chủ hiển thị hai phiên thành công riêng biệt chứ không phải một thành công và một im lặng. Sau đó kiểm tra rằng các máy khách khác vẫn tới được trình lắng nghe và các tuyến tới tài nguyên riêng tư không thay đổi.

Giữ bản ghi ngắn: máy khách nào dùng địa chỉ nào, máy chủ thấy gì và cách khắc phục nào trong ba cách đã được áp dụng. Các yêu cầu hairpinning của RFC 4787 là tài liệu tham chiếu cho những gì được kỳ vọng từ một NAT ở đây, và chúng giải thích vì sao một router không có tính năng này lại hành xử bình thường. Một lỗi nội bộ mà thế giới bên ngoài không thể tái tạo là một câu hỏi về dịch địa chỉ cho tới khi có chứng minh ngược lại, nên hãy kiểm tra nó như vậy.