VPN S2S v Azureu povezana, a brez prometa: preberite dnevnik IKE

Portal pravi Connected, tunel ima števec časa delovanja, in trace z vašega navideznega stroja umre na drugem hopu. Stanje povezave opisuje pogajanje IKE in IPsec, ne pa tega, ali en paket preživi plast pravil na kateri koli strani. Večino teh zahtevkov pojasnita dve napaki in nobene ne odpravi sprememba poti v Azureu. Obe sta že zapisani v dnevniku, ki ga je ustvaril prehod, zato začnem tam in ne v tabeli poti.

Kaj Connected v resnici potrjuje

Povezana povezava site-to-site pomeni, da sta faza 1 in faza 2 zaključeni in da so varnostne asociacije aktivne. To je trditev o pogajanju: obe strani sta se dogovorili o predlogu, izmenjali ključe in namestili par SA. Ne pove ničesar o tem, ali se izbirniki prometa ujemajo s podomrežji, ki jih imate za zaščitena, niti o tem, ali bo oddaljena stran paket po dešifriranju kam poslala. Tunel lahko stoji tedne in pri tem zavrže vsak zanimiv tok, in prav ta vzorec ljudi sili, da zdravi prehod zgradijo znova.

Napaki, ki ju je vredno preveriti najprej, sta peer, ki predlaga AH namesto ESP, in navidezno omrežje, oštevilčeno v prostoru, ki ga prehod ne bo obravnaval kot notranjega.

Odprite izvoženi dnevnik, preden se dotaknete poti

V portalu odprite prehod navideznega omrežja in zaženite operacijo VPN troubleshoot na povezavi, nato prenesite paket, ki ga ustvari, in ga razširite. Znotraj je dnevnik IKE z izmenjavami faze 1 in faze 2, s časovnimi žigi in berljiv kot navadno besedilo. V njem poiščite vrstico transform, namesto da berete od zgoraj navzdol, ker je zanimiv vnos običajno nekaj sto vrstic nižje. Če nimate dostopa do portala, se enaka diagnostika pojavi na cilju dnevnikov prehoda, ko so omogočene diagnostične nastavitve.

Dva vnosa prineseta večino vrednosti. Prvi se glasi približno expected ESP with combined authentication and cipher, received AH. Drugi je napaka neveljavnega payloada med izmenjavo IKE, kar običajno pomeni nepravilno oblikovano ali nepodprto polje predloga.

Oba opisujeta, kaj je ponudila lokalna naprava, torej gre za nastavitvi na strani peera. Ponovno ustvarjanje strani Azure ne spremeni predloga, ki ga pošilja vaš požarni zid, in to kljub temu početi je najpogosteje zapravljena ura v tem postopku. Na peeru nastavite fazo 2 na ESP s kombiniranim preverjanjem in šifro ter pustite, da se pogaja o algoritmu, nato preverite, ali potrditveno polje ponudnika z imenom, kot je combined mode, tiho izbira predlog AH pod njim.

Potrdite naslovni prostor navideznega omrežja

Prehod pričakuje, da bo navidezno omrežje v zasebnih obsegih. Omrežje, oštevilčeno v javnem bloku, na primer tisto, ki se začne z 111.x, lahko dvigne tunel, medtem ko Azure noče tega prostora obravnavati kot notranjega, zato je povezava videti zdrava in noben tok ni sprejet. Potrdite naslovni prostor, preden preživite popoldne ob izbirnikih. Če je oštevilčenje trda zahteva iz starejše dodelitve, je popravek sprememba naslovnega načrta in ne drug prehod.

Zabeležite prekrivanje z lokalnimi obsegi, medtem ko ste v rezini naslovnega prostora, ker prekrivajoče se predpone ustvarijo drugačno okvaro, ki je s strani odjemalca videti podobna.

Preverite predpone v obeh smereh

Vir prehoda lokalnega omrežja vsebuje lokalne predpone in te se morajo ujemati s podomrežji, ki jih oddaljena naprava resnično ščiti. Povzetek, ki vključuje naslove, ki jih naprava zavrže, bo spustil nekatere tokove in na drugih spodletel, kar se bere kot občasna okvara usmerjanja in ne kot neskladje konfiguracije. Preverite tudi oddaljeno stran: en konec navaja /16, drugi pa tri /24 znotraj njega — to je klasična delna okvara. Noben seznam ni sam po sebi odločilen, zato ju primerjajte drug ob drugem, namesto da bi zaupali tistemu, ki ga vidite.

Sprememba predpone se ne prevzame vedno sama, zato načrtujte, da boste predmet povezave znova shranili ali ustvarili, nato pa potrdite, da se nove predpone pojavijo na obeh straneh.

Preizkusite pot, ne ping

Trace, ki loči delujoč tunel od delujoče poti, je videti takole: prvi hop je lokalni prehod, nato nekaj hopov brez odgovora, nato odgovori oddaljeni gostitelj. Če trace nikoli ne doseže gostitelja, preizkusite vrata TCP, ki jih aplikacija resnično uporablja, ker se ICMP filtrira dovolj pogosto, da neuspešen ping dokaže zelo malo. Zaženite isti trace z oddaljenega gostitelja proti navideznemu stroju v Azureu. Asimetrija med obema rezultatoma je najhitrejši način, da najdete manjkajočo povratno pot ali pravilo, ki dovoljuje le eno smer.

Zapišite predlog peera, oba naslovna prostora in čas nastanka povezave v zahtevek, da bo naslednji inženir vedel, katere vrednosti so bile znova zgrajene in katerih se nihče ni dotaknil.

Če se dnevnik vrne prazen, prehod morda vaše povezave sploh ne zaključi. Potrdite, da se naslov peera na prehodu lokalnega omrežja ujema z napravo, s katere berete dnevnik, ker je dva prehoda v eni naročnini med obnovo zlahka zamenjati. Ta napaka stane en dan in ne pušča sledi v nobenem dnevniku.