Azure S2S VPN ansluten men ingen trafik: läs IKE-loggen

Portalen säger Connected, tunneln har en drifttidsräknare, och en trace från din virtuella maskin dör på andra hoppet. Anslutningsstatusen beskriver IKE- och IPsec-förhandlingen, inte om ett enda paket överlever policy-lagret på någon av sidorna. Två fel förklarar de flesta av dessa ärenden, och inget av dem åtgärdas genom att ändra en Azure-rutt. Båda står redan i loggen som gatewayen producerade, och därför börjar jag där i stället för i rutttabellen.

Vad Connected egentligen intygar

En ansluten site-to-site-anslutning innebär att fas 1 och fas 2 är slutförda och att säkerhetsassociationerna är uppe. Det är ett påstående om förhandlingen: båda parterna enades om ett förslag, utbytte nycklar och installerade paret SA. Det säger ingenting om huruvida trafikväljarna stämmer med de subnät du tror är skyddade, och ingenting om huruvida den bortre sidan kommer att routa paketet någonstans efter att ha dekrypterat det. En tunnel kan stå uppe i veckor medan den släpper varje intressant flöde, och det är precis det mönstret som får folk att bygga om en frisk gateway.

De två fel som är värda att kontrollera först är en peer som föreslår AH i stället för ESP, och ett virtuellt nät som är numrerat i ett område som gatewayen inte behandlar som internt.

Öppna den exporterade loggen innan du rör rutter

Öppna den virtuella nätverksgatewayen i portalen och kör VPN troubleshoot-åtgärden mot anslutningen, ladda sedan ner paketet den skapar och packa upp det. Inuti finns en IKE-logg med fas 1- och fas 2-utbytena, med tidsstämplar och läsbar som vanlig text. Sök i den efter transform-raden i stället för att läsa uppifrån och ner, eftersom den intressanta posten oftast ligger några hundra rader in. Har du ingen portalåtkomst visas samma diagnostik i gatewayens loggdestination när diagnostikinställningarna är påslagna.

Två poster bär merparten av värdet. Den första lyder ungefär expected ESP with combined authentication and cipher, received AH. Den andra är ett ogiltigt payload-fel under IKE-utbytet, vilket oftast betyder ett felformat eller icke stött förslagsfält.

Båda beskriver vad den lokala enheten erbjöd, så båda är inställningar på peer-sidan. Att återskapa Azure-sidan av anslutningen ändrar inte det förslag som din brandvägg skickar, och att göra det ändå är den mest bortkastade timmen i det här arbetet. På peeren ställer du in fas 2 på ESP med kombinerad autentisering och chiffer och låter den förhandla fram algoritmen, och kontrollerar sedan om en leverantörs kryssruta med namn som combined mode i tysthet väljer ett AH-förslag under.

Bekräfta det virtuella nätets adressutrymme

Gatewayen förväntar sig att det virtuella nätet ligger i privata intervall. Ett nät som är numrerat i ett publikt block, till exempel ett som börjar med 111.x, kan få tunneln upp medan Azure vägrar behandla det utrymmet som internt, så anslutningen ser frisk ut och inget flöde accepteras. Bekräfta adressutrymmet innan du lägger en eftermiddag på väljare. Om numreringen är ett hårt krav från en äldre tilldelning är rättelsen en ändring av adressplanen och inte en annan gateway.

Notera överlappningen med de lokala intervallen medan du är i bladet för adressutrymmet, eftersom överlappande prefix ger ett annat fel som ser likadant ut från klienten.

Kontrollera prefixen i båda riktningarna

Resursen för den lokala nätverksgatewayen innehåller de lokala prefixen, och de måste stämma med de subnät som den fjärranslutna enheten faktiskt skyddar. En sammanfattning som innehåller adresser som enheten släpper kommer att släppa igenom vissa flöden och misslyckas på andra, vilket läses som ett intermittent routningsfel snarare än en konfigurationsavvikelse. Kontrollera den bortre sidan också: ena änden listar ett /16 medan den andra listar tre /24 inuti det — det är det klassiska delvisa felet. Ingen av listorna är auktoritativ på egen hand, så jämför dem sida vid sida i stället för att lita på den du kan se.

En prefixändring fångas inte alltid upp av sig själv, så planera att spara eller återskapa anslutningsobjektet igen och bekräfta sedan att de nya prefixen syns på båda sidorna.

Testa en väg, inte en ping

Trace som skiljer en fungerande tunnel från en fungerande rutt ser ut så här: första hoppet är den lokala gatewayen, sedan några hopp som inte svarar, sedan svarar den bortre värden. Om trace aldrig når värden ska du testa den TCP-port som applikationen faktiskt använder, eftersom ICMP filtreras tillräckligt ofta för att en misslyckad ping ska bevisa mycket lite. Kör samma trace från en bortre värd mot en virtuell maskin i Azure. Asymmetrin mellan de två resultaten är det snabbaste sättet att hitta en saknad returväg eller en regel som bara tillåter en riktning.

Skriv peerens förslag, båda adressutrymmena och tiden då anslutningen skapades i ärendet, så att nästa ingenjör vet vilka värden som byggdes om och vilka som aldrig rördes.

Om loggen kommer tillbaka tom kan gatewayen mycket väl inte avsluta din anslutning alls. Bekräfta att peer-adressen på den lokala nätverksgatewayen stämmer med enheten som du läser loggen från, eftersom två gatewayer i en prenumeration lätt blandas ihop vid en ombyggnad. Det felet kostar en dag och lämnar inga spår i någon logg.