Azure S2S VPN verbonden maar geen verkeer: lees het IKE-log

De portal zegt Connected, de tunnel heeft een uptime-teller, en een trace vanaf uw virtuele machine sterft op de tweede hop. De verbindingsstatus beschrijft de IKE- en IPsec-onderhandeling, niet of één pakket de beleidslaag aan weerszijden overleeft. Twee fouten verklaren de meeste van deze tickets, en geen van beide wordt hersteld door een Azure-route te wijzigen. Beide staan al in het log dat de gateway heeft geproduceerd, daarom begin ik daar en niet in de routetabel.

Wat Connected werkelijk certificeert

Een verbonden site-to-site-verbinding betekent dat fase 1 en fase 2 zijn voltooid en dat de security associations actief zijn. Dat is een uitspraak over de onderhandeling: beide peers werden het eens over een voorstel, wisselden sleutels uit en installeerden het paar SA's. Het zegt niets over of de verkeersselectoren overeenkomen met de subnetten die u als beschermd beschouwt, en niets over of de verre kant het pakket na het ontsleutelen ergens heen routeert. Een tunnel kan weken overeind blijven terwijl hij elke interessante stroom laat vallen, en dat is precies het patroon waardoor mensen een gezonde gateway opnieuw bouwen.

De twee fouten die het eerst waard zijn om te controleren zijn een peer die AH voorstelt in plaats van ESP, en een virtueel netwerk dat is genummerd in een ruimte die de gateway niet als intern behandelt.

Open het geëxporteerde log voordat u routes aanraakt

Open in de portal de gateway van het virtuele netwerk en voer de VPN troubleshoot-bewerking uit op de verbinding, download daarna het pakket dat het oplevert en pak het uit. Binnenin zit een IKE-log met de fase 1- en fase 2-uitwisselingen, met tijdstempels en leesbaar als platte tekst. Zoek erin naar de transform-regel in plaats van van boven naar beneden te lezen, want de interessante regel staat meestal een paar honderd regels dieper. Heeft u geen portaaltoegang, dan verschijnen dezelfde diagnostische gegevens in de logbestemming van de gateway wanneer de diagnose-instellingen zijn ingeschakeld.

Twee regels dragen het grootste deel van de waarde. De eerste luidt ongeveer expected ESP with combined authentication and cipher, received AH. De tweede is een ongeldige-payload-fout tijdens de IKE-uitwisseling, wat meestal een verkeerd gevormd of niet-ondersteund voorstelveld betekent.

Beide beschrijven wat het on-premises apparaat heeft aangeboden, dus beide zijn instellingen aan de peer-kant. De Azure-kant van de verbinding opnieuw genereren verandert het voorstel dat uw firewall stuurt niet, en het toch doen is het meest verspilde uur in deze werkstroom. Stel op de peer fase 2 in op ESP met gecombineerde authenticatie en cipher en laat het de algoritme onderhandelen, en controleer daarna of een leveranciersselectievakje met een naam als combined mode stilletjes een AH-voorstel eronder selecteert.

Bevestig de adresruimte van het virtuele netwerk

De gateway verwacht dat het virtuele netwerk in privébereiken ligt. Een netwerk dat in een openbare blok is genummerd, bijvoorbeeld een dat met 111.x begint, kan de tunnel omhoog brengen terwijl Azure weigert die ruimte als intern te behandelen, zodat de verbinding gezond lijkt en geen enkele stroom wordt geaccepteerd. Bevestig de adresruimte voordat u een middag aan selectoren besteedt. Is de nummering een harde eis uit een oudere toewijzing, dan is de oplossing een wijziging van het adresplan en niet een andere gateway.

Noteer de overlap met de lokale bereiken terwijl u in de blade voor de adresruimte bent, want overlappende prefixen veroorzaken een ander falen dat er vanaf de client vergelijkbaar uitziet.

Controleer de prefixen in beide richtingen

De resource van de lokale netwerkgateway bevat de on-premises prefixen, en die moeten overeenkomen met de subnetten die het externe apparaat werkelijk beschermt. Een samenvatting die adressen bevat die het apparaat laat vallen, laat sommige stromen door en faalt op andere, wat leest als een periodieke routeringsfout en niet als een configuratieverschil. Controleer ook de verre kant: het ene uiteinde vermeldt een /16 terwijl het andere er drie /24 binnen vermeldt — dat is het klassieke gedeeltelijke falen. Geen van beide lijsten is op zichzelf gezaghebbend, dus vergelijk ze naast elkaar in plaats van degene te vertrouwen die u kunt zien.

Een prefixwijziging wordt niet altijd vanzelf opgepikt, dus plan om het verbindingsobject opnieuw op te slaan of opnieuw aan te maken en bevestig daarna dat de nieuwe prefixen aan beide kanten verschijnen.

Test een pad, geen ping

De trace die een werkende tunnel van een werkende route scheidt, ziet er zo uit: de eerste hop is de lokale gateway, dan een paar niet-reagerende hops, dan antwoordt de externe host. Als de trace de host nooit bereikt, test dan de TCP-poort die de toepassing werkelijk gebruikt, want ICMP wordt vaak genoeg gefilterd dat een mislukte ping heel weinig bewijst. Voer dezelfde trace uit vanaf een externe host naar een virtuele machine in Azure. De asymmetrie tussen de twee resultaten is de snelste manier om een ontbrekende retourroute of een regel die slechts één richting toestaat te vinden.

Schrijf het voorstel van de peer, beide adresruimtes en het tijdstip van aanmaken van de verbinding in het ticket, zodat de volgende engineer weet welke waarden opnieuw zijn opgebouwd en welke nooit zijn aangeraakt.

Komt het log leeg terug, dan termineert de gateway uw verbinding mogelijk helemaal niet. Bevestig dat het peer-adres op de lokale netwerkgateway overeenkomt met het apparaat waarvan u het log leest, want twee gateways in één abonnement zijn tijdens een herbouw gemakkelijk te verwarren. Die fout kost een dag en laat in geen enkel log een spoor achter.