De ce Azure Point-to-Site VPN nu îți schimbă IP-ul public

Conectez clientul Azure VPN pe un laptop Windows, deschid o pagină de ecou al adresei și văd aceeași adresă publică pe care a asignat-o routerul de acasă. Între timp, jump box-ul de la 10.20.0.4 răspunde și un nume de endpoint privat se rezolvă, deci tunelul nu este stricat. Un gateway point-to-site face exact ce spune configurația sa implicită: transportă prefixele private și lasă tot restul pe legătura locală. Obținerea unei adrese de ieșire deținute de Azure este o schimbare de proiectare a rutării, nu o reparație.

Ce anunță gateway-ul implicit

Gateway-ul împinge rute pentru spațiul de adrese al rețelei virtuale, plus rețelele asociate unde tranzitul prin gateway este permis și prefixele locale învățate printr-o conexiune site-to-site sau BGP. Nu există 0.0.0.0/0 în acel set. Sistemul tău de operare păstrează ruta implicită pe Wi-Fi sau Ethernet, așa că un pachet către un API public nu intră niciodată în tunel.

Adresa pe care clientul o primește în tunel este un lease privat din pool-ul point-to-site. Identifică clientul în fața resurselor din VNet; nu este o adresă pe care internetul o poate vedea și nu va apărea niciodată ca sursă a unei cereri de ieșire către un API SaaS. O intrare în lista de permisiuni construită în jurul acelui lease nu poate funcționa, oricât ai aștepta să apară în logurile furnizorului.

Tunel divizat și tunelare forțată alături

Doar al doilea rând schimbă adresa pe care o vede un serviciu la distanță. Tot restul din tabel este cost și suprafață operațională pe care le accepți când ieșirea trebuie inspectată sau tradusă în interiorul Azure. Dacă cineva îți cere să schimbi IP-ul public, cere toată coloana din dreapta, nu o mică ajustare la client.

Există o opțiune intermediară care merită numită înainte de a reconstrui ceva. Un VM proxy sau gateway în VNet îți dă o adresă sursă controlată pentru aplicațiile care pot fi îndreptate spre el, fără a muta ruta implicită a clientului. Asta păstrează navigarea normală locală și satisface în continuare un partener care are nevoie doar de un singur apel API venit din Azure. Eșuează când cerința este într-adevăr despre tot traficul, pentru că orice ignoră setarea de proxy tot iese local.

Fă tunelul să transporte ruta implicită

Pe un gateway de rețea virtuală, modalitatea acceptată de a direcționa tot traficul de internet al clientului în tunel este adăugarea de rute personalizate la configurația point-to-site. Două jumătăți acoperă întregul spațiu IPv4, iar fiecare este mai specifică decât ruta implicită locală, așa că clientul le preferă fără a șterge nimic:

Set-AzVirtualNetworkGateway -VirtualNetworkGateway GWOBJ -CustomRoute 0.0.0.0/1,128.0.0.0/1

Acea linie este ilustrativă, nu completă pentru copiere: obține mai întâi obiectul gateway-ului cu Get-AzVirtualNetworkGateway și înlocuiește GWOBJ cu el, apoi confirmă, înainte de a-l rula, că SKU-ul și modelul de implementare acceptă rute personalizate. Aceleași prefixe apar în portal, pe pagina de configurare point-to-site, care este locul mai sigur pentru a le seta dacă nu scriptezi deja gateway-ul.

Schimbarea acestor prefixe invalidează pachetul clientului. Descarcă din nou pachetul clientului VPN și reinstalează-l, pentru că rutele călătoresc în profil. Un client care se reconectează cu profilul vechi păstrează setul vechi de rute, iar tu poți pierde o oră depanând o schimbare care nu a ajuns niciodată la el.

Într-un hub WAN virtual securizat, echivalentul este o rută implicită în tabela de rute a hub-ului asociată gateway-ului point-to-site, cu Azure Firewall din hub preluând traficul. Firewall-ul traduce conexiunile către internet în propriile adrese IP publice, iar din această traducere provine noua adresă de ieșire. Când un firewall are mai multe IP-uri publice, oricare dintre ele poate apărea ca sursă, așa că lista de permisiuni trebuie să le conțină pe toate.

Ambele proiecte de mai sus sunt IPv4. Cele două prefixe /1 nu fac nimic pentru IPv6, iar suportul IPv6 point-to-site este destul de îngust încât să testezi combinația înainte de a promite paritate.

Verifică ruta, apoi ieșirea

După reinstalarea pachetului și reconectare, confirmă că clientul a instalat într-adevăr jumătățile. În Windows, Get-NetRoute -DestinationPrefix 0.0.0.0/1 și aceeași interogare pentru 128.0.0.0/1 ar trebui să numească interfața tunelului, iar route print le arată pe ambele lângă ruta ta implicită originală. În Linux, ip route show trebuie să listeze cele două prefixe; dacă nu o face, profilul nu le-a transportat niciodată.

Apoi reverifică adresa publică de la client și citește jurnalul firewall-ului pentru aceeași conexiune. Sursa ar trebui să fie IP-ul public al firewall-ului cu un port tradus. Un client care încă iese local în timp ce ambele rute există înseamnă că pachetele au ajuns la Azure și au plecat pe altă cale: o rută definită de utilizator pe subrețeaua gateway-ului, un firewall care este el însuși tunelat forțat către rețeaua locală, sau o politică ce aruncă fluxul înainte de traducere.

Retestează o destinație privată în aceeași sesiune. Un host de salt care încetează să răspundă după schimbare este semnul obișnuit că noile prefixe au dislocat ceva, fie o rută locală mai îngustă care era anunțată anterior, fie rezolvarea numelor care merge acum la un resolver fără forwarder pentru zonele tale private.

Când să lași tunelul divizat în pace

Dacă scopul este doar să ajungi la un API privat, un endpoint privat sau o pagină de administrare internă, comportamentul implicit este mai ieftin și mai silențios. Tunelarea forțată adaugă ore de firewall și costuri de procesare a datelor, o cale mai lungă și încă un loc unde fiecare flux al clientului poate eșua. Captează și mult mai mult trafic decât singura destinație care te interesa.

Recurge la el când cerința este formulată în termeni de ieșire: un partener trebuie să vadă o adresă Azure fixă, securitatea vrea conexiunile jurnalizate și inspectate, sau datele trebuie să iasă printr-un singur punct controlat. Chiar și atunci proiectul dă fiecărui utilizator o ieșire partajată, așa că responsabilitatea pe utilizator trebuie să vină din identitatea din aplicație, nu din adresa sursă.

Înainte de a închide schimbarea, confirmă patru lucruri: pachetul client instalat este cel nou, cele două rute /1 stau pe interfața tunelului, o destinație privată încă răspunde și jurnalul serviciului la distanță arată adresa firewall-ului.