Perché la VPN punto a sito di Azure non cambia il tuo IP pubblico

Collego il client Azure VPN su un portatile Windows, apro una pagina di eco dell'indirizzo e vedo lo stesso indirizzo pubblico assegnato dal router di casa. Nel frattempo la jump box su 10.20.0.4 risponde e un nome di endpoint privato si risolve, quindi il tunnel non è rotto. Un gateway punto a sito fa esattamente ciò che dice la sua configurazione predefinita: trasporta i prefissi privati e lascia tutto il resto sul collegamento locale. Ottenere un indirizzo di uscita di proprietà di Azure è un cambio di progettazione del routing, non una riparazione.

Cosa annuncia il gateway per impostazione predefinita

Il gateway distribuisce route per lo spazio degli indirizzi della rete virtuale, più le reti con peering dove è consentito il transito del gateway e i prefissi locali appresi tramite una connessione site-to-site o BGP. Non c'è alcun 0.0.0.0/0 in quell'insieme. Il tuo sistema operativo mantiene la route predefinita su Wi-Fi o Ethernet, quindi un pacchetto verso un'API pubblica non entra mai nel tunnel.

L'indirizzo che un client riceve dentro il tunnel è un lease privato dal pool punto a sito. Identifica il client verso le risorse nella VNet; non è un indirizzo che internet può vedere e non apparirà mai come origine di una richiesta in uscita verso un'API SaaS. Una voce di elenco consentiti costruita attorno a quel lease non può funzionare, per quanto tu aspetti che compaia nei log del fornitore.

Tunnel diviso e tunneling forzato fianco a fianco

Solo la seconda riga cambia l'indirizzo che vede un servizio remoto. Tutto il resto in quella tabella è costo e superficie operativa che accetti quando l'uscita deve essere ispezionata o tradotta dentro Azure. Se qualcuno ti chiede di far cambiare l'IP pubblico, sta chiedendo l'intera colonna di destra, non una piccola modifica al client.

C'è un'opzione intermedia che vale la pena nominare prima di ricostruire qualcosa. Una VM proxy o gateway dentro la VNet ti dà un indirizzo di origine controllato per le applicazioni che possono essere indirizzate lì, senza spostare la route predefinita del client. Questo mantiene la navigazione normale in locale e soddisfa comunque un partner che ha bisogno solo di una chiamata API proveniente da Azure. Fallisce quando il requisito riguarda davvero tutto il traffico, perché qualunque cosa ignori l'impostazione del proxy esce comunque localmente.

Fai portare al tunnel la route predefinita

Su un gateway di rete virtuale, il modo supportato per indirizzare tutto il traffico internet del client nel tunnel è aggiungere route personalizzate alla configurazione punto a sito. Due metà coprono tutto lo spazio IPv4, e ciascuna è più specifica della route predefinita locale, quindi il client le preferisce senza cancellare nulla:

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

Quella riga è illustrativa e non completa da copiare e incollare: recupera prima l'oggetto del gateway con Get-AzVirtualNetworkGateway e sostituiscilo a GWOBJ, e conferma che lo SKU e il modello di distribuzione accettino route personalizzate prima di eseguirlo. Gli stessi prefissi compaiono nel portale nella pagina di configurazione punto a sito, che è il posto più sicuro per impostarli se non stai già automatizzando il gateway.

Cambiare quei prefissi invalida il pacchetto client. Scarica di nuovo il pacchetto client VPN e reinstallalo, perché le route viaggiano dentro il profilo. Un client che si riconnette con il vecchio profilo mantiene il vecchio insieme di route, e puoi perdere un'ora a fare debug di una modifica che non gli è mai arrivata.

In un hub WAN virtuale protetto l'equivalente è una route predefinita nella tabella delle route dell'hub associata al gateway punto a sito, con Azure Firewall nell'hub che prende il traffico. Il firewall traduce le connessioni verso internet nei propri indirizzi IP pubblici, ed è da quella traduzione che viene il nuovo indirizzo di uscita. Quando un firewall ha più IP pubblici, qualsiasi di essi può comparire come origine, quindi un elenco consentiti deve contenerli tutti.

Entrambe le progettazioni sopra sono IPv4. I due prefissi /1 non fanno nulla per IPv6, e il supporto IPv6 punto a sito è abbastanza limitato da dover testare la combinazione prima di promettere parità.

Controlla la route, poi l'uscita

Dopo aver reinstallato il pacchetto e riconnesso, conferma che il client abbia effettivamente installato le metà. Su Windows, Get-NetRoute -DestinationPrefix 0.0.0.0/1 e la stessa query per 128.0.0.0/1 dovrebbero nominare l'interfaccia del tunnel, e route print mostra entrambe accanto alla tua route predefinita originale. Su Linux, ip route show deve elencare i due prefissi; se non lo fa, il profilo non li ha mai trasportati.

Poi ricontrolla l'indirizzo pubblico dal client e leggi il log del firewall per la stessa connessione. L'origine dovrebbe essere l'IP pubblico del firewall con una porta tradotta. Un client che esce ancora localmente mentre esistono entrambe le route significa che i pacchetti hanno raggiunto Azure e sono usciti per un'altra strada: una route definita dall'utente sulla subnet del gateway, un firewall esso stesso forzato in tunnel verso la rete locale, o un criterio che scarta il flusso prima della traduzione.

Riprova una destinazione privata nella stessa sessione. Un jump host che smette di rispondere dopo la modifica è il segno abituale che i nuovi prefissi hanno spostato qualcosa, o una route locale più stretta che prima veniva annunciata o la risoluzione dei nomi che ora va a un resolver senza forwarder per le tue zone private.

Quando lasciare in pace il tunnel diviso

Se l'obiettivo è solo raggiungere un'API privata, un endpoint privato o una pagina di amministrazione interna, il comportamento predefinito è più economico e più silenzioso. Il tunneling forzato aggiunge ore di firewall e costi di elaborazione dei dati, un percorso più lungo e un altro punto in cui ogni flusso client può fallire. Cattura anche molto più traffico dell'unica destinazione che ti interessava.

Ricorri ad esso quando il requisito è formulato in termini di uscita: un partner deve vedere un indirizzo Azure fisso, la sicurezza vuole le connessioni registrate e ispezionate, o i dati devono uscire attraverso un unico punto controllato. Anche allora la progettazione dà a ogni utente un'uscita condivisa, quindi la responsabilità per utente deve venire dall'identità nell'applicazione e non dall'indirizzo di origine.

Prima di chiudere la modifica, conferma quattro cose: il pacchetto client installato è quello nuovo, le due route /1 sono sull'interfaccia del tunnel, una destinazione privata risponde ancora e il log del servizio remoto mostra l'indirizzo del firewall.