VPN S2S v Azure je pripojená, ale nejde prevádzka: prečítajte si protokol IKE

Portál hovorí Connected, tunel má počítadlo doby prevádzky a trasovanie z vášho virtuálneho počítača zaniká na druhom hope. Stav pripojenia opisuje vyjednávanie IKE a IPsec, nie to, či jeden paket prežije vrstvu pravidiel na ktorejkoľvek strane. Väčšinu takýchto tiketov vysvetľujú dve chyby a ani jednu z nich neopraví zmena trasy v Azure. Obe už sú zapísané v protokole, ktorý vytvorila brána, preto začínam tam, a nie v tabuľke trás.

Čo Connected skutočne potvrdzuje

Pripojené spojenie site-to-site znamená, že fáza 1 a fáza 2 sú dokončené a že bezpečnostné asociácie sú aktívne. Je to tvrdenie o vyjednávaní: obe strany sa dohodli na návrhu, vymenili kľúče a nainštalovali dvojicu SA. Nehovorí nič o tom, či selektory prevádzky zodpovedajú podsietiam, ktoré považujete za chránené, ani o tom, či protistrana paket po dešifrovaní niekam pošle. Tunel môže stáť týždne a zahadzovať každý zaujímavý tok, a to je presne ten vzorec, prečo ľudia prestavujú zdravú bránu.

Dve chyby, ktoré stojí za to skontrolovať najskôr, sú protistrana ponúkajúca AH namiesto ESP a virtuálna sieť číslovaná v priestore, ktorý brána nebude považovať za interný.

Otvorte exportovaný protokol skôr, než sa dotknete trás

V portáli otvorte bránu virtuálnej siete a spustite operáciu VPN troubleshoot na pripojení, potom stiahnite balík, ktorý vytvorí, a rozbaľte ho. Vnútri je protokol IKE s výmenami fázy 1 a fázy 2, s časovými značkami a čitateľný ako obyčajný text. Hľadajte v ňom riadok transform namiesto čítania zhora nadol, pretože zaujímavý záznam býva o niekoľko stoviek riadkov nižšie. Ak nemáte prístup do portálu, rovnaká diagnostika sa objaví v cieli protokolov brány, keď sú zapnuté diagnostické nastavenia.

Dva záznamy nesú väčšinu hodnoty. Prvý znie približne expected ESP with combined authentication and cipher, received AH. Druhý je chyba neplatného payloadu počas výmeny IKE, čo zvyčajne znamená zle vytvorené alebo nepodporované pole návrhu.

Oba opisujú, čo ponúklo miestne zariadenie, takže oba sú nastavenia na strane protistrany. Opätovné vytvorenie strany Azure pripojenia nemení návrh, ktorý posiela váš firewall, a robiť to napriek tomu je najčastejšie premárnená hodina v tomto postupe. Na protistrane nastavte fázu 2 na ESP s kombinovaným overovaním a šifrou a nechajte ju vyjednať algoritmus, potom skontrolujte, či zaškrtávacie pole dodávateľa s názvom ako combined mode potichu nevyberá návrh AH.

Potvrďte adresný priestor virtuálnej siete

Brána očakáva, že virtuálna sieť bude v súkromných rozsahoch. Sieť číslovaná vo verejnom bloku, napríklad začínajúca 111.x, môže tunel zdvihnúť, pričom Azure odmieta považovať tento priestor za interný, takže pripojenie vyzerá zdravo a žiadny tok nie je prijatý. Potvrďte adresný priestor, skôr než strávite popoludnie na selektoroch. Ak je číslovanie tvrdou požiadavkou zo staršieho pridelenia, opravou je zmena adresného plánu, nie iná brána.

Zapíšte prekryv s miestnymi rozsahmi, kým ste v okne adresného priestoru, pretože prekrývajúce sa prefixy vytvárajú inú poruchu, ktorá z klienta vyzerá podobne.

Overte prefixy v oboch smeroch

Prostriedok brány miestnej siete obsahuje miestne prefixy a tie musia zodpovedať podsietiam, ktoré vzdialené zariadenie skutočne chráni. Zhrnutie, ktoré obsahuje adresy, ktoré zariadenie zahadzuje, prepustí niektoré toky a na iných zlyhá, čo sa číta ako občasná porucha smerovania a nie ako nesúlad konfigurácie. Skontrolujte aj protistranu: jeden koniec uvádza /16, zatiaľ čo druhý uvádza tri /24 vnútri — to je klasické čiastočné zlyhanie. Ani jeden zoznam nie je sám o sebe smerodajný, preto ich porovnajte vedľa seba, namiesto toho, aby ste dôverovali tomu, ktorý vidíte.

Zmena prefixu sa nie vždy prevezme sama, preto naplánujte opätovné uloženie alebo opätovné vytvorenie objektu pripojenia a potom potvrďte, že nové prefixy sa objavia na oboch stranách.

Testujte cestu, nie ping

Trasovanie, ktoré oddeľuje funkčný tunel od funkčnej trasy, vyzerá takto: prvý hop je miestna brána, potom niekoľko neodpovedajúcich hopov, potom vzdialený hostiteľ odpovie. Ak trasovanie nikdy nedorazí k hostiteľovi, otestujte port TCP, ktorý aplikácia skutočne používa, pretože ICMP sa filtruje dosť často na to, aby neúspešný ping dokázal veľmi málo. Spustite rovnaké trasovanie zo vzdialeného hostiteľa smerom k virtuálnemu počítaču v Azure. Asymetria medzi oboma výsledkami je najrýchlejší spôsob, ako nájsť chýbajúcu spätnú trasu alebo pravidlo, ktoré povoľuje len jeden smer.

Zapíšte návrh protistrany, oba adresné priestory a čas vytvorenia pripojenia do tiketu, aby ďalší inžinier vedel, ktoré hodnoty sa prestavali a ktorých sa nikto nikdy nedotkol.

Ak sa protokol vráti prázdny, brána možno vaše pripojenie vôbec neukončuje. Potvrďte, že adresa protistrany na bráne miestnej siete zodpovedá zariadeniu, z ktorého protokol čítate, pretože dve brány v jednom predplatnom sa pri prestavbe ľahko pomýlia. Táto chyba stojí deň a nezanechá stopu v žiadnom protokole.