Azure S2S VPN on ühendatud, aga liiklust pole: loe IKE-logi

Portaal ütleb Connected, tunnelil on tööaja loendur ja trace sinu virtuaalmasinast sureb teisel hopil. Ühenduse olek kirjeldab IKE ja IPsec läbirääkimist, mitte seda, kas ükski pakett läbib poliitikakihi kummalgi pool. Kahte tõrget seletab enamiku sellistest piletitest ja kumbagi ei paranda Azure'i marsruudi muutmine. Mõlemad on juba kirjas logis, mille lüüs tootis, seepärast alustan sealt, mitte marsruuditabelist.

Mida Connected tegelikult tõendab

Ühendatud site-to-site ühendus tähendab, et faas 1 ja faas 2 on lõpetatud ja turbeseosed on püsti. See on väide läbirääkimise kohta: mõlemad pooled leppisid kokku ettepanekus, vahetasid võtmed ja paigaldasid SA-paari. See ei ütle midagi selle kohta, kas liikluse selektorid vastavad alamvõrkudele, mida pead kaitstuks, ega selle kohta, kas kaugem pool marsruudib paketi pärast dekrüpteerimist kuhugi. Tunnel võib püsida nädalaid, visates samal ajal ära iga huvitava voo, ja just see muster paneb inimesi tervet lüüsi uuesti ehitama.

Kaks tõrget, mida esimesena kontrollida tasub, on peer, mis pakub AH-d ESP asemel, ja virtuaalvõrk, mis on nummerdatud ruumis, mida lüüs ei käsitle sisemisena.

Ava eksporditud logi enne, kui marsruute puutud

Ava portaalides virtuaalvõrgu lüüs ja käivita ühendusel VPN troubleshoot operatsioon, seejärel laadi alla selle loodud pakett ja paki see lahti. Sees on IKE-log faasi 1 ja faasi 2 vahetustega, ajatemplitega ja lihttekstina loetav. Otsi sealt rida transform, mitte loe ülalt alla, sest huvitav kirje on tavaliselt mõnisada rida allpool. Kui portaalile ligipääsu pole, ilmuvad samad diagnostikad lüüsi logisihtkohta, kui diagnostikaseaded on lubatud.

Kaks kirjet kannavad suuremat osa väärtusest. Esimene kõlab umbes nii: expected ESP with combined authentication and cipher, received AH. Teine on kehtetu payloadi viga IKE-vahetuse ajal, mis tähendab tavaliselt vigaselt vormindatud või toetamata ettepanekuvälja.

Mõlemad kirjeldavad, mida kohalik seade pakkus, seega on mõlemad peer-poolseaded. Azure'i poole uuesti genereerimine ei muuda ettepanekut, mille sinu tulemüür saadab, ja selle tegemine on ikkagi selle töövoo kõige sagedasem raisatud tund. Peeril sea faas 2 ESP-le kombineeritud autentimise ja šifriga ning lase tal algoritm läbi rääkida, seejärel kontrolli, kas tarnija märkeruut nimega midagi combined mode'i taolist valib vaikselt selle all AH-ettepaneku.

Kinnita virtuaalvõrgu aadressiruum

Lüüs eeldab, et virtuaalvõrk asub privaatsetes vahemikes. Avalikus plokis nummerdatud võrk, näiteks 111.x-ga algav, võib tunneli üles tõsta, samal ajal kui Azure keeldub seda ruumi sisemisena käsitlemast, nii et ühendus näeb terve välja ja ükski voog ei ole vastu võetud. Kinnita aadressiruum enne, kui kulutad selektoritele terve pärastlõuna. Kui nummerdus on vanemast jaotusest pärit range nõue, on parandus aadressiplaani muutmine, mitte teine lüüs.

Kirjuta üles kattuvus kohalike vahemikega, kui oled aadressiruumi teral, sest kattuvad prefiksid tekitavad teistsuguse tõrke, mis kliendi poolt vaadates sarnane välja näeb.

Kontrolli prefikseid mõlemas suunas

Kohaliku võrgu lüüsi ressurss hoiab kohalikke prefikseid ja need peavad vastama alamvõrkudele, mida kaugseade tegelikult kaitseb. Kokkuvõte, mis sisaldab aadresse, mille seade ära viskab, laseb mõned vood läbi ja ebaõnnestub teistel, mis loeb pigem vahelduva marsruutimistõrkena kui konfiguratsiooni mittevastavusena. Kontrolli ka kaugemat poolt: üks ots loetleb /16, samal ajal kui teine loetleb selle sees kolm /24 — see on klassikaline osaline tõrge. Kumbki nimekiri ei ole iseenesest autoriteetne, seega võrdle neid kõrvuti, mitte ära usalda seda, mida näed.

Prefiksi muudatust ei võeta alati automaatselt vastu, seega planeeri ühendusobjekti uuesti salvestamist või uuesti loomist ja seejärel kinnita, et uued prefiksid ilmuvad mõlemale poolele.

Testi teed, mitte pingi

Trace, mis eristab töötavat tunnelit töötavast marsruudist, näeb välja nii: esimene hop on kohalik lüüs, siis mõned vastamata hopid, siis vastab kaugem host. Kui trace ei jõua kunagi hostini, testi TCP-porti, mida rakendus tegelikult kasutab, sest ICMP-d filtreeritakse piisavalt sageli, et ebaõnnestunud ping tõestab väga vähe. Käivita sama trace kaugest hostist Azure'i virtuaalmasina suunas. Asümmeetria kahe tulemuse vahel on kiireim viis leida puuduv tagasitee või reegel, mis lubab ainult ühte suunda.

Kirjuta peeri ettepanek, mõlemad aadressiruumid ja ühenduse loomise aeg piletisse, et järgmine insener teaks, millised väärtused ehitati uuesti ja milliseid ei puudutatud kunagi.

Kui logi tuleb tühjalt tagasi, ei pruugi lüüs sinu ühendust üldse lõpetada. Kinnita, et kohaliku võrgu lüüsi peer-aadress vastab seadmele, millest logi loed, sest kaks lüüsi ühes tellimuses on uuesti ehitamise ajal kergesti segi aetavad. See viga maksab päeva ja ei jäta ühessegi logi jälge.