Azure S2S VPN tilkoblet men ingen trafikk: les IKE-loggen

Portalen sier Connected, tunnelen har en oppetidsteller, og et trace fra din virtuelle maskin dør på andre hopp. Tilkoblingsstatusen beskriver IKE- og IPsec-forhandlingen, ikke om én enkelt pakke overlever politikklaget på noen av sidene. To feil forklarer de fleste av disse sakene, og ingen av dem repareres ved å endre en Azure-rute. Begge er allerede skrevet ned i loggen som gatewayen produserte, og derfor starter jeg der i stedet for i rutetabellen.

Hva Connected egentlig attesterer

En tilkoblet site-to-site-forbindelse betyr at fase 1 og fase 2 er fullført og at sikkerhetsassosiasjonene er oppe. Det er en uttalelse om forhandlingen: begge partene ble enige om et forslag, utvekslet nøkler og installerte paret med SA-er. Den sier ingenting om hvorvidt trafikkvelgerne samsvarer med subnettene du tror er beskyttet, og ingenting om hvorvidt den fjerne siden vil rute pakken noe sted etter at den dekrypterer. En tunnel kan stå oppe i uker mens den slipper hver interessant strøm, og det er nøyaktig mønsteret som får folk til å bygge en sunn gateway på nytt.

De to feilene som er verdt å sjekke først, er en peer som foreslår AH i stedet for ESP, og et virtuelt nett som er nummerert i et område gatewayen ikke vil behandle som internt.

Åpne den eksporterte loggen før du rører ruter

I portalen åpner du gatewayen for det virtuelle nettet og kjører VPN troubleshoot-operasjonen mot tilkoblingen, og laster deretter ned pakken den lager og pakker den ut. Inni ligger en IKE-logg med fase 1- og fase 2-utvekslingene, med tidsstempler og lesbar som ren tekst. Søk i den etter transform-linjen i stedet for å lese fra toppen og ned, fordi den interessante oppføringen vanligvis er noen hundre linjer inne. Har du ikke portaltilgang, vises de samme diagnosene i loggdestinasjonen til gatewayen når diagnoseinnstillingene er slått på.

To oppføringer bærer mesteparten av verdien. Den første lyder omtrent expected ESP with combined authentication and cipher, received AH. Den andre er en ugyldig payload-feil under IKE-utvekslingen, som vanligvis betyr et feilformet eller ikke støttet forslagsfelt.

Begge beskriver hva den lokale enheten tilbød, så begge er innstillinger på peer-siden. Å gjenopprette Azure-siden av tilkoblingen endrer ikke forslaget brannmuren din sender, og å gjøre det likevel er den mest bortkastede timen i denne arbeidsflyten. På peeren setter du fase 2 til ESP med kombinert autentisering og cipher og lar den forhandle algoritmen, og sjekker deretter om en leverandøravkrysning med et navn som combined mode i det stille velger et AH-forslag under.

Bekreft adresserommet til det virtuelle nettet

Gatewayen forventer at det virtuelle nettet ligger i private områder. Et nett som er nummerert i en offentlig blokk, for eksempel et som starter med 111.x, kan få tunnelen opp mens Azure nekter å behandle området som internt, slik at tilkoblingen ser sunn ut og ingen strøm godtas. Bekreft adresserommet før du bruker en ettermiddag på velgere. Er nummereringen et hardt krav fra en eldre tildeling, er rettelsen en endring av adresseplanen og ikke en annen gateway.

Noter overlappen med de lokale områdene mens du er i adresseromsbladet, fordi overlappende prefikser gir en annen feil som ser lik ut fra klienten.

Kontroller prefiksene i begge retninger

Ressursen for den lokale nettverksgatewayen holder de lokale prefiksene, og de må samsvare med subnettene den eksterne enheten faktisk beskytter. Et sammendrag som inneholder adresser enheten slipper, vil slippe noen strømmer gjennom og feile på andre, noe som leses som en periodisk rutefeil snarere enn en konfigurasjonsavvik. Sjekk den fjerne siden også: den ene enden lister et /16 mens den andre lister tre /24 inni det — det er den klassiske delvise feilen. Ingen av listene er autoritative alene, så sammenlign dem side om side i stedet for å stole på den du kan se.

En prefiksendring fanges ikke alltid opp av seg selv, så planlegg å lagre eller gjenopprette tilkoblingsobjektet på nytt og bekreft deretter at de nye prefiksene vises på begge sider.

Test en vei, ikke en ping

Traceet som skiller en fungerende tunnel fra en fungerende rute ser slik ut: første hopp er den lokale gatewayen, deretter noen hopp som ikke svarer, deretter svarer den eksterne verten. Når traceet aldri når verten, tester du TCP-porten applikasjonen faktisk bruker, fordi ICMP filtreres ofte nok til at en mislykket ping beviser svært lite. Kjør det samme traceet fra en ekstern vert mot en virtuell maskin i Azure. Asymmetrien mellom de to resultatene er den raskeste måten å finne en manglende returrute eller en regel som bare tillater én retning.

Skriv peerens forslag, begge adresserommene og tidspunktet for opprettelsen av tilkoblingen i saken, slik at neste ingeniør vet hvilke verdier som ble bygget på nytt og hvilke som aldri ble rørt.

Hvis loggen kommer tom tilbake, kan det hende gatewayen ikke avslutter tilkoblingen din i det hele tatt. Bekreft at peer-adressen på den lokale nettverksgatewayen samsvarer med enheten du leser loggen fra, fordi to gatewayer i ett abonnement lett forveksles under en gjenoppbygging. Den feilen koster en dag og etterlater ingen spor i noen logg.