Azure S2S VPN csatlakozva, de nincs forgalom: olvassa el az IKE-naplót

A portál Connected állapotot ír, az alagútnak van üzemidő-számlálója, és a virtuális gépéről indított trace a második hopnál meghal. A kapcsolat állapota az IKE- és IPsec-tárgyalást írja le, nem azt, hogy egyetlen csomag túléli-e a házirend-réteget bármelyik oldalon. Két hiba magyarázza ezeknek a jegyeknek a többségét, és egyiket sem javítja Azure-útvonal módosítása. Mindkettő már ott van a naplóban, amelyet az átjáró előállított, ezért onnan indulok, nem az útvonaltáblából.

Mit tanúsít valójában a Connected

Egy csatlakoztatott site-to-site kapcsolat azt jelenti, hogy az 1. és a 2. fázis befejeződött és a biztonsági társítások élnek. Ez a tárgyalásról szóló állítás: mindkét fél megegyezett egy javaslatban, kulcsot cserélt és telepítette az SA-párt. Nem mond semmit arról, hogy a forgalomválasztók megegyeznek-e azokkal az alhálózatokkal, amelyeket védettnek hisz, és arról sem, hogy a túloldal a visszafejtés után bárhová továbbítja-e a csomagot. Egy alagút hetekig fennmaradhat, miközben minden érdekes folyamot eldob, és pontosan ez a minta készteti az embereket egy egészséges átjáró újjáépítésére.

A két hiba, amelyet érdemes először megvizsgálni: egy peer, amely ESP helyett AH-t javasol, és egy virtuális hálózat, amelyet olyan térben számoztak, amelyet az átjáró nem tekint belsőnek.

Nyissa meg az exportált naplót, mielőtt útvonalakhoz nyúlna

A portálon nyissa meg a virtuális hálózati átjárót, és futtassa a VPN troubleshoot műveletet a kapcsolaton, majd töltse le az általa előállított csomagot, és csomagolja ki. Belül egy IKE-napló található az 1. és 2. fázis cseréivel, időbélyegekkel és egyszerű szövegként olvashatóan. A transform sorát keresse benne, ne fentről lefelé olvasson, mert az érdekes bejegyzés általában néhányszáz sorral beljebb van. Ha nincs portál-hozzáférése, ugyanazok a diagnosztikák jelennek meg az átjáró naplócéljában, ha a diagnosztikai beállítások engedélyezve vannak.

Két bejegyzés hordozza az érték nagy részét. Az első nagyjából így szól: expected ESP with combined authentication and cipher, received AH. A második érvénytelen payload hiba az IKE-csere során, ami általában hibásan formázott vagy nem támogatott javaslatmezőt jelent.

Mindkettő azt írja le, mit ajánlott a helyszíni eszköz, tehát mindkettő peer oldali beállítás. Az Azure oldal újragenerálása nem változtatja meg a tűzfal által küldött javaslatot, és ezt mégis megtenni a leggyakrabban elpazarolt óra ebben a munkafolyamatban. A peeren állítsa a 2. fázist ESP-re kombinált hitelesítéssel és titkosítással, hagyja megtárgyalni az algoritmust, majd ellenőrizze, hogy a combined mode nevűhöz hasonló gyártói jelölőnégyzet nem választ-e csendben egy AH-javaslatot alatta.

Erősítse meg a virtuális hálózat címtartományát

Az átjáró azt várja, hogy a virtuális hálózat magán tartományokban legyen. Egy nyilvános blokkban számozott hálózat, például amelyik 111.x-szel kezdődik, felhozhatja az alagutat, miközben az Azure megtagadja, hogy ezt a teret belsőnek tekintse, így a kapcsolat egészségesnek látszik, és egyetlen folyam sem fogadható el. A választókra fordított délután előtt erősítse meg a címtartományt. Ha a számozás egy régebbi kiosztásból eredő kemény követelmény, a megoldás a címterv módosítása, nem egy másik átjáró.

Jegyezze fel az átfedést a helyszíni tartományokkal, amíg a címtartomány panelen van, mert az átfedő előtagok másféle hibát okoznak, amely az ügyfél felől hasonlónak látszik.

Ellenőrizze az előtagokat mindkét irányban

A helyi hálózati átjáró erőforrása tartalmazza a helyszíni előtagokat, és ezeknek meg kell egyezniük azokkal az alhálózatokkal, amelyeket a távoli eszköz valóban véd. Egy olyan összegzés, amely tartalmazza az eszköz által eldobott címeket, egyes folyamokat átenged, másokon elbukik, ami szakaszos útvonalhibaként olvasható, nem konfiguráció-eltérésként. Nézze meg a túloldalt is: az egyik vég /16-ot sorol fel, míg a másik három /24-et benne — ez a klasszikus részleges hiba. Egyik lista sem mérvadó önmagában, ezért hasonlítsa össze őket egymás mellett, ne bízzon abban, amelyiket látja.

Az előtag módosítását nem mindig veszi át magától, ezért tervezze meg a kapcsolatobjektum újramentését vagy újralétrehozását, majd erősítse meg, hogy az új előtagok mindkét oldalon megjelennek.

Útvonalat teszteljen, ne pinget

A trace, amely elválasztja a működő alagutat a működő útvonaltól, így néz ki: az első hop a helyszíni átjáró, aztán néhány nem válaszoló hop, aztán a távoli gazdagép válaszol. Ha a trace soha nem ér el a gazdagépig, tesztelje azt a TCP-portot, amelyet az alkalmazás valóban használ, mert az ICMP-t elég gyakran szűrik ahhoz, hogy egy sikertelen ping nagyon keveset bizonyítson. Futtassa ugyanazt a trace-t egy távoli gazdagépről egy Azure-beli virtuális gép felé. A két eredmény közötti aszimmetria a leggyorsabb módja a hiányzó visszaútvonal vagy a csak egy irányt engedélyező szabály megtalálásának.

Írja be a peer javaslatát, mindkét címtartományt és a kapcsolat létrehozási idejét a jegybe, hogy a következő mérnök tudja, mely értékek épültek újjá, és melyekhez nem nyúltak soha.

Ha a napló üresen jön vissza, lehet, hogy az átjáró egyáltalán nem terminálja a kapcsolatot. Erősítse meg, hogy a helyi hálózati átjárón szereplő peer-cím megegyezik azzal az eszközzel, amelyről a naplót olvassa, mert egy előfizetésben két átjárót könnyű összekeverni egy újjáépítés során. Ez a hiba egy napba kerül, és semmilyen naplóban nem hagy nyomot.