Waarom Azure Point-to-Site VPN je publieke IP niet verandert

Ik verbind de Azure VPN-client op een Windows-laptop, open een adres-echopagina en zie hetzelfde publieke adres dat mijn thuisrouter heeft uitgegeven. Ondertussen antwoordt de jumpbox op 10.20.0.4 en wordt een naam van een privé-eindpunt omgezet, dus de tunnel is niet kapot. Een point-to-site-gateway doet precies wat de standaardconfiguratie zegt: de privépreflenzen worden vervoerd en al het andere blijft op de lokale link. Een uitgangsadres in eigendom van Azure krijgen is een wijziging van het routeringsontwerp, geen reparatie.

Wat de gateway standaard aankondigt

De gateway pusht routes voor de adresruimte van het virtuele netwerk, plus peernetwerken waar gateway-transit is toegestaan en on-premises preflenzen die via een site-to-site-verbinding of BGP zijn geleerd. In die set zit geen 0.0.0.0/0. Je besturingssysteem houdt zijn standaardroute op Wi-Fi of Ethernet, dus een pakket naar een publieke API komt nooit in de tunnel.

Het adres dat een client in de tunnel krijgt, is een privélease uit de point-to-site-pool. Het identificeert de client bij resources in de VNet; het is geen adres dat het internet kan zien, en het zal nooit verschijnen als de bron van een uitgaand verzoek naar een SaaS-API. Een allowlist-item rond die lease kan niet werken, hoe lang je ook wacht tot het in de leverancierslogs opduikt.

Split tunnel en geforceerde tunneling naast elkaar

Alleen de tweede rij verandert het adres dat een externe dienst ziet. Al het andere in die tabel is kosten en operationeel oppervlak dat je accepteert wanneer de uitgang binnen Azure moet worden geïnspecteerd of vertaald. Als iemand je vraagt om het publieke IP te laten veranderen, vraagt hij om de hele rechterkolom, niet om een kleine aanpassing aan de client.

Er is een tussenoptie die het noemen waard is voordat je iets herbouwt. Een proxy- of gateway-VM in de VNet geeft je een gecontroleerd bronadres voor de applicaties die erop kunnen worden gericht, zonder de standaardroute van de client te verplaatsen. Dat houdt normaal browsen lokaal en voldoet nog steeds aan een partner die maar één API-aanroep uit Azure nodig heeft. Het faalt wanneer de eis echt over al het verkeer gaat, want alles wat de proxy-instelling negeert, gaat nog steeds lokaal naar buiten.

Laat de tunnel de standaardroute dragen

Op een gateway voor virtuele netwerken is de ondersteunde manier om al het internetverkeer van de client de tunnel in te sturen het toevoegen van aangepaste routes aan de point-to-site-configuratie. Twee helften dekken de hele IPv4-ruimte, en elk is specifieker dan de lokale standaardroute, dus de client geeft ze voorrang zonder iets te verwijderen:

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

Die regel is illustratief en niet compleet om te kopiëren: haal eerst het gateway-object op met Get-AzVirtualNetworkGateway en vervang GWOBJ daardoor, en bevestig voordat je het uitvoert dat de SKU en het implementatiemodel aangepaste routes accepteren. Dezelfde preflenzen staan in de portal op de point-to-site-configuratiepagina, de veiligere plek om ze in te stellen als je de gateway nog niet script.

Het wijzigen van die preflenzen maakt het clientpakket ongeldig. Download het VPN-clientpakket opnieuw en installeer het opnieuw, want de routes reizen in het profiel mee. Een client die opnieuw verbindt met zijn oude profiel houdt de oude routeset, en je kunt een uur verliezen aan het debuggen van een wijziging die hem nooit bereikte.

In een beveiligde Virtual WAN-hub is het equivalent een standaardroute in de hub-routetabel die aan de point-to-site-gateway is gekoppeld, waarbij Azure Firewall in de hub het verkeer overneemt. De firewall vertaalt internetgebonden verbindingen naar zijn eigen publieke IP-adressen, en uit die vertaling komt het nieuwe uitgangsadres. Als een firewall meerdere publieke IP's heeft, kan elk daarvan als bron verschijnen, dus een allowlist moet ze allemaal bevatten.

Beide ontwerpen hierboven zijn IPv4. De twee /1-preflenzen doen niets voor IPv6, en de point-to-site-IPv6-ondersteuning is smal genoeg dat je de combinatie moet testen voordat je pariteit belooft.

Controleer de route en dan de uitgang

Bevestig na het opnieuw installeren van het pakket en opnieuw verbinden dat de client de helften echt heeft geïnstalleerd. Op Windows zouden Get-NetRoute -DestinationPrefix 0.0.0.0/1 en dezelfde query voor 128.0.0.0/1 de tunnelinterface moeten noemen, en route print toont beide naast je oorspronkelijke standaardroute. Op Linux moet ip route show de twee preflenzen vermelden; als dat niet gebeurt, heeft het profiel ze nooit gedragen.

Controleer daarna het publieke adres vanaf de client opnieuw en lees de firewalllog voor dezelfde verbinding. De bron zou het publieke IP van de firewall met een vertaalde poort moeten zijn. Een client die nog steeds lokaal naar buiten gaat terwijl beide routes bestaan, betekent dat pakketten Azure bereikten en via een andere weg vertrokken: een door de gebruiker gedefinieerde route op het gatewaysubnet, een firewall die zelf geforceerd naar het lokale netwerk is getunneld, of een beleid dat de stroom vóór de vertaling laat vallen.

Test één privébestemming opnieuw in dezelfde sessie. Een jumpserver die na de wijziging stopt met antwoorden is het gebruikelijke teken dat de nieuwe preflenzen iets hebben verdrongen, ofwel een nauwere lokale route die eerder werd aangekondigd ofwel naamresolutie die nu naar een resolver zonder forwarder voor je privézones gaat.

Wanneer je de split tunnel met rust laat

Als het doel alleen is om een privé-API, een privé-eindpunt of een interne beheerpagina te bereiken, is het standaardgedrag goedkoper en stiller. Geforceerde tunneling voegt firewalluren en kosten voor gegevensverwerking toe, een langere weg en nog een plek waar elke clientstroom kan falen. Het vangt ook veel meer verkeer dan de ene bestemming waar je je zorgen over maakte.

Grijp er alleen naar als de eis in termen van uitgang wordt gesteld: een partner moet een vast Azure-adres zien, beveiliging wil dat de verbindingen worden gelogd en geïnspecteerd, of gegevens moeten via één gecontroleerd punt naar buiten. Zelfs dan geeft het ontwerp elke gebruiker een gedeelde uitgang, dus verantwoording per gebruiker moet uit identiteit in de applicatie komen, niet uit het bronadres.

Bevestig vier dingen voordat je de wijziging sluit: het geïnstalleerde clientpakket is het nieuwe, de twee /1-routes staan op de tunnelinterface, een privébestemming antwoordt nog, en de log van de externe dienst toont het firewalladres.