S2S VPN v Azure je připojená, ale neprochází provoz: čtěte IKE log

Portál píše Connected, tunel má počítadlo doby běhu a trasování z vašeho virtuálního počítače umírá na druhém hopu. Stav připojení popisuje vyjednávání IKE a IPsec, ne to, zda jeden paket přežije vrstvu zásad na kterékoli straně. Většinu takových tiketů vysvětlují dvě závady a ani jednu z nich neopraví změna trasy v Azure. Obě už jsou zapsané v logu, který brána vytvořila, proto začínám tam, a ne v tabulce tras.

Co Connected skutečně potvrzuje

Připojené spojení site-to-site znamená, že fáze 1 a fáze 2 jsou dokončené a bezpečnostní asociace jsou nahoru. To je tvrzení o vyjednávání: obě strany se dohodly na návrhu, vyměnily klíče a nainstalovaly dvojici SA. Nic neříká o tom, zda selektory provozu odpovídají podsítím, které považujete za chráněné, ani o tom, zda protější strana paket po dešifrování někam pošle. Tunel může stát týdny a zahazovat každý zajímavý tok, a to je přesně vzorec, kvůli kterému lidé přestavují zdravou bránu.

Dvě závady, které stojí za to zkontrolovat nejdřív, jsou protistrana nabízející AH místo ESP a virtuální síť číslovaná v prostoru, který brána nebude považovat za interní.

Otevřete exportovaný log, než se dotknete tras

V portálu otevřete bránu virtuální sítě a spusťte operaci VPN troubleshoot nad připojením, potom stáhněte balíček, který vytvoří, a rozbalte ho. Uvnitř je IKE log s výměnami fáze 1 a fáze 2, s časovými značkami a čitelný jako prostý text. Hledejte v něm řádek transform místo čtení shora dolů, protože zajímavý záznam bývá o několik set řádků níž. Pokud nemáte přístup do portálu, stejná diagnostika se objeví v cíli logů brány, když jsou zapnutá diagnostická nastavení.

Dva záznamy nesou většinu hodnoty. První zní přibližně expected ESP with combined authentication and cipher, received AH. Druhý je chyba neplatného payloadu během výměny IKE, což obvykle znamená špatně vytvořené nebo nepodporované pole návrhu.

Oba popisují, co nabídlo místní zařízení, takže oba jsou nastavení na straně protistrany. Opětovné vygenerování strany Azure připojení nemění návrh, který vaše firewall posílá, a dělat to i tak je nejčastější ztracená hodina v tomto postupu. Na protistraně nastavte fázi 2 na ESP s kombinovaným ověřováním a šifrou a nechte ji vyjednat algoritmus, potom zkontrolujte, zda zaškrtávací políčko dodavatele s názvem jako combined mode potichu nevybírá návrh AH.

Potvrďte adresní prostor virtuální sítě

Brána očekává, že virtuální síť bude v privátních rozsazích. Síť číslovaná ve veřejném bloku, třeba začínající 111.x, může tunel zvednout, zatímco Azure odmítá považovat tento prostor za interní, takže připojení vypadá zdravě a žádný tok není přijat. Potvrďte adresní prostor, než strávíte odpoledne nad selektory. Pokud je číslování tvrdým požadavkem ze staršího přidělení, opravou je změna adresního plánu, ne jiná brána.

Zapište překryv s místními rozsahy, dokud jste v okně adresního prostoru, protože překrývající se prefixy vytvářejí jinou závadu, která z klienta vypadá podobně.

Ověřte prefixy v obou směrech

Prostředek brány místní sítě drží místní prefixy a ty musí odpovídat podsítím, které vzdálené zařízení skutečně chrání. Souhrn, který obsahuje adresy, jež zařízení zahazuje, propustí některé toky a na jiných selže, což se čte jako občasná závada směrování, a ne jako nesoulad konfigurace. Zkontrolujte i protější stranu: jeden konec uvádí /16, zatímco druhý uvádí tři /24 uvnitř něj — to je klasické částečné selhání. Ani jeden seznam není sám o sobě směrodatný, proto je porovnejte vedle sebe, místo abyste věřili tomu, který vidíte.

Změna prefixu se ne vždy projeví sama, proto počítejte s tím, že objekt připojení znovu uložíte nebo vytvoříte, a potom potvrďte, že se nové prefixy objeví na obou stranách.

Testujte cestu, ne ping

Trasování, které odděluje funkční tunel od funkční trasy, vypadá takto: první hop je místní brána, pak několik neodpovídajících hopů, pak vzdálený hostitel odpoví. Pokud trasování nikdy nedorazí k hostiteli, otestujte port TCP, který aplikace skutečně používá, protože ICMP se filtruje dost často na to, aby neúspěšný ping dokázal jen velmi málo. Spusťte stejné trasování ze vzdáleného hostitele k virtuálnímu počítači v Azure. Asymetrie mezi oběma výsledky je nejrychlejší způsob, jak najít chybějící zpětnou trasu nebo pravidlo, které povoluje jen jeden směr.

Zapište návrh protistrany, oba adresní prostory a čas vytvoření připojení do tiketu, aby další inženýr věděl, které hodnoty byly přestavěny a kterých se nikdo nedotkl.

Pokud se log vrátí prázdný, brána možná vaše připojení vůbec neukončuje. Potvrďte, že adresa protistrany v bráně místní sítě odpovídá zařízení, ze kterého log čtete, protože dvě brány v jednom předplatném se při přestavbě snadno pletou. Tahle chyba stojí den a nezanechá stopu v žádném logu.