Vì sao GRE và ESP thất bại qua cổng NAT của AWS
Cổng NAT được quản lý chỉ chuyển tiếp TCP, UDP và ICMP. Xem vì sao một quy tắc cho phép không thể mang GRE hoặc ESP gốc, và cần thay đổi điều gì thay thế.
Đường hầm thất bại, nhóm bảo mật đã cho phép toàn bộ lưu lượng, và kết luận là AWS đang chặn VPN. Nó không chặn gì cả. Một cổng NAT được quản lý chuyển tiếp một tập hợp giao thức bên ngoài đã được ghi nhận, và GRE gốc hoặc ESP gốc không nằm trong đó, nên không quy tắc nào bạn thêm vào khiến cổng mang chúng. Quy tắc cho phép và khả năng vận chuyển là hai thứ khác nhau, và chỉ một trong hai là thứ bạn có thể thay đổi.
Tập quy tắc không phải tập giao thức
Nhóm bảo mật quyết định lưu lượng nào được phép rời khỏi phiên bản. Cổng NAT quyết định nó có thể dịch và chuyển tiếp những gì. Khi giới hạn thứ hai áp dụng, một quy tắc dễ dãi tạo ra đúng triệu chứng mà người ta đọc sai thành vấn đề tường lửa: các gói rời khỏi phiên bản, trao đổi điều khiển thậm chí có thể hoàn tất, và không có gì đến được phía đối tác.
Đặc tả giao thức của cổng NAT của AWS liệt kê TCP, UDP và ICMP cho dịch vụ được quản lý. Đó là toàn bộ tập được hỗ trợ. Một quy tắc cho phép đối với giao thức IP khác không thể mở rộng nó, vì quy tắc được đánh giá rất lâu trước khi đường chuyển tiếp của cổng được chạm tới.
Sự khác biệt này quan trọng vì hai lỗi trông giống hệt nhau từ phía máy khách và có cách khắc phục hoàn toàn khác nhau.
PPTP cho thấy vì sao một bài kiểm tra cổng nói dối
PPTP là ví dụ cũ rõ ràng nhất về việc kiểm tra cổng mà không chứng minh được gì. Nó mở một kết nối điều khiển TCP trên cổng 1723 rồi mang dữ liệu đường hầm qua GRE, tức giao thức IP 47. Giao thức 47 không phải cổng TCP 47, và hai con số này không có gì liên quan ngoài việc chia sẻ chữ số.
Một người vận hành kiểm tra kết nối tới 1723 và thấy bắt tay hoàn tất sẽ kết luận đường đi hoạt động. Sau đó kênh dữ liệu không bao giờ đi qua một gói nào, vì cổng không có hỗ trợ GRE để cung cấp. Đó là cách diễn giải yêu cầu của một giao thức cũ, không phải lời khuyên triển khai PPTP, vốn đã lỗi thời từ nhiều năm.
Lập luận tương tự áp dụng cho bất kỳ giao thức nào có kênh điều khiển là TCP hoặc UDP trong khi đường dữ liệu thì không.
IPsec chỉ tồn tại như UDP
IPsec là trường hợp câu trả lời có điều kiện chứ không phải một lời từ chối thẳng. AWS ghi nhận NAT traversal là cách bố trí được hỗ trợ cho IPsec qua cổng NAT. Khi NAT-T được thương lượng, ESP được đóng gói trong UDP và cổng thấy UDP thông thường thay vì giao thức 50.
Cho phép UDP 4500 không khiến các điểm cuối dùng NAT traversal. Nó chỉ cho phép các gói nếu chúng đã ở dạng đó. Xác nhận từ đầu ra thương lượng của chính máy khách xem đóng gói nào được chọn, và xác nhận ở phía nhận rằng đối tác đã chấp nhận nó. Hai điểm cuối được cấu hình cho ESP gốc sẽ tiếp tục gửi ESP gốc, bất kể tập quy tắc nói gì.
Một VPN dựa trên TCP hoặc UDP phù hợp với tập vận chuyển đã ghi nhận và vẫn có thể thất bại vì lý do định tuyến, lọc hoặc xác thực. Phù hợp với tập là cần thiết, không đủ.
Kiểm tra đường đi trước khi mở rộng chính sách
Xác minh tuyến thực tế của mạng con khối lượng công việc và danh tính của bước nhảy tiếp theo trước tiên. Một đường công khai trực tiếp, một phiên bản NAT, một cổng NAT được quản lý và một đường riêng qua cổng chuyển tiếp là bốn thiết kế khác nhau, và chỉ một trong số đó là dịch vụ được quản lý mô tả ở đây.
Sau đó ghi lại điểm cuối đã thử, họ địa chỉ, giao thức bên ngoài và cổng nếu giao thức có. Dùng chẩn đoán của máy khách và quan sát luồng của chủ sở hữu mạng thay vì một yêu cầu trình duyệt thành công, vì nó chỉ chứng minh TCP và UDP hoạt động. Sau đó, xem lại nhóm bảo mật, ACL của mạng con, tường lửa của khách và chính sách dịch vụ cho cả hai hướng của luồng.
Đừng mở toàn bộ lưu lượng để bù đắp cho một phương thức vận chuyển mà dịch vụ không thể mang. Thay đổi quy tắc sẽ không khắc phục được, và nó sẽ tồn tại sau sự cố.
Khi phương thức vận chuyển không phù hợp
Nếu giao thức bên ngoài nằm ngoài tập được hỗ trợ, cách khắc phục là kiến trúc: chọn một phương thức vận chuyển mà đường đi có thể mang, hoặc chuyển lối ra sang thứ mang được thứ bạn cần. OpenVPN qua UDP, WireGuard qua UDP và các đường hầm dựa trên TLS đều phù hợp với tập đã ghi nhận. Một phiên bản NAT do khách hàng quản lý là lựa chọn khi một giao thức cụ thể phải đi qua và chi phí vận hành nó là chấp nhận được.
Lưu trữ một máy chủ VPN đầu vào là vấn đề riêng với câu trả lời riêng. Cổng NAT cung cấp dịch chuyển ra ngoài và không cung cấp chuyển tiếp cổng vào tổng quát, nên máy chủ phía sau cần lối vào công khai đã được phê duyệt thiết kế theo điều kiện riêng của nó.
Thứ tự công việc: gọi tên giao thức bên ngoài, xác nhận bước nhảy tiếp theo, so sánh với tập đã ghi nhận, rồi thay đổi kiến trúc hoặc phương thức vận chuyển. Một số cổng khác không thể biến GRE thành TCP, và thêm một quy tắc dễ dãi không thể biến một trao đổi điều khiển đã hoàn tất thành kênh dữ liệu hoạt động.