Hai IP công cộng trên một Azure VPN VM: cái nào làm gì

Hai IP công cộng trên một Azure VPN VM tạo ra một kỳ vọng hiếm khi đúng: địa chỉ mà máy khách kết nối tới cũng sẽ là địa chỉ mà các trang web nhìn thấy. Ba quyết định độc lập tạo ra kết quả đó, và chỉ quyết định đầu liên quan đến trình lắng nghe của đường hầm. Quyết định thứ hai là nguồn phía máy khách dùng cho lưu lượng được chuyển tiếp, và quyết định thứ ba là phương thức ra của Azure áp dụng cho nguồn đó. Đổi một cái thì hai cái kia vẫn nguyên chỗ cũ, vì vậy hãy quyết định từng cái một cách rõ ràng.

Quyết định 1: đường hầm kết thúc ở đâu

Một IP công cộng của Azure được gắn với một cấu hình IP riêng trên NIC; đó không phải địa chỉ bạn thêm vào bên trong hệ điều hành của máy khách. Hãy đọc ánh xạ thay vì giả định: az network nic show --ids /subscriptions/.../networkInterfaces/vpn-nic --query 'ipConfigurations[].{private:privateIPAddress,public:publicIPAddress.id}'. Bất kỳ địa chỉ riêng nào mà truy vấn đó trả về chính là địa chỉ mà máy khách thực sự phải có.

Một NIC có thể mang nhiều cấu hình IP, nên hai địa chỉ công cộng không cần hai NIC. Nếu thiết kế thực sự dùng hai NIC, mỗi cái mang theo tuyến và bước nhảy tiếp theo của riêng nó, và bạn đã thêm một quyết định định tuyến thay vì đơn giản hóa một quyết định.

Với dịch vụ có ràng buộc cục bộ rõ ràng, hãy gắn vào địa chỉ riêng thật của máy khách, không bao giờ gắn vào phần giữ chỗ công cộng. Một trình lắng nghe chấp nhận mọi địa chỉ sẽ nhận lưu lượng qua mọi cấu hình IP tiếp cận nó, vì vậy hãy giới hạn lối vào bằng nhóm bảo mật mạng và tường lửa của máy chủ thay vì hy vọng thứ tự gắn kết sẽ quyết định.

Quyết định 2: máy khách được chuyển tiếp dùng nguồn nào

Sau khi cổng giải mã yêu cầu của máy khách, gói mà nó chuyển tiếp khác với gói đã đến trình lắng nghe VPN. Máy khách cần bật chuyển tiếp, một chính sách tường lửa cho phép luồng, và một địa chỉ nguồn mà thiết kế đám mây cho phép. Nếu bạn dịch địa chỉ bên trong của máy khách, Azure sẽ đánh giá chính nguồn đã dịch đó, không phải địa chỉ bên trong của máy khách.

Một quy tắc SNAT hẹp có thể chọn nguồn riêng của máy khách, nhưng không thể vượt qua bản dịch Azure ở phía sau. Chọn SNAT khi bạn cần trách nhiệm giải trình theo từng máy khách bên trong VM; bỏ qua khi thiết kế lối ra của mạng con đã cung cấp nguồn công cộng ổn định và bản dịch thứ hai chỉ thêm trạng thái.

Quyết định 3: phương thức ra nào của Azure thắng

Microsoft tài liệu hóathứ tự ưu tiên lối ra: một tuyến áp dụng được tới thiết bị hoặc cổng có ưu tiên, và kết nối mạng con qua NAT Gateway có ưu tiên hơn IP công cộng ở cấp phiên bản trên đường đi liên quan. Thứ tự đó là lý do vì sao dịch sang 10.20.0.5 không chứng minh rằng một trang web sẽ thấy 198.51.100.20. Hãy đọc bảng tuyến hiệu lực, liên kết NAT Gateway và IP công cộng của NIC cùng nhau trước khi chấp nhận thiết kế lối ra.

Hãy đểthiết lập chuyển tiếp của Azure NICtách biệt với chuyển tiếp trong Linux. Cờ đám mây cho phép các gói mà nguồn hoặc đích không được gán cho NIC; nó không bật net.ipv4.ip_forward, và thiết lập trong máy khách không cấp quyền của đám mây.

Socket của đường hầm có quyết định nguồn riêng

Address của WireGuard dưới wg-quick gán một địa chỉ cho giao diện WireGuard; đó không phải chỉ dẫn gắn kết UDP bên ngoài. Nguồn của socket mã hóa đi theo bảng tuyến, nên một tuyến chính sách hoặc tuyến mặc định thứ hai có thể di chuyển nó mà không chạm vào địa chỉ giao diện.OpenVPN: tùy chọn local và UDP multihome hành xử giống nhau: chúng liên quan đến trình lắng nghe và các phản hồi, không liên quan đến nguồn internet của từng máy khách được chuyển tiếp.

Giữ tuyến lớp dưới mang đường hầm, và xác nhận máy khách vẫn nhận được phản hồi đã xác thực từ bố trí lối vào mong đợi. Đừng dựa vào thứ tự danh sách địa chỉ như một chính sách chọn nguồn lâu dài, vì địa chỉ tiếp theo được thêm vào NIC có thể thay đổi cái nào thắng.

Chấp nhận điều gì, và theo thứ tự nào

Chấp nhận ba kết quả riêng rẽ. Thứ nhất, một máy khách bên ngoài đến được lối vào VPN dự kiến. Thứ hai, một yêu cầu mới được cho phép từ máy khách VPN đó đi ra qua lối ra internet đã ghi nhận. Thứ ba, các đường lắng nghe và chuyển tiếp không mong muốn vẫn bị từ chối. Ghi lại các ánh xạ công cộng sang riêng tư và người phụ trách phía máy khách và đám mây của từng quyết định ở cùng một nơi.

Một đường hầm thành công chỉ chứng minh phần đầu. Hãy kiểm tra lối ra bằng một luồng mới, vì một kết nối đã lưu trong bộ nhớ đệm có thể tiếp tục dùng nguồn cũ rất lâu sau khi tuyến thay đổi.