S2S VPN u Azureu spojen ali bez prometa: pročitajte IKE zapisnik

Portal kaže Connected, tunel ima brojač vremena rada, a trace s vašega virtualnog računala umire na drugom hopu. Stanje veze opisuje IKE i IPsec pregovore, a ne preživljava li ijedan paket sloj pravila na bilo kojoj strani. Dvije pogreške objašnjavaju većinu ovakvih zahtjeva i nijednu ne ispravlja promjena Azure rute. Obje su već zapisane u zapisniku koji je pristupnik proizveo, zato počinjem ondje, a ne u tablici ruta.

Što Connected doista potvrđuje

Povezana site-to-site veza znači da su faza 1 i faza 2 dovršene i da su sigurnosne asocijacije podignute. To je tvrdnja o pregovorima: obje su se strane dogovorile o prijedlogu, razmijenile ključeve i instalirale par SA. Ne govori ništa o tome podudaraju li se selektori prometa s podmrežama koje smatrate zaštićenima, ni o tome hoće li udaljena strana usmjeriti paket bilo kamo nakon dešifriranja. Tunel može stajati tjednima dok odbacuje svaki zanimljiv tok, a to je upravo obrazac zbog kojeg ljudi ponovno grade zdrav pristupnik.

Dvije pogreške koje prvo vrijedi provjeriti jesu peer koji predlaže AH umjesto ESP-a i virtualna mreža numerirana u prostoru koji pristupnik neće tretirati kao unutarnji.

Otvorite izvezeni zapisnik prije nego dirnete rute

U portalu otvorite pristupnik virtualne mreže i pokrenite radnju VPN troubleshoot na vezi, zatim preuzmite paket koji se stvori i raspakirajte ga. Unutra je IKE zapisnik s razmjenama faze 1 i faze 2, s vremenskim oznakama i čitljiv kao običan tekst. Tražite u njemu redak transform umjesto da čitate odozgo prema dolje, jer zanimljiv je unos obično nekoliko stotina redaka niže. Ako nemate pristup portalu, ista se dijagnostika pojavljuje na odredištu zapisnika pristupnika kada su uključene dijagnostičke postavke.

Dva unosa nose najveći dio vrijednosti. Prvi zvuči otprilike expected ESP with combined authentication and cipher, received AH. Drugi je pogreška nevaljanog payloada tijekom IKE razmjene, što obično znači loše oblikovano ili nepodržano polje prijedloga.

Oba opisuju što je ponudila lokalna oprema, pa su oba postavke na strani peera. Ponovno stvaranje Azure strane veze ne mijenja prijedlog koji šalje vaš vatrozid, a činiti to ipak najčešće je izgubljeni sat u ovom postupku. Na peeru postavite fazu 2 na ESP sa kombiniranom autentifikacijom i šifrom i pustite ga da pregovara algoritam, zatim provjerite odabire li potvrdni okvir dobavljača nazvan nešto poput combined mode tiho AH prijedlog ispod.

Potvrdite adresni prostor virtualne mreže

Pristupnik očekuje da se virtualna mreža nalazi u privatnim rasponima. Mreža numerirana u javnom bloku, primjerice ona koja počinje s 111.x, može podignuti tunel dok Azure odbija taj prostor tretirati kao unutarnji, pa veza izgleda zdravo i nijedan tok nije prihvaćen. Potvrdite adresni prostor prije nego potrošite poslijepodne na selektore. Ako je numeriranje tvrd uvjet iz starije dodjele, ispravak je promjena adresnog plana, a ne drugi pristupnik.

Zabilježite preklapanje s lokalnim rasponima dok ste na oštrici adresnog prostora, jer preklapajući prefiksi stvaraju drukčiji kvar koji s klijenta izgleda slično.

Provjerite prefikse u obama smjerovima

Resurs pristupnika lokalne mreže drži lokalne prefikse i oni se moraju podudarati s podmrežama koje udaljena oprema doista štiti. Sažetak koji uključuje adrese koje oprema odbacuje propustit će neke tokove, a na drugima pasti, što se čita kao povremeni kvar usmjeravanja, a ne kao nesklad u konfiguraciji. Provjerite i udaljenu stranu: jedan kraj navodi /16 dok drugi navodi tri /24 unutar njega — to je klasičan djelomični neuspjeh. Nijedan popis nije sam po sebi mjerodavan, zato ih usporedite jedan uz drugi umjesto da vjerujete onome koji vidite.

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

Testirajte put, a ne ping

Trace koji razlikuje tunel koji radi od rute koja radi izgleda ovako: prvi hop je lokalni pristupnik, zatim nekoliko hopova bez odgovora, zatim udaljeni host odgovara. Ako trace nikada ne stigne do hosta, testirajte TCP port koji aplikacija doista koristi, jer se ICMP filtrira dovoljno često da neuspjeli ping dokazuje vrlo malo. Pokrenite isti trace s udaljenog hosta prema virtualnom računalu u Azureu. Asimetrija između dvaju rezultata najbrži je način da pronađete povratnu rutu koja nedostaje ili pravilo koje dopušta samo jedan smjer.

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

Ako se zapisnik vrati prazan, pristupnik možda uopće ne terminira vašu vezu. Potvrdite da se peer adresa na pristupniku lokalne mreže podudara s opremom s koje čitate zapisnik, jer je dva pristupnika u jednoj pretplati lako zamijeniti tijekom ponovne izgradnje. Ta pogreška stoji jedan dan i ne ostavlja trag ni u jednom zapisniku.