Azure S2S VPN verbind maar geen verkeer: lees die IKE-log

Die portaal sê Connected, die tonnel het ’n uptime-teller, en ’n trace vanaf jou virtuele masjien sterf op die tweede hop. Verbindingstatus beskryf die IKE- en IPsec-onderhandeling, nie of ’n enkele pakket die beleidslaag aan weerskante oorleef nie. Twee foute veroorsaak die meeste van hierdie tickets, en nie een van hulle word reggemaak deur ’n Azure-roete te verander nie. Albei is reeds neergeskryf in die log wat die gateway geproduseer het, en daarom begin ek daar eerder as in die roetetabel.

Wat Connected werklik sertifiseer

’n Verbinde site-tot-site-verbinding beteken dat fase 1 en fase 2 voltooi is en die sekuriteitsassosiasies op is. Dit is ’n stelling oor onderhandeling: albei eweknieë het oor ’n voorstel ooreengekom, sleutels uitgeruil en die paar SA's geïnstalleer. Dit sê niks oor of die verkeerskeerders ooreenstem met die subnetwerke wat jy dink beskerm word nie, en niks oor of die verre kant die pakket enige plek sal roeteer nadat dit ontsifreer het nie. ’n Tonnel kan weke lank op bly terwyl elke interessante vloei laat vaar word, en dit is presies die patroon wat mense ’n gesonde gateway laat herbou.

Die twee foute wat eerste ondersoek moet word, is ’n eweknie wat AH in plaas van ESP voorstel, en ’n virtuele netwerk wat in ’n ruimte genommer is wat die gateway nie as intern sal behandel nie.

Maak die uitgevoerde log oop voordat jy aan roetes raak

Maak in die portaal die virtuele netwerkgateway oop en voer die VPN-ontfoutingsbewerking teen die verbinding uit, laai dan die bundel wat dit produseer en pak dit uit. Binne-in is ’n IKE-log met die fase 1- en fase 2-uitruilings, met tydstempels en as gewone teks leesbaar. Soek daarin na die transform-reël eerder as om van bo na onder te lees, want die interessante inskrywing is gewoonlik ’n paar honderd reëls in. As jy geen portaaltoegang het nie, verskyn dieselfde diagnostiek in die gateway se logbestemming wanneer diagnostiese instellings geaktiveer is.

Twee inskrywings dra die meeste van die waarde. Die eerste lees iets soos expected ESP with combined authentication and cipher, received AH. Die tweede is ’n ongeldige-payload-fout tydens die IKE-uitruiling, wat gewoonlik ’n misvormde of onondersteunde voorstelveld beteken.

Albei beskryf wat die on-premises-toestel aangebied het, dus albei is instellings aan die eweknie-kant. Om die Azure-kant van die verbinding te hergenereer verander nie die voorstel wat jou firewall stuur nie, en om dit tog te doen is die mees algemene vermorste uur in hierdie werkvloei. Stel op die eweknie fase 2 op ESP met gekombineerde verifikasie en syfer en laat dit die algoritme onderhandel, en kyk dan of ’n verskaffer-merkbokkie met iets soos combined mode nie stilweg ’n AH-voorstel daaronder kies nie.

Bevestig die virtuele netwerk se adresruimte

Die gateway verwag dat die virtuele netwerk in private reekse sit. ’n Netwerk wat in ’n publieke blok genommer is, byvoorbeeld een wat met 111.x begin, kan die tonnel op bring terwyl Azure weier om daardie ruimte as intern te behandel, so die verbinding lyk gesond en geen vloei word aanvaar nie. Bevestig die adresruimte voordat jy ’n middag aan keerders bestee. As die nommering ’n harde vereiste uit ’n ouer toekenning is, is die regstelling ’n verandering aan die adresplan eerder as ’n ander gateway.

Teken die oorvleueling met die on-premises-reekse op terwyl jy in die adresruimte-blad is, want oorvleuelende voorvoegsels produseer ’n ander fout wat van die kliënt af soortgelyk lyk.

Verifieer die voorvoegsels in albei rigtings

Die plaaslike netwerkgateway-hulpbron hou die on-premises-voorvoegsels, en hulle moet ooreenstem met die subnetwerke wat die afgeleë toestel werklik beskerm. ’n Opsomming wat adresse insluit wat die toestel laat vaar, sal sommige vloeie deurlaat en ander faal, wat soos ’n wisselvallige roetefout eerder as ’n konfigurasie-mismatch lees. Kyk ook na die verre kant: een kant wat ’n /16 lys terwyl die ander drie /24's daarbinne lys, is die klassieke gedeeltelike faling. Nie een lys is op sigself gesaghebbend nie, so vergelyk hulle langs mekaar eerder as om die een te vertrou wat jy kan sien.

’n Voorvoegsel word nie altyd vanself opgetel nie, so beplan om die verbindingsobjek weer te stoor of te herskep en bevestig dan dat die nuwe voorvoegsels aan albei kante verskyn.

Toets ’n pad, nie ’n ping nie

Die trace wat ’n werkende tonnel van ’n werkende roete skei, lyk so: eerste hop is die on-premises-gateway, dan ’n paar onreageerende hope, dan antwoord die afgeleë gasheer. As die trace nooit die gasheer bereik nie, toets die TCP-poort wat die toepassing werklik gebruik, want ICMP word dikwels genoeg gefiltreer dat ’n mislukte ping baie min bewys. Voer dieselfde trace uit vanaf ’n afgeleë gasheer na ’n virtuele masjien in Azure. Asimmetrie tussen die twee resultate is die vinnigste manier om ’n ontbrekende terugroete of ’n reël wat net een rigting toelaat, te vind.

Skryf die eweknie-voorstel, albei adresruimtes en die verbinding se skeppingstyd in die ticket, sodat die volgende ingenieur weet watter waardes herbou is en watter nooit aangeraak is nie.

As die log leeg terugkom, is dit moontlik dat die gateway jou verbinding glad nie termineer nie. Bevestig dat die eweknie-adres op die plaaslike netwerkgateway ooreenstem met die toestel waarvan jy die log lees, want twee gateways in een intekening is maklik om tydens ’n herbou te verwar. Daardie fout kos ’n dag en laat geen spoor in enige log nie.