Azure plats-till-plats-VPN med en peer bakom NAT: checklista

Gå igenom dessa kontroller i ordning och stanna vid den första som misslyckas. De flesta rapporter om att Azure inte stöder en enhet bakom NAT visar sig vara en peer-adress som Azure inte når, eller en tunnel som aldrig initieras från rätt sida. Den yttre transporten och den inre routningen är två olika problem, och att blanda dem kostar en eftermiddag. Varje steg nedan ger en observation som du kan lämna vidare till någon annan.

Steg 1: bekräfta att peeren över huvud taget är bakom NAT

Jämför adressen på enhetens WAN-gränssnitt med adressen som Azure ser för den. Om de skiljer sig översätter något, och den översättaren är nu en del av din VPN-design. Fråga leverantören om mappningen är statisk eller delad, eftersom en delad mappning ändrar vad du kan förlita dig på. En enhet med privat WAN-adress och utan vidarebefordran är ett annat fall än en bakom en carrier-grade NAT med en stabil offentlig mappning.

Om de två adresserna stämmer överens, stanna här: NAT är inte ditt problem och resten av listan hjälper inte.

Skriv ned båda adresserna och översättarens modell i ärendet. Den enda raden förhindrar nästa runda frågor om varför den konfigurerade peeren inte svarar.

Steg 2: kom överens om vem som initierar

Azure VPN Gateway FAQ anger stöd för NAT-T och tillägger att den lokala enheten bör initiera IPsec-tunneln när den sitter bakom NAT. Det stämmer med hur tillståndsbaserad översättning fungerar, eftersom översättaren håller en mappning därför att den inre enheten skickade det första paketet. Om Azure förväntas initiera och ingenting kommer för att skapa den mappningen, startar tunneln aldrig.

Konfigurera peeren så att ett misstag med enbart svarande är uppenbart, och kontrollera om enheten försöker igen själv eller behöver en trigger. Vissa enheter reser en tunnel först när intressant trafik dyker upp, vilket är bra tills den intressanta trafiken är en hälsoprob som aldrig kommer.

Titta på IKE-utbytet på enheten under en manuell initiering; tystnad där är ett routing- eller brandväggssvar, inte ett Azure-svar.

Steg 3: få peer-adressen rätt

Azure behöver en nåbar offentlig adress för peeren i objektet för den lokala nätverksgatewayen, vanligtvis översättarens offentliga adress i stället för enhetens inre adress. Identiteten som enheten autentiserar sig med är ett separat fält och kan med rätta skilja sig från adressen som Azure ringer. Håll de två åtskilda, eftersom att byta dem ger ett autentiseringsfel som ser exakt ut som ett NAT-problem.

Om den offentliga adressen ändras måste det objektet ändras med den. Ett namn som löses till en inaktuell adress är sämre än en statisk adress som du måste uppdatera manuellt.

Skriv ned alla tre värdena: enhetens lokala adress, den översatta offentliga adressen och den konfigurerade peer-identiteten.

Steg 4: öppna bara de portar NAT-T behöver

NAT-T bär ESP inuti UDP, och RFC 3948 beskriver den inkapslingen med port 4500 som används efter den inledande förhandlingen på port 500. Din brandvägg och översättaren måste båda tillåta utbytet och dess returtrafik. Att tillåta en orelaterad TCP-port bevisar ingenting om den här vägen, och en regel som tillåter utgående men inte svaret misslyckas ändå.

Statisk vidarebefordran av inkommande port är inte automatiskt nödvändig när peeren initierar och översättaren håller tillstånd. Det blir nödvändigt när mappningen är instabil eller när något på vägen låter tillståndet gå ut aggressivt.

Fånga en gång på båda sidor av översättaren; skillnaden i inkapsling syns direkt.

Steg 5: skilj yttre transport från inre routning

En tunnel som etableras och inte bär något är ett routingproblem, inte ett NAT-T-problem. Platserna behöver fortfarande kompatibla trafikväljare, matchande adressutrymmen, åtkomstregler och en returväg för applikationsnäten. Inget av det levereras av ett lyckat IKE-utbyte.

Om de två platserna använder överlappande privata intervall är översättning inne i tunneln en separat design med egna regler. Numrera inte om ett subnät bara för att den yttre gatewayen råkar stå bakom en hemrouter.

Klassificera felet per steg innan du ändrar något, och behåll den klassificeringen i ärendet så att nästa person börjar där du slutade.