L2TP/IPsec qua NAT: điều gì thực sự hỏng và tại sao

Khẳng định NAT làm hỏng L2TP/IPsec chỉ đúng một nửa và vì thế vô dụng. Dịch địa chỉ là bình thường, traversal NAT tồn tại chính là để sống sót qua nó, và hàng triệu máy khách kết nối mỗi ngày từ sau một bộ định tuyến. Thứ hỏng là một giai đoạn cụ thể của một trao đổi cụ thể: IKE không bao giờ nhận được trả lời, đường hầm đã đóng gói bị chính sách chỉ cho phép một giao thức loại bỏ, hoặc ánh xạ dịch hết hạn trong khi đường hầm không hoạt động. Khi biết mình đang ở giai đoạn nào, cách sửa thường là một quy tắc hoặc một keepalive, không phải thiết kế VPN mới.

Huyền thoại chính là câu hỏi sai

Câu hỏi hữu ích không phải «NAT có làm hỏng cái này không» mà là «phần nào của trao đổi đang được dịch, và thiết bị dịch làm gì với nó». L2TP/IPsec là giao thức phân tầng: IKE thương lượng, ESP bảo vệ, và L2TP mang PPP bên trong lớp bảo vệ đó. Dịch địa chỉ tác động khác nhau lên từng tầng, và có thể phân biệt dấu hiệu hỏng nếu nhìn vào giai đoạn thương lượng thay vì hộp thoại lỗi.

Một bộ định tuyến duyệt web thành công chỉ chứng minh TCP với dịch cổng nguồn hoạt động. Nó không nói gì về UDP 500, UDP 4500 hay giao thức 50, và chính ba thứ đó là thứ mà triển khai này phụ thuộc vào.

Giai đoạn 1: IKE phải nhận được câu trả lời

Trao đổi đầu tiên đi tới bên trả lời trên UDP 500. Nếu không có câu trả lời nào quay lại, mọi thứ khác không quan trọng: khóa chia sẻ trước, đề xuất và thông tin đăng nhập đều chưa được đọc. Hãy quan sát yêu cầu và câu trả lời thay vì suy đoán từ thời gian chờ của máy khách:

sudo tcpdump -n -i any 'udp port 500 or udp port 4500 or proto 50'
swanctl --list-sas

Yêu cầu không có trả lời thường có nghĩa là tường lửa hoặc nhà mạng phía trên đang bỏ gói, chứ không phải máy chủ từ chối nó. Câu trả lời có tải thông báo nêu tên đề xuất hoặc vấn đề chứng chỉ nghĩa là các gói đã đến và thương lượng thất bại vì nội dung, đây là một cách sửa hoàn toàn khác.

Khi cả hai bên ở sau lớp dịch, bên khởi tạo chỉ cần tới được bên trả lời, nên hầu hết triển khai phía máy khách hoạt động từ giai đoạn 1. Lưu trữ phía máy chủ là nơi vấn đề đầu vào bắt đầu, và đó là lý do hai tình huống này không bao giờ nên được bàn như một.

Giai đoạn 2: đóng gói thay đổi điều tường lửa nhìn thấy

ESP là một giao thức IP, không phải cổng TCP hay UDP, và việc dịch địa chỉ cổng thông thường không có trường cổng để ghi lại. Vì thế traversal NAT chuyển tải được bảo vệ vào trong UDP 4500: việc đóng gói cho thiết bị dịch thứ mà nó biết cách dịch. Khi điều đó xảy ra, một quy tắc tường lửa chỉ viết cho UDP 500 sẽ cho phép thương lượng và bỏ đường hầm, tạo ra kết quả khó hiểu khi nhật ký cho thấy giai đoạn 1 thành công và không có lưu lượng.

Bản thân trao đổi IKE cũng có thể chuyển sang UDP 4500 sau khi phát hiện NAT, điều này khiến những người chỉ mở 500 bất ngờ. Hãy cho phép cả hai cổng theo cả hai chiều trên đường đi, và nhớ rằng tường lửa có trạng thái chỉ giữ luồng chừng nào còn thấy lưu lượng.

Giao thức 50 vẫn quan trọng trên các đường không có dịch, và trên các đường mà hộp trung gian được cấu hình cho phép nó. Nếu bạn chẩn đoán bằng cách loại trừ, hãy tắt giả thuyết thay vì thêm quy tắc hàng loạt: cho phép 500, 4500 và ESP, xác nhận đường hầm dựng lên, rồi gỡ bỏ những gì hóa ra không cần thiết. Một quy tắc không ai giải thích được là quy tắc không ai sẽ gỡ khi nó trở thành nguyên nhân của sự cố tiếp theo. Hãy ghi việc thu hẹp vào nhật ký thay đổi cùng với giai đoạn mà nó đã sửa, để kỹ sư tiếp theo bắt đầu từ bằng chứng của bạn chứ không phải từ cùng một quy tắc ngón tay cái.

Giai đoạn 3: ánh xạ hết hạn và đường hầm chết

Thiết bị dịch lưu trạng thái cho các luồng nó chuyển tiếp, và trạng thái đó có thời hạn. Đường hầm L2TP/IPsec mang ít lưu lượng khi không ai dùng, nên một đường hầm không hoạt động có thể sống lâu hơn ánh xạ của nó và ngừng nhận lưu lượng quay về. Máy khách vẫn tin mình đang kết nối, máy chủ không thấy gì, và triệu chứng đầu tiên thường là hết thời gian chờ của ứng dụng chứ không phải lỗi VPN.

Phát hiện đối tác chết và keepalive NAT tồn tại vì việc này, và cả hai đầu phải sẵn sàng gửi chúng. Nếu máy chủ của bạn ở sau lớp dịch, yêu cầu phía Windows là một thiết lập registry được ghi chép giúp máy chủ giả định đóng gói UDP cho các gói đi ra của chính nó; nếu không có, bên trả lời gửi ESP mà thiết bị dịch không thể ánh xạ ngược. Đây là vấn đề cấu hình máy chủ, không phải máy khách.

Thay đổi địa chỉ WAN tạo ra cùng kết quả từ hướng khác: ánh xạ được dựng lại quanh địa chỉ mới, và hiệp hội bảo mật cũ giờ trỏ tới một bộ giá trị không còn tồn tại. Hành vi kết nối lại thuộc về cách triển khai máy khách, và đó là lý do «kết nối lại sau khi khởi động lại bộ định tuyến» chạy trên một máy khách và cần nút gạt tay trên máy khác.

Lưu trữ sau NAT của nhà mạng là vấn đề khác

Nếu bạn muốn lưu trữ máy chủ L2TP/IPsec tại nhà và truy cập từ bên ngoài, yêu cầu là khả năng tiếp cận đầu vào không được yêu cầu, và đó không phải là thứ traversal NAT cung cấp. NAT của nhà mạng trước bộ định tuyến của bạn nghĩa là không có cổng nào bạn có thể chuyển tiếp để trở nên tiếp cận được, vì địa chỉ công cộng được chia sẻ và ánh xạ chỉ là đi ra.

Không hộp kiểm IPsec pass-through nào thay đổi điều đó, và không cấu hình máy khách nào bù đắp được. Các câu trả lời được hỗ trợ là một địa chỉ thực sự tiếp cận được, một điểm cuối được lưu trữ, hoặc một kiến trúc nơi mọi thành viên tạo kết nối đi ra. Đặc tả đóng gói UDP giải quyết vấn đề dịch cho các luồng đang tồn tại; nó không tạo ra đường vào nơi nhà mạng không cung cấp.

Vì vậy hãy so sánh các mạng thay vì đoán. Mang cùng thiết bị và hồ sơ sang mạng được phép khác và xem giai đoạn nào hỏng ở đó. Nếu nó chạy ở nơi khác, khác biệt nằm ở đường đi, và điều đó thu hẹp việc tìm kiếm về ba giai đoạn trên thay vì toàn bộ cấu hình.