Două IP-uri publice pe un singur VM VPN Azure: care face ce

Două IP-uri publice pe un singur VM VPN Azure creează o așteptare care rareori se confirmă: adresa la care se conectează clienții va fi și adresa pe care o văd site-urile web. Trei decizii independente produc acel rezultat, iar doar prima privește ascultătorul tunelului. A doua este sursa din invitat folosită pentru traficul de client redirecționat, iar a treia este metoda de ieșire Azure aplicată acelei surse. Schimbați una și celelalte două rămân unde erau, așa că decideți fiecare în mod explicit.

Decizia 1: unde se termină tunelul

Un IP public Azure este asociat cu o configurație de IP privat pe NIC; nu este o adresă pe care o adăugați în sistemul de operare al invitatului. Citiți asocierea în loc să o presupuneți: az network nic show --ids /subscriptions/.../networkInterfaces/vpn-nic --query 'ipConfigurations[].{private:privateIPAddress,public:publicIPAddress.id}'. Orice adresă privată ar returna acea interogare este cea pe care invitatul trebuie să o aibă efectiv.

O singură NIC poate purta mai multe configurații de IP, așa că două adrese publice nu necesită două NIC-uri. Dacă proiectul folosește totuși două NIC-uri, fiecare aduce propriile rute de invitat și următoarele salturi, iar dumneavoastră ați adăugat o decizie de rutare în loc să o simplificați.

Pentru un serviciu cu o legare locală explicită, legați-vă de adresa privată reală a invitatului, niciodată de substituentul public. Un ascultător care acceptă toate adresele primește trafic prin fiecare configurație de IP care ajunge la el, așa că limitați intrarea cu grupul de securitate de rețea și cu firewallul gazdei în loc să sperați că ordinea legării va decide.

Decizia 2: ce sursă folosește clientul redirecționat

După ce gateway-ul decriptează o cerere a clientului, pachetul pe care îl redirecționează este diferit de cel care a ajuns la ascultătorul VPN. Invitatul are nevoie de redirecționare activată, de o politică de firewall care permite fluxul și de o adresă sursă permisă de proiectul cloud. Dacă traduci adresa internă a clientului, acea sursă tradusă este cea pe care Azure o va evalua, nu adresa internă a clientului.

O regulă SNAT îngustă poate alege o sursă privată a invitatului, dar nu poate anula o traducere Azure ulterioară. Alegeți SNAT când aveți nevoie de responsabilitate pe client în interiorul VM-ului; omiteți-l când proiectul de ieșire al subrețelei oferă deja o sursă publică stabilă și o a doua traducere ar adăuga doar stare.

Decizia 3: ce metodă de ieșire Azure câștigă

Microsoft documenteazăordinea de precedență a ieșirii: o rută aplicabilă către un dispozitiv sau un gateway are prioritate, iar conectivitatea subrețelei prin NAT Gateway are prioritate față de un IP public la nivel de instanță pe calea relevantă. Această ordine este motivul pentru care traducerea către 10.20.0.5 nu dovedește că un site web va vedea 198.51.100.20. Citiți împreună tabelul de rute efectiv, asocierea NAT Gateway și IP-ul public al NIC-ului înainte de a accepta proiectul de ieșire.

Ținețisetarea de redirecționare a NIC-ului Azureseparată de redirecționarea din Linux. Indicatorul din cloud permite pachete a căror sursă sau destinație nu este atribuită NIC-ului; nu activează net.ipv4.ip_forward, iar setarea din invitat nu acordă permisiunea cloud.

Socketul tunelului are propria decizie de sursă

Address din WireGuard sub wg-quick atribuie o adresă interfeței WireGuard; nu este o instrucțiune de legare UDP externă. Sursa socketului criptat urmează tabelul de rute, așa că o rută de politică sau o a doua rută implicită o poate muta fără a atinge adresa interfeței.OpenVPN: opțiunea local și UDP multihome se comportă la fel: privesc ascultătorul și răspunsurile lui, nu sursa de internet a fiecărui client redirecționat.

Păstrați ruta stratului inferior care transportă tunelul și confirmați că clientul primește în continuare răspunsuri autentificate din aranjamentul de intrare așteptat. Nu vă bazați pe ordinea listei de adrese ca politică permanentă de selecție a sursei, pentru că următoarea adresă adăugată la NIC poate schimba care câștigă.

Ce să acceptați și în ce ordine

Acceptați trei rezultate separat. În primul rând, un client extern ajunge la intrarea VPN dorită. În al doilea rând, o nouă cerere permisă de la acel client VPN iese prin ieșirea de internet documentată. În al treilea rând, căile de ascultare și redirecționare neintenționate rămân refuzate. Înregistrați corespondențele public-la-privat și responsabilii de invitat și de cloud ai fiecărei decizii în același loc.

Un tunel reușit dovedește doar prima parte. Testați ieșirea cu un flux nou, deoarece o conexiune din memoria cache poate continua să folosească sursa veche mult timp după schimbarea rutei.