NAT ở máy chủ VPN hay ở bộ định tuyến? Cả hai đều có thể hoạt động

Đánh dấu một kết nối là tuyến mặc định trên máy tính xách tay là bước mà mọi người nhớ, và cũng chính là bước không thay đổi gì trên cổng kết nối. Máy khách giờ gửi các yêu cầu Internet vào đường hầm; liệu chúng có ra khỏi tòa nhà hay không phụ thuộc vào việc chuyển tiếp, một điểm dịch và một đường quay về chạm tới địa chỉ riêng của máy khách. Hai cách bố trí có thể cung cấp cả ba, chúng đặt công việc ở những nơi khác nhau, và cả hai đều thất bại theo cùng một cách âm thầm khi không ai sở hữu hướng trả lời. Chọn giữa chúng là câu hỏi ai nên nhìn thấy nhóm máy khách.

Lầm tưởng: tuyến của máy khách tạo ra lối ra

Đường hầm cưỡng bức là một chính sách phía máy khách: nó quyết định rằng lưu lượng đi tới bộ điều hợp VPN thay vì bộ điều hợp vật lý. Tài liệu định tuyến VPN của Microsoft mô tả sự tách đó và hành vi cưỡng bức, và đó là một phát biểu về bảng tuyến của máy khách, không phải về các quy tắc chuyển tiếp của máy chủ. Từ góc nhìn của máy khách, đường hầm là nơi Internet trú ngụ; từ góc nhìn của cổng kết nối, một gói tin đến từ một địa chỉ mà không ai ở phía trên từng nghe nói tới. Không bên nào bị cấu hình sai khi đứng riêng, và đó là lý do sự cố trông giống một máy chủ hỏng với người ngồi trước máy tính xách tay.

Sự không khớp đó là toàn bộ vấn đề mà phần còn lại của bài viết giải quyết. Một cái gì đó phải làm cho địa chỉ riêng của máy khách có thể quay về được, và lựa chọn là ở đâu.

Hãy vẽ đường quay về trước

Viết ra tuyến với địa chỉ thật trước khi chạm vào bất kỳ cài đặt nào, và đánh dấu hai điểm dịch có thể có trên đó. Phòng thí nghiệm này dùng một nhóm VPN 10.70.0.0/24 với một máy khách tại 10.70.0.37, địa chỉ LAN của máy chủ 172.16.40.10, một bộ định tuyến tại 172.16.40.1 và một lối ra công cộng 203.0.113.40.

client 10.70.0.37 -- tunnel --> RRAS 172.16.40.10 -- LAN --> router 172.16.40.1 --> 203.0.113.40
                                  (translate here?)                             (or here?)

Máy chủ vốn đã duyệt Internet chỉ chứng minh tuyến của chính nó. Một gói tin được chuyển tiếp thay cho máy khách là một quyết định khác, do chính sách chuyển tiếp trên cùng máy đưa ra, và đó thường là thứ còn thiếu. Đánh dấu ba điểm quyết định trên sơ đồ giữ cuộc trò chuyện về từng điểm một.

Phương án A: dịch trên máy chủ VPN

Ở đây máy chủ dịch nguồn của máy khách sang địa chỉ LAN của chính nó trước khi giao gói tin cho bộ định tuyến, và bộ định tuyến áp dụng cách dịch thông thường của nó khi ra ngoài. Trên gói trả lời, ánh xạ của bộ định tuyến khôi phục địa chỉ máy chủ và ánh xạ của máy chủ khôi phục địa chỉ máy khách. Hai lần dịch có trạng thái nối tiếp là bình thường và khả thi, miễn là cả hai đều được ghi lại; bộ định tuyến không bao giờ cần tuyến tới nhóm, và đó là điểm hấp dẫn của cách bố trí này.

Get-RemoteAccess | Select-Object VpnS2SInterface, RoutingDomain
Get-NetNat | Select-Object Name, InternalIPInterfaceAddressPrefix

Hãy dùng các lần đọc này để xem máy chủ đã có gì thay vì giả định rằng có NAT. Một quy tắc masquerade của Linux sao chép từ blog không phải là cấu hình Windows, và một sự cho phép trong tường lửa của máy chủ cho trình lắng nghe VPN không phải là cùng một chính sách với sự cho phép chuyển tiếp yêu cầu của máy khách. Xác nhận vai trò chuyển tiếp của máy chủ từ giao diện quản trị của chính nó, rồi xem phần dịch riêng ra, vì hai thứ đó thường được bật bởi những phần khác nhau của một lần triển khai.

Phương án B: mang nhóm tới bộ định tuyến

Trong cách bố trí thứ hai, máy chủ chuyển tiếp địa chỉ nguồn thật của máy khách, và bộ định tuyến dịch địa chỉ đó. Điều này giữ nhóm máy khách hiển thị ở biên, hữu ích nếu bộ định tuyến là nơi chứa chính sách lưu lượng, ghi nhật ký hoặc kiểm tra. Nó cũng có nghĩa là bộ định tuyến cần một tuyến quay về cho 10.70.0.0/24 trỏ tới 172.16.40.10, cùng với một chính sách Internet thực sự bao gồm tiền tố đó; một quy tắc viết cho mạng con LAN không âm thầm mở rộng tới nhóm.

Chọn cách này khi thiết bị biên là chủ sở hữu chính sách dự định và có thể chấp nhận thêm một tiền tố trong bảng định tuyến và bảng dịch của nó. Chọn cách dịch phía máy chủ khi nhóm cần vô hình ở phía trên và bộ định tuyến không do cùng một nhóm quản trị. Không phương án nào được gợi ý bởi bất kỳ hộp kiểm nào trên máy khách, và không phương án nào an toàn hơn nói chung; chúng đặt tính hiển thị và việc bảo trì ở những nơi khác nhau.

Làm rõ DNS, IPv6 và việc chấp nhận

Việc dịch địa chỉ không sửa được phân giải tên. Máy khách có thể dùng một trình phân giải được cung cấp cùng hồ sơ VPN, một trình phân giải riêng cho những không gian tên cụ thể, hoặc một trình phân giải công cộng đã được phê duyệt, và một trình phân giải không thể chạm tới dưới chính sách đó sẽ tiếp tục thất bại sau khi định tuyến hoạt động. Hãy kiểm tra tên và địa chỉ riêng ra để hai lỗi không bao giờ hòa vào một báo cáo.

IPv6 cần một đoạn riêng trong thiết kế. Một cách dịch IPv4 đang hoạt động không nói gì về việc các máy khách IPv6 có tuyến, có nguồn công cộng hợp lệ hay có chính sách chặn chúng khi đường hầm sụp hay không. Để điều đó không được nói ra nghĩa là một nửa số máy khách âm thầm đi vòng qua cổng kết nối trong khi nửa còn lại hoạt động.

Để chấp nhận, hãy theo dõi một yêu cầu máy khách được phép và câu trả lời của nó qua cả hai ranh giới, và ghi lại địa chỉ mà mỗi ranh giới phải thấy tại thời điểm đó. Chính bản ghi đó biến lần thay đổi nhóm tiếp theo thành một chỉnh sửa năm phút thay vì một cuộc tranh cãi về việc ai sở hữu tuyến quay về bị thiếu. Hãy giữ bản ghi cùng hồ sơ máy khách thay vì trong một phiếu, vì hồ sơ là thứ kỹ sư tiếp theo sẽ tìm thấy trước.