Azure S2S VPN prijungtas, bet eismo nėra: skaitykite IKE žurnalą

Portalas rašo Connected, tunelis turi veikimo laiko skaitiklį, o trace iš jūsų virtualios mašinos žūva antrame hop'e. Ryšio būsena aprašo IKE ir IPsec derybas, o ne tai, ar vienas paketas išgyvena politikos sluoksnį kurioje nors pusėje. Du gedimai paaiškina daugumą šių bilietų, ir nė vieno jų nepataiso Azure maršruto pakeitimas. Abu jau įrašyti žurnale, kurį sukūrė šliuzas, todėl pradedu ten, o ne maršrutų lentelėje.

Ką iš tikrųjų patvirtina Connected

Prijungtas site-to-site ryšys reiškia, kad 1 ir 2 fazės baigtos ir saugos asociacijos veikia. Tai teiginys apie derybas: abi pusės susitarė dėl pasiūlymo, apsikeitė raktais ir įdiegė SA porą. Jis nieko nesako apie tai, ar eismo selektoriai atitinka potinklius, kuriuos laikote apsaugotais, ir nieko apie tai, ar tolimoji pusė nukreips paketą kur nors po iššifravimo. Tunelis gali stovėti savaitėmis, mesdamas kiekvieną įdomų srautą, ir būtent šis modelis verčia žmones perstatyti sveiką šliuzą.

Du gedimai, kuriuos verta patikrinti pirmiausia, yra peer, siūlantis AH vietoj ESP, ir virtualus tinklas, sunumeruotas erdvėje, kurios šliuzas nelaikys vidine.

Atidarykite eksportuotą žurnalą prieš liesdami maršrutus

Portale atidarykite virtualaus tinklo šliuzą ir paleiskite VPN troubleshoot operaciją ryšiui, tada atsisiųskite sukurtą paketą ir išskleiskite jį. Viduje yra IKE žurnalas su 1 ir 2 fazių apsikeitimais, su laiko žymomis ir skaitomas kaip paprastas tekstas. Ieškokite jame transform eilutės, o ne skaitykite iš viršaus į apačią, nes įdomus įrašas paprastai būna po kelių šimtų eilučių. Jei neturite prieigos prie portalo, ta pati diagnostika atsiranda šliuzo žurnalo paskirties vietoje, kai įjungti diagnostikos nustatymai.

Du įrašai neša didžiąją dalį vertės. Pirmasis skamba maždaug expected ESP with combined authentication and cipher, received AH. Antrasis yra netinkamo payload klaida IKE apsikeitimo metu, o tai paprastai reiškia neteisingai suformuotą ar nepalaikomą pasiūlymo lauką.

Abu aprašo, ką pasiūlė vietinis įrenginys, todėl abu yra peer pusės nustatymai. Azure pusės atkūrimas nekeičia pasiūlymo, kurį siunčia jūsų ugniasienė, ir vis tiek tai daryti yra dažniausiai švaistoma valanda šiame darbe. Peere nustatykite 2 fazę į ESP su sujungtu autentifikavimu ir šifru ir leiskite jam derėtis dėl algoritmo, tada patikrinkite, ar combined mode pavadinimo tiekėjo žymės langelis tyliai nepasirenka AH pasiūlymo po juo.

Patvirtinkite virtualaus tinklo adresų erdvę

Šliuzas tikisi, kad virtualus tinklas bus privačiose srityse. Tinklas, sunumeruotas viešame bloke, pavyzdžiui prasidedantis 111.x, gali pakelti tunelį, nors Azure atsisako laikyti tą erdvę vidine, todėl ryšys atrodo sveikas ir nė vienas srautas nepriimamas. Patvirtinkite adresų erdvę prieš praleisdami popietę su selektoriais. Jei numeracija yra griežtas senesnio paskirstymo reikalavimas, sprendimas yra adresų plano pakeitimas, o ne kitas šliuzas.

Užrašykite persidengimą su vietinėmis sritimis, kol esate adresų erdvės skydelyje, nes persidengiantys prefiksai sukuria kitokį gedimą, kuris iš kliento pusės atrodo panašiai.

Patikrinkite prefiksus abiem kryptimis

Vietinio tinklo šliuzo išteklius laiko vietinius prefiksus, ir jie turi atitikti potinklius, kuriuos tolimas įrenginys iš tikrųjų saugo. Suvestinė, apimanti adresus, kuriuos įrenginys atmeta, praleis kai kuriuos srautus, o kituose nepavyks, ir tai skaitoma kaip protarpinis maršrutizavimo gedimas, o ne kaip konfigūracijos neatitikimas. Patikrinkite ir tolimąją pusę: vienas galas išvardija /16, o kitas – tris /24 jo viduje, tai klasikinis dalinis nepavykimas. Nė vienas sąrašas nėra savarankiškai patikimas, todėl palyginkite juos greta, o ne pasitikėkite tuo, kurį matote.

Prefikso pakeitimas ne visada paimamas savaime, todėl planuokite iš naujo išsaugoti arba sukurti ryšio objektą ir tada patvirtinkite, kad nauji prefiksai atsiranda abiejose pusėse.

Tikrinkite kelią, o ne ping

Trace, kuris atskiria veikiantį tunelį nuo veikiančio maršruto, atrodo taip: pirmasis hop yra vietinis šliuzas, tada keli neatsakantys hopai, tada atsako tolimas hostas. Jei trace niekada nepasiekia hosto, tikrinkite TCP prievadą, kurį programa iš tikrųjų naudoja, nes ICMP filtruojamas pakankamai dažnai, kad nepavykęs ping įrodo labai mažai. Paleiskite tą patį trace iš tolimo hosto link virtualios mašinos Azure. Dviejų rezultatų asimetrija yra greičiausias būdas rasti trūkstamą grįžimo maršrutą arba taisyklę, leidžiančią tik vieną kryptį.

Įrašykite peer pasiūlymą, abi adresų erdves ir ryšio sukūrimo laiką į bilietą, kad kitas inžinierius žinotų, kurios reikšmės buvo perstatytos, o kurių niekada neliesta.

Jei žurnalas grįžta tuščias, šliuzas gali visai nebaigti jūsų ryšio. Patvirtinkite, kad vietinio tinklo šliuzo peer adresas atitinka įrenginį, iš kurio skaitote žurnalą, nes du šliuzai vienoje prenumeratoje lengvai supainiojami perstatant. Ta klaida kainuoja dieną ir nepalieka pėdsakų jokiame žurnale.