Vì sao một VM có thiết bị VPN trên Azure mất đường trả về
Một thiết bị VPN trong VM của Azure cần UDR, cờ chuyển tiếp của card mạng và chính sách của khách đồng thuận với nhau. Hãy theo một yêu cầu chi nhánh đi qua cả ba.
Một VM của Azure chạy thiết bị VPN nằm trong hai hệ thống ra quyết định độc lập. Azure quyết định gói tin rời khỏi subnet nào, bằng bảng tuyến và thiết lập chuyển tiếp của card mạng. Hệ điều hành của chính thiết bị quyết định có chuyển tiếp gói tin đã giải mã hay không. Một đường hầm dựng lên hoàn hảo vẫn có thể thất bại ở hệ thống thứ hai, và đó là nơi phần lớn các triển khai kiểu này dừng lại.
Ba chủ sở hữu của một tuyến đường
Lấy một mạng chi nhánh 192.168.50.0/24 và một subnet cho khối lượng công việc 10.0.10.0/24, thiết bị nằm tại 10.0.0.4 trong subnet riêng của nó. Một yêu cầu duy nhất chạm vào ba cấu hình riêng biệt.
| Decision | Configured in | How it fails |
|---|---|---|
| Where the workload subnet sends branch traffic | Azure route table entry | Traffic leaves the subnet and never reaches the appliance |
| Whether a NIC may accept traffic not addressed to it | Azure NIC IP forwarding | Packets arrive and disappear at the interface |
| Whether the guest forwards decrypted traffic | Guest OS or vendor appliance policy | Tunnel is up, workload is unreachable |
| Whether the workload accepts the source | NSG and service policy | Requests delivered, replies refused |
Mỗi dòng do một nhóm khác nhau sở hữu trong phần lớn tổ chức, vì thế sự cố này thường đến dưới dạng ba phiếu thay vì một.
Tuyến chỉ về thiết bị
Liên kết bảng tuyến với subnet của khối lượng công việc và cho tiền tố chi nhánh một bước nhảy kế tiếp kiểu Virtual appliance với 10.0.0.4 làm địa chỉ. Hãy dùng địa chỉ riêng có thể đến được của thiết bị, không bao giờ dùng điểm vào VPN công khai của nó. Bước nhảy kế tiếp phải là một địa chỉ mà subnet của khối lượng công việc đã có thể đến. Hãy để phần định tuyến còn lại của khối lượng công việc yên, trừ khi bạn đã chủ động quyết định thay tuyến mặc định.
Giữ thiết bị trong subnet riêng của nó và bảo đảm tuyến gửi lưu lượng chi nhánh tới thiết bị không bắt luôn đường ra của chính thiết bị. Một vòng lặp như vậy trông như đường hầm khỏe mạnh mà không có phản hồi nào, và gỡ lỗi nó lúc 2 giờ sáng là việc rất khổ sở.
Cờ card mạng mà mọi người đều quên
Azure có thiết lập chuyển tiếp IP cho từng card mạng, và mặc định là tắt. Nó tồn tại vì card chuyển tiếp nhận các gói tin được gửi tới thứ khác, và âm thầm bỏ chúng là mặc định an toàn cho mọi người còn lại.
az network nic update --resource-group rg-net --name appliance-nic --ip-forwarding true bật nó cho một giao diện. Hướng dẫn của Microsoft về chuyển tiếp trên card mạng yêu cầu thiết lập này trên mọi card được gắn kết có chuyển tiếp lưu lượng, nên thiết bị một card vẫn cần đặt nó trên card đó.
Cờ này không phải tuyến đường và cũng không phải quy tắc tường lửa. Bật nó lên chỉ cấp quyền và không gì khác.
Khách xử lý gói tin đã giải mã thế nào
Khi đường hầm kết thúc, ngăn xếp của chính thiết bị đưa ra quyết định tiếp theo. Trên khách Linux, chuyển tiếp IPv4 là thiết lập lúc chạy, và sysctl -w net.ipv4.ip_forward=1 chỉ kéo dài đến lần khởi động kế tiếp. Hãy lưu nó vào một tệp dưới /etc/sysctl.d/ thay vào đó. Thiết bị của nhà cung cấp có tương đương riêng, và các hướng dẫn Linux dán vào nền tảng của nhà cung cấp thường không làm gì cả.
Chính sách tường lửa của khách lại tách riêng, và nhóm bảo mật mạng của khối lượng công việc cũng vậy. Cho phép UDP 500 và 4500 tới địa chỉ công khai của VM bảo vệ đường hầm; nó không nói gì về việc một yêu cầu chi nhánh đã giải mã có thể tới một cổng của khối lượng công việc hay không.
Theo một yêu cầu và phản hồi của nó
Chọn một luồng được phép và theo nó từ đầu đến cuối. Chi nhánh cần một tuyến cho 10.0.10.0/24 qua kết nối site, thiết bị cần một đường giao tới subnet của khối lượng công việc, và subnet của khối lượng công việc cần một tuyến trả về phía chi nhánh.
Hãy quyết định sớm xem thiết kế giữ địa chỉ nguồn của chi nhánh hay dịch nó. NAT thay đổi thứ mà khối lượng công việc nhìn thấy, nên các quy tắc truy cập của nó phải mô tả mô hình bạn thực sự chọn chứ không phải một địa chỉ cổng mạng đoán được.
Một cái bắt tay thành công chỉ chứng minh một mắt xích của chuỗi đó. Tuyến đường hoàn chỉnh khi phản hồi quay về qua đúng thiết bị ấy và chính sách của khối lượng công việc cho phép điều đó.