VPN sau NAT bạn không thể cấu hình: điều gì vẫn hoạt động

Mỗi điểm cuối đường hầm cần một địa chỉ và một cổng mà phía bên kia có thể chạm tới, và một router bạn không quản trị là lý do thường gặp khiến yêu cầu đó thất bại. Phần thú vị không phải là có các mẹo, mà là mỗi mẹo phụ thuộc vào một thuộc tính của bảng ánh xạ mà bạn không thấy từ máy khách. Hai thuộc tính trong số đó quyết định gần như mọi thứ: cách một ánh xạ được tạo ra, và liệu nó có chấp nhận gói tin từ một địa chỉ mà phía trong chưa bao giờ liên hệ hay không. Hãy phân loại môi trường theo các thuộc tính đó và các cách lách sẽ không còn là chuyện dân gian.

Bảng ánh xạ quyết định mọi thứ

Dịch địa chỉ mạng giữ một bảng trong đó địa chỉ và cổng bên trong được ghi đối chiếu với địa chỉ và cổng công cộng. Các phản hồi khớp với một bản ghi được dịch ngược lại, và một gói tin đến từ bên ngoài mà không có bản ghi khớp thì không có đích nào cả. Chính hành vi đó giải thích vì sao một trình lắng nghe sau router không thể truy cập từ internet. Nó cũng giải thích vì sao gói tin đầu tiên theo mỗi hướng phải bắt nguồn từ bên trong.

Hãy nhìn bảng từ phía router và các cách lách trở nên rõ ràng: hoặc có gì đó tạo một mục vĩnh viễn, hoặc tạo một mục tạm thời và giữ nó tươi, hoặc lưu lượng không bao giờ đi theo đường đó. Phần còn lại của bài viết là ba trường hợp đó theo thứ tự. Không có gì ở đây phụ thuộc vào một tính năng của nhà cung cấp ngoài những gì bảng ghi lại.

Dịch vụ gặp gỡ có thể và không thể làm gì

Đục lỗ UDP dùng bản ghi đi ra như một lỗ mở tạm thời thay vì đánh bại bộ lọc. Cả hai bên liên hệ một dịch vụ gặp gỡ, dịch vụ này biết từng điểm cuối công cộng và báo lại cho bên kia điểm cuối của nó. Sau đó cả hai gửi về phía nhau, và mỗi gói đi ra tạo hoặc làm mới bản ghi cho phép phản hồi đi vào. Thứ tự là điều khiến nó hoạt động, và thứ tự cũng là điều khiến nó mong manh: một bên gửi trước khi bên kia tạo bản ghi của mình sẽ bị bỏ đi, trong khi một lần thử lại sau đó một chút lại thành công. Bản thân dịch vụ không mang lưu lượng VPN, nên đòn bẩy duy nhất của nó là thời điểm mà nó phối hợp.

Hành vi ánh xạ quyết định phần còn lại, và RFC 4787 nêu ba dạng: độc lập với điểm cuối, phụ thuộc địa chỉ, và phụ thuộc địa chỉ và cổng. Ở dạng cuối, cổng mà một bên phải nhắm tới thay đổi theo từng đích, nên dự đoán không còn đáng tin cậy. Đó là chỗ kỹ thuật này gặp ngõ cụt, vì NAT cấp nhà mạng và một tường lửa doanh nghiệp nghiêm ngặt đều loại bỏ khả năng dự đoán mà sơ đồ cần, và không lượng thử lại nào mang nó trở lại.

Keepalive, khởi động lại và điểm cuối di chuyển

Một đường đã đục lỗ là một luồng chứ không phải trình lắng nghe, nên mọi thứ chạy trên nó phải sống sót qua thay đổi. Nó phải giữ ánh xạ sống bằng lưu lượng định kỳ, nhận ra khi điểm cuối công cộng di chuyển, và thiết lập lại sau khi router khởi động lại hoặc địa chỉ được cấp lại. Các sản phẩm mesh VPN đặt logic đó trong mặt phẳng điều khiển của riêng chúng, còn một máy chủ đơn giản để mặc bạn. Keepalive chỉ giúp khi cùng một ánh xạ còn tồn tại, và chúng tốn pin trên máy khách di động, nên một khoảng thời gian hung hăng không miễn phí.

Một laptop ngủ một giờ thường trở lại trên một điểm cuối công cộng khác. Mọi thứ thiết lập lại đường đi phải chạy lại từ bên trong, điều này đặt lại yêu cầu đó lên máy khách.

Ba cách vòng qua một chuyển tiếp bị thiếu

Cách thứ nhất yêu cầu router tự tạo mục, thông qua UPnP IGD, NAT-PMP hoặc PCP, khi tính năng tồn tại và được bật. Cách thứ hai giao lưu lượng cho một relay có địa chỉ công cộng, luôn hoạt động và luôn tốn băng thông cộng với một ranh giới tin cậy khác. Cách thứ ba đảo ngược hướng: máy chủ bên trong mở một đường hầm đi ra tới một máy chủ công cộng và mọi thứ khác đi bên trong nó.

[Peer]
PublicKey = 6yGj3kQ2wVb8sTn1pLx4dRc7hZa9mKf2uYe5oNq0iXw=
Endpoint = relay.corp.internal:51820
PersistentKeepalive = 25
AllowedIPs = 10.44.0.0/24

Một điểm cuối relay làm cho việc trao đổi đó hiển thị trong cấu hình máy khách, nơi điểm cuối là một relay chứ không phải địa chỉ của chính bên kia. Keepalive liên tục giữ ấm ánh xạ, và các tiền tố được phép quyết định máy khách có thể gửi gì qua nó. Một đường hầm ngược từ máy chủ bên trong là cùng ý tưởng với một chủ sở hữu khác, và nó không cần bất kỳ thay đổi NAT nào. Mỗi cách trong ba cách loại bỏ yêu cầu đi vào mà không đánh bại một tường lửa vốn chặn lưu lượng không được yêu cầu theo thiết kế, vì lưu lượng vẫn bắt đầu từ bên trong.

Khớp cách lách với người sở hữu router

Nếu bạn quản trị router, một chuyển tiếp UDP tĩnh dễ kiểm tra hơn bất kỳ sơ đồ đục lỗ nào và thất bại theo những cách bạn thấy. Nếu không, hãy tìm hiểu xem nhà cung cấp có relay hoặc mặt phẳng điều khiển được lưu trữ hay không, và liệu chính sách có cho phép dùng nó. Nếu không có gì trong số đó, các lựa chọn còn lại là đường hầm ngược hoặc chấp nhận rằng điểm cuối không thể truy cập từ bên ngoài. Ghi lại bạn đã dùng cách nào quan trọng hơn vẻ ngoài, vì các lựa chọn khác nhau ở việc ai có thể quan sát lưu lượng và điều gì xảy ra khi một bên thứ ba thay đổi điều gì đó.

Hãy lưu ý đường đi cuối cùng là trực tiếp hay qua relay, vì riêng sự thật đó dự đoán cả độ trễ và hành vi khi lỗi. RFC 4787 vẫn là tài liệu tham chiếu cho hành vi ánh xạ bên dưới tất cả những điều này, và đọc phần ánh xạ của nó nhanh hơn là thử ba cách lần lượt. Bảng không quan tâm bạn chọn tùy chọn nào; nó chỉ ghi lại gói tiếp theo được phép làm gì.