Bakit nawawala ng VM na may VPN appliance sa Azure ang pabalik na landas
Ang VPN appliance sa isang VM sa Azure ay nangangailangan na magkatugma ang UDR, ang flag ng pagpapasa ng NIC at ang patakaran ng bisita. Sundan ang isang hiling ng sangay sa lahat ng tatlo.
Ang isang VM sa Azure na nagpapatakbo ng VPN appliance ay nasa loob ng dalawang independiyenteng sistema ng pagpapasya. Itinatakda ng Azure kung saan lumalabas ang isang packet sa isang subnet, gamit ang mga talahanayan ng ruta at ang setting ng pagpapasa ng NIC. Itinatakda ng sariling operating system ng appliance kung ipapasa nito ang na-decrypt na packet. Ang isang tunnel na perpektong bumabangon ay maaaring pa ring mabigo sa pangalawang sistema, at doon humihinto ang karamihan sa mga deployment na ito.
Tatlong may-ari ng isang landas
Kumuha ng network ng sangay na 192.168.50.0/24 at isang subnet ng workload na 10.0.10.0/24, na ang appliance ay nasa 10.0.0.4 sa sarili nitong subnet. Isang hiling lang ang tumatama sa tatlong magkahiwalay na configuration.
| 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 |
Bawat hilera ay pag-aari ng ibang koponan sa karamihan ng organisasyon, kaya kadalasang dumarating ang kabiguang ito bilang tatlong ticket sa halip na isa.
Ang rutang tumuturo sa appliance
Iugnay ang talahanayan ng ruta sa subnet ng workload at bigyan ang prefix ng sangay ng susunod na hop na uri Virtual appliance na may 10.0.0.4 bilang address. Gamitin ang maabot na pribadong address ng appliance, huwag kailanman ang pampublikong entry point nito ng VPN. Ang susunod na hop ay dapat isang address na kayang maabot na ng subnet ng workload. Iwanan ang natitirang routing ng workload, maliban kung sinadya mong palitan ang default na ruta.
Panatilihin ang appliance sa sarili nitong subnet, at tiyakin na ang rutang nagpapadala ng trapiko ng sangay sa appliance ay hindi rin nahuhuli sa sariling palabas na landas ng appliance. Ang gayong loop ay mukhang malusog na tunnel na walang sagot, at napakahirap i-debug nito sa ganap na 2 ng madaling-araw.
Ang flag ng NIC na nakakalimutan ng lahat
May setting ang Azure ng pagpapasa ng IP sa bawat NIC, at naka-off ito bilang default. Umiiral ito dahil ang NIC na nagpapasa ay tumatanggap ng mga packet na nakaaddress sa ibang bagay, at ang tahimik na pagtatapon sa mga ito ang ligtas na default para sa lahat ng iba.
az network nic update --resource-group rg-net --name appliance-nic --ip-forwarding true binubuksan ito para sa isang interface. Ang gabay ng Microsoft tungkol sa pagpapasa sa NIC ay nangangailangan ng setting sa bawat konektadong NIC na nagpapasa ng trapiko, kaya kailangan pa rin ito ng appliance na may isang NIC sa NIC na iyon.
Ang flag ay hindi ruta at hindi patakaran ng firewall. Ang pagbukas nito ay nagbibigay ng pahintulot at wala nang iba.
Ano ang ginagawa ng bisita sa na-decrypt na packet
Kapag natapos ang tunnel, ang sariling stack ng appliance ang gumagawa ng susunod na pasya. Sa bisitang Linux, ang pagpapasa ng IPv4 ay setting sa oras ng pagtakbo, at sysctl -w net.ipv4.ip_forward=1 tumatagal hanggang sa susunod na boot. I-save ito sa isang file sa ilalim ng /etc/sysctl.d/ sa halip. Ang appliance ng vendor ay may sariling katumbas, at ang mga tagubilin ng Linux na idinikit sa platform ng vendor ay karaniwang walang ginagawa.
Ang patakaran ng firewall ng bisita ay hiwalay na naman, gayundin ang grupo ng seguridad ng network ng workload. Ang pagpayag sa UDP 500 at 4500 papunta sa pampublikong address ng VM ay nagpoprotekta sa tunnel; wala itong sinasabi tungkol sa kung ang na-decrypt na hiling ng sangay ay makakaabot sa isang port ng workload.
Sundan ang isang hiling at ang sagot nito
Pumili ng isang pinapayagang daloy at sundan ito mula simula hanggang wakas. Kailangan ng sangay ng ruta para sa 10.0.10.0/24 sa pamamagitan ng koneksyon ng site, kailangan ng appliance ng landas ng paghahatid patungo sa subnet ng workload, at kailangan ng subnet ng workload ng pabalik na ruta patungo sa sangay.
Magpasya nang maaga kung pinapanatili ng disenyo ang source address ng sangay o isinasalin ito. Binabago ng NAT ang nakikita ng workload, kaya dapat ilarawan ng mga patakaran ng pag-access nito ang modelong talagang pinili mo at hindi isang hinulaang address ng gateway.
Ang matagumpay na pakikipagkamay ay nagpapatunay ng isang kawing ng kadenang iyon. Kumpleto ang landas kapag bumalik ang sagot sa pamamagitan ng parehong appliance at pinapayagan ito ng sariling patakaran ng workload.