Dalawang pampublikong IP sa isang Azure VPN VM: alin ang gumagawa ng ano

Ang dalawang pampublikong IP sa isang Azure VPN VM ay lumilikha ng inaasahan na bihirang mangyari: ang address na kinokonektahan ng mga client ay magiging address din na nakikita ng mga website. Tatlong malayang desisyon ang gumagawa niyon, at ang una lang ang tungkol sa listener ng tunnel. Ang pangalawa ay ang pinagmulan sa guest na ginagamit para sa ipinasa na trapiko ng client, at ang pangatlo ay ang paraan ng labasan ng Azure na nalalapat sa pinagmulang iyon. Baguhin ang isa at ang dalawa ay mananatili kung nasaan sila, kaya magpasya sa bawat isa nang malinaw.

Desisyon 1: saan nagtatapos ang tunnel

Ang pampublikong IP ng Azure ay nakaugnay sa isang pribadong IP configuration sa NIC; hindi ito address na idinaragdag mo sa loob ng operating system ng guest. Basahin ang mapping sa halip na ipagpalagay ito: az network nic show --ids /subscriptions/.../networkInterfaces/vpn-nic --query 'ipConfigurations[].{private:privateIPAddress,public:publicIPAddress.id}'. Anumang pribadong address na ibalik ng query na iyon ang siyang dapat talagang hawak ng guest.

Ang isang NIC ay makakadala ng maraming IP configuration, kaya ang dalawang pampublikong address ay hindi nangangailangan ng dalawang NIC. Kung talagang gumagamit ng dalawang NIC ang disenyo, bawat isa ay nagdadala ng sariling ruta sa guest at susunod na hop, at nagdagdag ka ng desisyon sa routing sa halip na pasimplehin ito.

Para sa serbisyong may malinaw na lokal na pagkakabit, ikabit sa tunay na pribadong address ng guest, hindi kailanman sa pampublikong placeholder. Ang listener na tumatanggap ng lahat ng address ay tumatanggap ng trapiko sa bawat IP configuration na umaabot dito, kaya limitahan ang pasukan gamit ang network security group at firewall ng host sa halip na umasa na ang pagkakasunod-sunod ng pagkakabit ang magpapasya.

Desisyon 2: anong pinagmulan ang ginagamit ng ipinasa na client

Matapos i-decrypt ng gateway ang request ng client, ang packet na ipinapasa nito ay iba sa packet na dumating sa listener ng VPN. Kailangan ng guest ng naka-enable na pagpapasa, patakaran ng firewall na pumapayag sa daloy, at source address na pinapayagan ng disenyo ng cloud. Kung isasalin mo ang panloob na address ng client, ang isinaling pinagmulan na iyon ang susuriin ng Azure, hindi ang panloob na address ng client.

Ang makitid na tuntunin ng SNAT ay makakapili ng pribadong pinagmulan sa guest, ngunit hindi nito maaagawan ng bisa ang kasunod na pagsasalin ng Azure. Piliin ang SNAT kapag kailangan mo ng pananagutan sa bawat client sa loob ng VM; laktawan ito kapag ang disenyo ng labasan ng subnet ay nagbibigay na ng matatag na pampublikong pinagmulan at ang ikalawang pagsasalin ay magdadagdag lamang ng estado.

Desisyon 3: aling paraan ng labasan ng Azure ang nananalo

Dokumentado ng Microsoft angpagkakasunod-sunod ng priyoridad ng labasan: ang naaangkop na ruta patungo sa appliance o gateway ay may priyoridad, at ang konektibidad ng subnet sa pamamagitan ng NAT Gateway ay may priyoridad kaysa pampublikong IP sa antas ng instance sa kaugnay na landas. Dahil sa pagkakasunod-sunod na iyon, ang pagsasalin sa 10.20.0.5 ay hindi nagpapatunay na makikita ng website ang 198.51.100.20. Basahin nang sabay ang epektibong talahanayan ng ruta, ang kaugnayan sa NAT Gateway at ang pampublikong IP ng NIC bago tanggapin ang disenyo ng labasan.

Panatilihinghiwalay ang setting ng pagpapasa ng Azure NICsa pagpapasa sa Linux. Pinapayagan ng flag ng cloud ang mga packet na ang pinagmulan o destinasyon ay hindi nakatalaga sa NIC; hindi nito binubuksan ang net.ipv4.ip_forward, at ang setting sa guest ay hindi nagbibigay ng pahintulot ng cloud.

Ang socket ng tunnel ay may sariling desisyon sa pinagmulan

Ang Address ng WireGuard sa ilalim ng wg-quick ay nagtatalaga ng address sa interface ng WireGuard; hindi ito tagubilin sa panlabas na pagkakabit ng UDP. Ang pinagmulan ng naka-encrypt na socket ay sumusunod sa talahanayan ng ruta, kaya malilipat ito ng patakaran ng ruta o ikalawang default na ruta nang hindi ginalaw ang address ng interface.OpenVPN: ang opsyon na local at UDP multihome ay ganoon din ang asal: tungkol sila sa listener at sa mga sagot nito, hindi sa pinagmulan sa internet ng bawat ipinasa na client.

Panatilihin ang ruta ng ilalim na layer na nagdadala ng tunnel, at tiyakin na ang client ay tumatanggap pa rin ng mga awtentikadong sagot mula sa inaasahang ayos ng pasukan. Huwag umasa sa pagkakasunod-sunod ng listahan ng address bilang permanenteng patakaran sa pagpili ng pinagmulan, dahil ang susunod na address na idadagdag sa NIC ay maaaring magbago kung alin ang mananalo.

Ano ang tatanggapin, at sa anong pagkakasunod-sunod

Tanggapin ang tatlong resulta nang hiwalay. Una, naaabot ng panlabas na client ang inilaan na pasukan ng VPN. Ikalawa, lumalabas ang isang bagong pinahintulutang request mula sa client ng VPN na iyon sa naidokumentong labasan sa internet. Ikatlo, nananatiling tinatanggihan ang mga hindi sinasadyang landas ng listener at pagpapasa. Itala ang mga mapping mula pampubliko patungong pribado at ang mga may-ari sa guest at cloud ng bawat desisyon sa isang lugar.

Ang matagumpay na tunnel ay nagpapatunay lamang sa unang bahagi. Subukan ang labasan gamit ang bagong daloy, dahil ang naka-cache na koneksyon ay maaaring gumamit pa ng lumang pinagmulan matagal pagkatapos magbago ang ruta.