Azure site-naar-site VPN met een peer achter NAT: checklist

Werk deze controles in volgorde af en stop bij de eerste die mislukt. De meeste meldingen dat Azure een apparaat achter NAT niet ondersteunt, blijken een peer-adres te zijn dat Azure niet kan bereiken, of een tunnel die nooit vanaf de juiste kant wordt gestart. Het buitenste transport en de interne routering zijn twee verschillende problemen, en ze door elkaar halen kost een middag. Elke stap hieronder levert een waarneming op die je aan iemand anders kunt geven.

Stap 1: bevestig dat de peer überhaupt achter NAT zit

Vergelijk het adres op de WAN-interface van het apparaat met het adres dat Azure ervoor ziet. Als ze verschillen, vertaalt er iets, en die vertaler maakt nu deel uit van je VPN-ontwerp. Vraag de provider of de mapping statisch of gedeeld is, want een gedeelde mapping verandert waarop je kunt vertrouwen. Een apparaat met een privé-WAN-adres en zonder doorsturing is een ander geval dan een apparaat achter een carrier-grade NAT met een stabiele openbare mapping.

Als de twee adressen overeenkomen, stop dan hier: NAT is niet je probleem en de rest van deze lijst helpt niet.

Noteer beide adressen en het model van de vertaler in het ticket. Die ene regel voorkomt de volgende ronde vragen waarom de geconfigureerde peer niet antwoordt.

Stap 2: spreek af wie initieert

De Azure VPN Gateway FAQ vermeldt NAT-T-ondersteuning en voegt toe dat het on-premises apparaat de IPsec-tunnel moet initiëren wanneer het achter NAT staat. Dat komt overeen met hoe stateful vertaling werkt, omdat de vertaler een mapping aanhoudt doordat het interne apparaat het eerste pakket heeft verzonden. Als Azure wordt geacht te initiëren en er komt niets om die mapping te maken, begint de tunnel nooit.

Configureer de peer zo dat een alleen-responder-fout duidelijk is, en controleer of het apparaat zelf opnieuw probeert of een trigger nodig heeft. Sommige apparaten brengen een tunnel alleen op als er interessant verkeer verschijnt, wat prima is totdat het interessante verkeer een gezondheidsprobe is die nooit komt.

Kijk mee naar de IKE-uitwisseling op het apparaat tijdens een handmatige initiatie; stilte daar is een antwoord van routering of firewall, niet een antwoord van Azure.

Stap 3: krijg het peer-adres goed

Azure heeft een bereikbaar openbaar adres nodig voor de peer in zijn lokale netwerkgateway-object, meestal het openbare adres van de vertaler in plaats van het interne adres van het apparaat. De identiteit waarmee het apparaat zich authenticeert is een apart veld en mag legitiem afwijken van het adres dat Azure belt. Houd de twee uit elkaar, want ze verwisselen levert een authenticatiefout op die er precies als een NAT-probleem uitziet.

Als het openbare adres verandert, moet dat object mee veranderen. Een naam die naar een verouderd adres verwijst is erger dan een statisch adres dat je handmatig moet bijwerken.

Schrijf alle drie de waarden op: lokaal adres van het apparaat, vertaald openbaar adres, geconfigureerde peer-identiteit.

Stap 4: open alleen de poorten die NAT-T nodig heeft

NAT-T draagt ESP in UDP, en RFC 3948 beschrijft die inkapseling met poort 4500 die na de eerste onderhandeling op poort 500 wordt gebruikt. Je firewall en de vertaler moeten beide de uitwisseling en het retourverkeer toestaan. Een ongerelateerde TCP-poort toestaan bewijst niets over dit pad, en een regel die uitgaand toestaat maar het antwoord niet, faalt nog steeds.

Een statische doorsturing van een inkomende poort is niet automatisch nodig wanneer de peer initieert en de vertaler status bijhoudt. Die wordt nodig wanneer de mapping onstabiel is of wanneer iets op het pad de status agressief laat verlopen.

Leg één keer vast aan beide zijden van de vertaler; het verschil in inkapseling is meteen zichtbaar.

Stap 5: scheid het buitenste transport van de interne routering

Een tunnel die tot stand komt en niets vervoert, is een routeringsprobleem, geen NAT-T-probleem. De sites hebben nog steeds compatibele verkeersselectoren, overeenkomende adresruimtes, toegangsregels en een retourpad voor de applicatienetwerken nodig. Niets daarvan levert een geslaagde IKE-uitwisseling.

Als de twee sites overlappende privébereiken gebruiken, is vertaling binnen de tunnel een apart ontwerp met eigen regels. Nummer een subnet niet opnieuw omdat de buitenste gateway toevallig achter een thuisrouter staat.

Classificeer de storing per fase voordat je iets wijzigt, en houd die classificatie in het ticket zodat de volgende persoon begint waar jij stopte.