S2S VPN i Azure er forbundet men uden trafik: læs IKE-loggen

Portalen siger Connected, tunnelen har en oppetidstæller, og et trace fra din virtuelle maskine dør på andet hop. Forbindelsestilstanden beskriver IKE- og IPsec-forhandlingen, ikke om en enkelt pakke overlever politiklaget på nogen af siderne. To fejl forklarer de fleste af disse sager, og ingen af dem repareres ved at ændre en Azure-rute. Begge er allerede skrevet ned i loggen, som gatewayen har produceret, og derfor starter jeg der i stedet for i rutetabellen.

Hvad Connected egentlig attesterer

En forbundet site-to-site-forbindelse betyder, at fase 1 og fase 2 er gennemført og at sikkerhedsassociationerne er oppe. Det er en udtalelse om forhandlingen: begge parter blev enige om et forslag, udvekslede nøgler og installerede parret af SA'er. Det siger intet om, hvorvidt trafikvælgerne matcher de undernet, du tror er beskyttet, og intet om, hvorvidt den fjerne side vil route pakken nogen steder hen efter dekryptering. En tunnel kan stå oppe i ugevis, mens den dropper hver eneste interessante strøm, og det er præcis mønstret, der får folk til at genopbygge en sund gateway.

De to fejl, der er værd at tjekke først, er en peer, der foreslår AH i stedet for ESP, og et virtuelt netværk, der er nummereret i et rum, som gatewayen ikke vil behandle som internt.

Åbn den eksporterede log, før du rører ruter

Åbn det virtuelle netværks gateway i portalen, og kør VPN troubleshoot-handlingen mod forbindelsen, og download derefter den pakke, den producerer, og pak den ud. Indeni er en IKE-log med fase 1- og fase 2-udvekslingerne, tidsstemplet og læsbar som almindelig tekst. Søg i den efter transform-linjen i stedet for at læse fra top til bund, fordi den interessante post normalt er nogle hundrede linjer inde. Har du ikke adgang til portalen, vises de samme diagnostikdata i gatewayens logdestination, når diagnostikindstillingerne er aktiveret.

To poster bærer det meste af værdien. Den første lyder omtrent expected ESP with combined authentication and cipher, received AH. Den anden er en ugyldig payload-fejl under IKE-udvekslingen, hvilket normalt betyder et forkert udformet eller ikke-understøttet forslagsfelt.

Begge beskriver, hvad den lokale enhed tilbød, så begge er indstillinger på peer-siden. At genskabe Azure-siden af forbindelsen ændrer ikke det forslag, din firewall sender, og at gøre det alligevel er den mest almindelige spildte time i dette arbejdsforløb. På peeren sætter du fase 2 til ESP med kombineret godkendelse og cipher og lader den forhandle algoritmen, og derefter tjekker du, om et leverandør-afkrydsningsfelt med et navn som combined mode i det stille vælger et AH-forslag nedenunder.

Bekræft det virtuelle netværks adresserum

Gatewayen forventer, at det virtuelle netværk ligger i private områder. Et netværk, der er nummereret i en offentlig blok, for eksempel et der starter med 111.x, kan få tunnelen op, mens Azure nægter at behandle det rum som internt, så forbindelsen ser sund ud, og ingen strøm accepteres. Bekræft adresserummet, før du bruger en eftermiddag på vælgere. Er nummereringen et hårdt krav fra en ældre tildeling, er rettelsen en ændring af adresseplanen og ikke en anden gateway.

Notér overlapningen med de lokale områder, mens du er i adresserumsbladet, fordi overlappende præfikser giver en anden fejl, der ser ens ud fra klienten.

Kontrollér præfikserne i begge retninger

Ressourcen for den lokale netværksgateway holder de lokale præfikser, og de skal matche de undernet, som den eksterne enhed faktisk beskytter. Et resumé, der indeholder adresser, som enheden dropper, vil slippe nogle strømme igennem og fejle på andre, hvilket læses som en periodisk rutefejl snarere end en konfigurationsuoverensstemmelse. Tjek også den fjerne side: den ene ende lister et /16, mens den anden lister tre /24 indeni det — det er den klassiske delvise fejl. Ingen af listerne er autoritative alene, så sammenlign dem side om side i stedet for at stole på den, du kan se.

En præfiksændring fanges ikke altid af sig selv, så planlæg at gemme eller genskabe forbindelsesobjektet igen og derefter bekræfte, at de nye præfikser vises på begge sider.

Test en vej, ikke en ping

Det trace, der skiller en fungerende tunnel fra en fungerende rute, ser sådan ud: første hop er den lokale gateway, derefter et par hop uden svar, derefter svarer den eksterne vært. Når trace aldrig når værten, skal du teste den TCP-port, som applikationen faktisk bruger, fordi ICMP filtreres ofte nok til, at en mislykket ping beviser meget lidt. Kør det samme trace fra en ekstern vært mod en virtuel maskine i Azure. Asymmetri mellem de to resultater er den hurtigste måde at finde en manglende returrute eller en regel, der kun tillader én retning.

Skriv peerens forslag, begge adresserum og forbindelsens oprettelsestid i sagen, så den næste ingeniør ved, hvilke værdier der blev genopbygget, og hvilke der aldrig blev rørt.

Hvis loggen kommer tom tilbage, terminerer gatewayen muligvis slet ikke din forbindelse. Bekræft, at peer-adressen på den lokale netværksgateway matcher den enhed, du læser loggen fra, fordi to gateways i ét abonnement er lette at forveksle under en genopbygning. Den fejl koster en dag og efterlader intet spor i nogen log.