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

Portalen seier Connected, tunnelen har ein oppetidsteljar, og eit trace frå den virtuelle maskina di døyr på andre hoppet. Tilkoplingsstatusen skildrar IKE- og IPsec-forhandlinga, ikkje om ein einaste pakke overlever politikkaget på nokon av sidene. To feil forklarer dei fleste av desse sakene, og ingen av dei blir retta ved å endre ei Azure-rute. Begge er alt skrivne ned i loggen som gatewayen laga, og difor startar eg der i staden for i rutetabellen.

Kva Connected eigentleg stadfestar

Ei tilkopla site-to-site-forbinding tyder at fase 1 og fase 2 er fullførte og at tryggleiksassosiasjonane er oppe. Det er ei utsegn om forhandlinga: begge sidene vart samde om eit framlegg, bytte nøklar og installerte paret med SA-ar. Ho seier ingenting om trafikkveljarane stemmer med subnetta du trur er verna, og ingenting om den fjerne sida vil rute pakka noko stad etter at ho dekrypterer. Ein tunnel kan stå oppe i veker medan han slepp kvar interessant straum, og det er nett dette mønsteret som får folk til å byggje ein sunn gateway på nytt.

Dei to feila som er verd å sjekke fyrst, er ein peer som føreslår AH i staden for ESP, og eit virtuelt nett som er nummerert i eit område gatewayen ikkje vil handsame som internt.

Opne den eksporterte loggen før du rører ruter

I portalen opnar du gatewayen for det virtuelle nettet og køyrer VPN troubleshoot-operasjonen mot tilkoplinga, og lastar deretter ned pakka han lagar og pakkar ho ut. Inni ligg ein IKE-logg med fase 1- og fase 2-utvekslingane, med tidsstempel og lesbar som rein tekst. Søk i han etter transform-linja i staden for å lese frå toppen og ned, fordi den interessante oppføringa vanlegvis er nokre hundre linjer inne. Har du ikkje portaltilgang, viser dei same diagnosane seg i loggmålet til gatewayen når diagnoseinnstillingane er slått på.

To oppføringar ber mesteparten av verdien. Den fyrste lyder om lag expected ESP with combined authentication and cipher, received AH. Den andre er ein ugyldig payload-feil under IKE-utvekslinga, som vanlegvis tyder eit feilforma eller ikkje støtta framleggsfelt.

Begge skildrar kva den lokale eininga baud på, så begge er innstillingar på peer-sida. Å byggje Azure-sida av tilkoplinga på nytt endrar ikkje framlegget brannmuren din sender, og å gjere det likevel er den mest bortkasta timen i denne arbeidsflyten. På peeren set du fase 2 til ESP med kombinert autentisering og chiffer og lèt han forhandle algoritmen, og sjekkar deretter om ein leverandør-avkryssingsboks med eit namn som combined mode i det stille vel eit AH-framlegg under.

Stadfest adresserommet til det virtuelle nettet

Gatewayen ventar at det virtuelle nettet ligg i private område. Eit nett som er nummerert i ein offentleg blokk, til dømes eit som byrjar med 111.x, kan få tunnelen opp medan Azure nektar å handsame området som internt, slik at tilkoplinga ser sunn ut og ingen straum blir godteken. Stadfest adresserommet før du brukar ein ettermiddag på veljarar. Er nummereringa eit hardt krav frå ein eldre tildeling, er rettinga ei endring av adresseplanen og ikkje ein annan gateway.

Noter overlappinga med dei lokale områda medan du er i adresseromsbladet, fordi overlappande prefiks gir ein annan feil som ser lik ut frå klienten.

Kontroller prefiksa i båe retningar

Ressursen for den lokale nettverksgatewayen held dei lokale prefiksa, og dei må stemme med subnetta den fjerne eininga faktisk vernar. Eit samandrag som inneheld adresser eininga slepp, vil sleppe nokre straumar gjennom og feile på andre, noko som blir lese som ein periodisk rutefeil snarare enn eit konfigurasjonsavvik. Sjekk den fjerne sida òg: den eine enden listar eit /16 medan den andre listar tre /24 inni det — det er den klassiske delvise feilen. Ingen av listene er autoritative åleine, så samanlikn dei side om side i staden for å stole på den du kan sjå.

Ei prefiksendring blir ikkje alltid fanga opp av seg sjølv, så planlegg å lagre eller byggje tilkoplingsobjektet på nytt og stadfest deretter at dei nye prefiksa viser seg på båe sider.

Test ein veg, ikkje ein ping

Traceet som skil ein fungerande tunnel frå ei fungerande rute ser slik ut: fyrste hoppet er den lokale gatewayen, deretter nokre hopp som ikkje svarar, deretter svarar den fjerne verten. Når traceet aldri når verten, testar du TCP-porten applikasjonen faktisk brukar, fordi ICMP blir filtrert ofte nok til at ein mislykka ping beviser svært lite. Køyr det same traceet frå ein fjern vert mot ei virtuell maskin i Azure. Asymmetrien mellom dei to resultata er den snøggaste måten å finne ei manglande returrute eller ei regel som berre tillèt éin retning.

Skriv framlegget til peeren, båe adresseromma og tidspunktet for opprettinga av tilkoplinga i saka, slik at neste ingeniør veit kva verdiar som vart bygde på nytt og kva som aldri vart rørte.

Kjem loggen tom tilbake, kan det hende gatewayen ikkje avsluttar tilkoplinga di i det heile. Stadfest at peer-adressa på den lokale nettverksgatewayen stemmer med eininga du les loggen frå, fordi to gatewayar i eitt abonnement lett blir forveksla under ein ombygging. Den feilen kostar ein dag og etterlèt ingen spor i nokon logg.