Due IP pubblici su una sola VM VPN Azure: quale fa cosa

Due IP pubblici su una sola VM VPN Azure creano un'aspettativa che raramente si avvera: l'indirizzo a cui si connettono i client sarà anche l'indirizzo che vedono i siti web. Tre decisioni indipendenti producono quel risultato, e solo la prima riguarda l'ascoltatore del tunnel. La seconda è l'origine guest usata per il traffico client inoltrato, e la terza è il metodo di uscita di Azure che si applica a quell'origine. Cambiane una e le altre due restano dove erano, quindi decidi ciascuna esplicitamente.

Decisione 1: dove termina il tunnel

Un IP pubblico di Azure è associato a una configurazione IP privata sulla NIC; non è un indirizzo che aggiungi nel sistema operativo guest. Leggi la mappatura invece di presumerla: az network nic show --ids /subscriptions/.../networkInterfaces/vpn-nic --query 'ipConfigurations[].{private:privateIPAddress,public:publicIPAddress.id}'. Qualunque indirizzo privato restituisca quella query è quello che il guest deve realmente avere.

Una NIC può portare più configurazioni IP, quindi due indirizzi pubblici non richiedono due NIC. Se il progetto usa davvero due NIC, ognuna porta le proprie rotte guest e i propri hop successivi, e hai aggiunto una decisione di routing invece di semplificarne una.

Per un servizio con un binding locale esplicito, legati all'indirizzo privato reale del guest, mai al segnaposto pubblico. Un ascoltatore che accetta tutti gli indirizzi riceve traffico tramite ogni configurazione IP che lo raggiunge, quindi limita l'ingresso con il gruppo di sicurezza di rete e il firewall dell'host invece di sperare che decida l'ordine di binding.

Decisione 2: quale origine usa il client inoltrato

Dopo che il gateway ha decifrato una richiesta del client, il pacchetto che inoltra è diverso da quello arrivato all'ascoltatore VPN. Il guest necessita dell'inoltro abilitato, di una policy del firewall che consenta il flusso e di un indirizzo di origine che il progetto cloud consente. Se traduci l'indirizzo interno del client, è quell'origine tradotta che Azure valuterà, non l'indirizzo interno del client.

Una regola SNAT ristretta può scegliere un'origine privata del guest, ma non può prevalere su una traduzione Azure successiva. Scegli SNAT quando ti serve responsabilità per client dentro la VM; saltalo quando il progetto di uscita della subnet fornisce già un'origine pubblica stabile e una seconda traduzione aggiungerebbe solo stato.

Decisione 3: quale metodo di uscita Azure vince

Microsoft documental'ordine di precedenza dell'uscita: una rotta applicabile verso un apparato o un gateway ha la precedenza, e la connettività della subnet tramite NAT Gateway ha la precedenza su un IP pubblico a livello di istanza sul percorso interessato. Questo ordine è il motivo per cui tradurre verso 10.20.0.5 non prova che un sito vedrà 198.51.100.20. Leggi insieme la tabella di routing effettiva, l'associazione NAT Gateway e l'IP pubblico della NIC prima di accettare il progetto di uscita.

Tienil'impostazione di inoltro della NIC Azureseparata dall'inoltro di Linux. Il flag cloud consente pacchetti la cui origine o destinazione non è assegnata alla NIC; non abilita net.ipv4.ip_forward, e l'impostazione del guest non concede il permesso cloud.

Il socket del tunnel ha la propria decisione di origine

L'opzione Address di WireGuard sotto wg-quick assegna un indirizzo all'interfaccia WireGuard; non è un'istruzione di binding UDP esterno. L'origine del socket cifrato segue la tabella di routing, quindi una rotta di policy o una seconda rotta predefinita può spostarla senza toccare l'indirizzo dell'interfaccia.OpenVPN: l'opzione local e UDP multihome si comportano allo stesso modo: riguardano l'ascoltatore e le sue risposte, non l'origine internet di ogni client inoltrato.

Preserva la rotta di sotto che trasporta il tunnel e conferma che il client riceva ancora risposte autenticate dalla disposizione di ingresso prevista. Non affidarti all'ordine dell'elenco degli indirizzi come policy permanente di selezione dell'origine, perché il prossimo indirizzo aggiunto alla NIC può cambiare quale vince.

Cosa accettare, e in quale ordine

Accetta tre risultati separatamente. Primo, un client esterno raggiunge l'ingresso VPN previsto. Secondo, una nuova richiesta consentita da quel client VPN esce dall'uscita internet documentata. Terzo, i percorsi di ascolto e inoltro non voluti restano negati. Registra le corrispondenze pubblico-privato e i responsabili guest e cloud di ogni decisione nello stesso posto.

Un tunnel riuscito dimostra solo la prima parte. Prova l'uscita con un nuovo flusso, perché una connessione in cache può continuare a usare l'origine vecchia molto tempo dopo il cambio di rotta.