S2S VPN u Azureu povezan ali nema saobraćaja: pročitajte IKE log

Portal piše Connected, tunel ima brojač vremena rada, a trace sa vaše virtuelne mašine umire na drugom hopu. Stanje veze opisuje IKE i IPsec pregovore, a ne da li jedan paket preživljava sloj politika na bilo kojoj strani. Dvije greške objašnjavaju većinu ovakvih tiketa i nijedna se ne popravlja promjenom Azure rute. Obje su već zapisane u logu koji je gateway proizveo, zato počinjem odatle, a ne iz tabele ruta.

Šta Connected zapravo potvrđuje

Povezana site-to-site veza znači da su faza 1 i faza 2 završene i da su sigurnosne asocijacije podignute. To je tvrdnja o pregovorima: obje strane su se dogovorile o prijedlogu, razmijenile ključeve i instalirale par SA. Ništa ne govori o tome da li se selektori saobraćaja poklapaju sa podmrežama koje smatrate zaštićenim, niti o tome da li će dalja strana usmjeriti paket bilo gdje nakon dešifrovanja. Tunel može stajati sedmicama dok ispušta svaki zanimljiv tok, a to je upravo obrazac zbog kojeg ljudi ponovo grade zdrav gateway.

Dvije greške koje prvo vrijedi provjeriti su peer koji predlaže AH umjesto ESP i virtuelna mreža numerisana u prostoru koji gateway neće tretirati kao interni.

Otvorite izvezeni log prije nego što dirnete rute

U portalu otvorite gateway virtuelne mreže i pokrenite VPN troubleshoot operaciju nad vezom, zatim preuzmite paket koji se proizvede i raspakujte ga. Unutra je IKE log sa razmjenama faze 1 i faze 2, sa vremenskim oznakama i čitljiv kao običan tekst. Tražite u njemu liniju transform umjesto da čitate odozgo nadole, jer zanimljiv unos obično dolazi nakon nekoliko stotina redova. Ako nemate pristup portalu, ista dijagnostika se pojavljuje u odredištu loga gatewaya kada su uključena dijagnostička podešavanja.

Dva unosa nose najviše vrijednosti. Prvi zvuči otprilike ovako: expected ESP with combined authentication and cipher, received AH. Drugi je greška nevažećeg payloada tokom IKE razmjene, što obično znači loše formirano ili nepodržano polje prijedloga.

Oba opisuju šta je predložio on-premises uređaj, pa su oba podešavanja na strani peera. Ponovno generisanje Azure strane veze ne mijenja prijedlog koji vaš firewall šalje, a raditi to ipak je najčešće izgubljeni sat u ovom poslu. Na peeru postavite fazu 2 na ESP sa kombinovanom autentifikacijom i šifrom i pustite ga da pregovara algoritam, zatim provjerite da li polje za potvrdu dobavljača nazvano nešto kao combined mode tiho bira AH prijedlog ispod.

Potvrdite adresni prostor virtuelne mreže

Gateway očekuje da virtuelna mreža bude u privatnim opsezima. Mreža numerisana u javnom bloku, na primjer ona koja počinje sa 111.x, može podići tunel dok Azure odbija tretirati taj prostor kao interni, pa veza izgleda zdravo i nijedan tok nije prihvaćen. Potvrdite adresni prostor prije nego što potrošite popodne na selektore. Ako je numeracija tvrd zahtjev iz starije dodjele, popravka je promjena adresnog plana, a ne drugi gateway.

Zapišite preklapanje sa on-premises opsezima dok ste u oštrici adresnog prostora, jer preklapajući prefiksi proizvode drugačiji kvar koji sa klijenta izgleda slično.

Provjerite prefikse u oba smjera

Resurs gatewaya lokalne mreže drži on-premises prefikse i oni moraju odgovarati podmrežama koje udaljeni uređaj zaista štiti. Sažetak koji uključuje adrese koje uređaj ispušta propustit će neke tokove, a na drugima pasti, što se čita kao povremeni kvar rutiranja, a ne kao nesklad u konfiguraciji. Provjerite i dalju stranu: jedan kraj navodi /16 dok drugi navodi tri /24 unutar njega — to je klasičan djelimični neuspjeh. Nijedna lista nije sama po sebi mjerodavna, zato ih uporedite jednu uz drugu umjesto da vjerujete onoj koju vidite.

Promjena prefiksa se ne preuzima uvijek sama, zato planirajte ponovno čuvanje ili ponovno kreiranje objekta veze i zatim potvrdite da se novi prefiksi pojavljuju na obje strane.

Testirajte put, a ne ping

Trace koji razdvaja tunel koji radi od rute koja radi izgleda ovako: prvi hop je on-premises gateway, zatim nekoliko hopova bez odgovora, zatim udaljeni host odgovara. Ako trace nikada ne stigne do hosta, testirajte TCP port koji aplikacija zaista koristi, jer se ICMP filtrira dovoljno često da neuspjeli ping dokazuje vrlo malo. Pokrenite isti trace sa udaljenog hosta prema virtuelnoj mašini u Azureu. Asimetrija između dva rezultata najbrži je način da pronađete povratnu rutu koja nedostaje ili pravilo koje dozvoljava samo jedan smjer.

Zapišite peer prijedlog, oba adresna prostora i vrijeme kreiranja veze u tiket, da sljedeći inženjer zna koje su vrijednosti ponovo izgrađene, a koje nikada nisu dirane.

Ako se log vrati prazan, gateway možda uopšte ne terminira vašu vezu. Potvrdite da se peer adresa na gatewayu lokalne mreže poklapa sa uređajem s kojeg čitate log, jer je dva gatewaya u jednoj pretplati lako zamijeniti tokom ponovne izgradnje. Ta greška košta jedan dan i ne ostavlja trag ni u jednom logu.