Twee openbare IP's op één Azure VPN-VM: welke doet wat

Twee openbare IP's op één Azure VPN-VM scheppen een verwachting die zelden uitkomt: het adres waarop clients verbinden, is ook het adres dat websites zien. Drie onafhankelijke beslissingen leveren dat resultaat, en alleen de eerste gaat over de tunnel-listener. De tweede is de gastbron voor doorgestuurd clientverkeer, en de derde is de Azure-uitgangsmethode die op die bron van toepassing is. Verander er één en de andere twee blijven waar ze waren, dus beslis elk expliciet.

Beslissing 1: waar de tunnel eindigt

Een openbaar Azure-IP is gekoppeld aan een privé-IP-configuratie op de NIC; het is geen adres dat u in het gastbesturingssysteem toevoegt. Lees de koppeling in plaats van haar aan te nemen: az network nic show --ids /subscriptions/.../networkInterfaces/vpn-nic --query 'ipConfigurations[].{private:privateIPAddress,public:publicIPAddress.id}'. Welk privéadres die query ook teruggeeft, dat is het adres dat de gast daadwerkelijk moet hebben.

Eén NIC kan meerdere IP-configuraties dragen, dus twee openbare adressen vereisen geen twee NIC's. Als het ontwerp toch twee NIC's gebruikt, brengt elk zijn eigen gastroutes en volgende hops mee, en hebt u een routeringsbeslissing toegevoegd in plaats van er een te vereenvoudigen.

Voor een dienst met een expliciete lokale binding bindt u aan het werkelijke privéadres van de gast, nooit aan de openbare plaatsaanduiding. Een listener die alle adressen accepteert, ontvangt verkeer via elke IP-configuratie die hem bereikt, dus beperk de ingang met de netwerkbeveiligingsgroep en de hostfirewall in plaats van te hopen dat de bindingsvolgorde beslist.

Beslissing 2: welke bron de doorgestuurde client gebruikt

Nadat de gateway een clientverzoek heeft ontsleuteld, is het pakket dat zij doorstuurt anders dan het pakket dat bij de VPN-listener aankwam. De gast heeft doorgifte ingeschakeld nodig, een firewallbeleid dat de stroom toestaat, en een bronadres dat het cloudontwerp toestaat. Als u het interne clientadres vertaalt, is die vertaalde bron degene die Azure evalueert, niet het interne adres van de client.

Een smalle SNAT-regel kan een privé gastbron kiezen, maar kan een latere Azure-vertaling niet overrulen. Kies SNAT wanneer u verantwoording per client binnen de VM nodig hebt; sla het over wanneer het uitgaande ontwerp van het subnet al een stabiele openbare bron biedt en een tweede vertaling alleen toestand zou toevoegen.

Beslissing 3: welke Azure-uitgangsmethode wint

Microsoft documenteertde voorrangsorde voor uitgaand verkeer: een toepasselijke route naar een apparaat of gateway heeft voorrang, en subnet-NAT Gateway-connectiviteit heeft voorrang boven een openbaar IP op instansniveau op het relevante pad. Die volgorde is de reden waarom vertaling naar 10.20.0.5 niet bewijst dat een website 198.51.100.20 zal zien. Lees de effectieve routetabel, de NAT Gateway-koppeling en het openbare IP van de NIC samen voordat u het uitgangsontwerp accepteert.

Houdde doorgifte-instelling van de Azure-NICgescheiden van doorgifte in Linux. De cloudvlag staat pakketten toe waarvan de bron of bestemming niet aan de NIC is toegewezen; hij schakelt net.ipv4.ip_forward niet in, en de gastinstelling verleent geen cloudtoestemming.

De tunnelsocket heeft zijn eigen bronbeslissing

De Address van WireGuard onder wg-quick wijst een adres toe aan de WireGuard-interface; het is geen instructie voor externe UDP-binding. De bron van de versleutelde socket volgt de routetabel, dus een beleidsroute of een tweede standaardroute kan hem verplaatsen zonder het interfaceadres aan te raken.OpenVPN: de optie local en UDP multihome gedragen zich hetzelfde: ze betreffen de listener en zijn antwoorden, niet de internetbron van elke doorgestuurde client.

Behoud de onderliggende route die de tunnel draagt, en bevestig dat de client nog steeds geauthenticeerde antwoorden van de verwachte ingangsopstelling ontvangt. Vertrouw niet op de volgorde van de adressenlijst als permanent bronselectiebeleid, want het volgende adres dat aan de NIC wordt toegevoegd kan veranderen welke wint.

Wat te accepteren, en in welke volgorde

Accepteer drie resultaten afzonderlijk. Ten eerste bereikt een externe client de bedoelde VPN-ingang. Ten tweede verlaat een nieuw toegestaan verzoek van die VPN-client de gedocumenteerde internetuitgang. Ten derde blijven onbedoelde listener- en doorgifteroutes geweigerd. Leg de koppelingen van openbaar naar privé en de gast- en cloudverantwoordelijken van elke beslissing op dezelfde plaats vast.

Een geslaagde tunnel bewijst alleen het eerste deel. Test de uitgang met een nieuwe stroom, want een gecachte verbinding kan de oude bron nog lang na de routewijziging blijven gebruiken.