Azure VPN typu site-to-site s partnerem za NAT: kontrolní seznam

Projděte tyto kontroly v pořadí a zastavte se u první, která selže. Většina hlášení, že Azure nepodporuje zařízení za NAT, se nakonec ukáže jako adresa partnera, na kterou se Azure nedostane, nebo tunel, který se nikdy neiniciuje ze správné strany. Vnější přenos a vnitřní směrování jsou dva různé problémy a jejich mícháním ztratíte odpoledne. Každý krok níže vytvoří pozorování, které můžete předat někomu jinému.

Krok 1: ověřte, že partner je vůbec za NAT

Porovnejte adresu na WAN rozhraní zařízení s adresou, kterou pro něj vidí Azure. Pokud se liší, něco překládá, a tento překladač je nyní součástí vašeho návrhu VPN. Zeptejte se poskytovatele, zda je mapování statické, nebo sdílené, protože sdílené mapování mění to, na co se můžete spolehnout. Zařízení s privátní WAN adresou a bez předávání je jiný případ než zařízení za NAT operátorské úrovně se stabilním veřejným mapováním.

Pokud se obě adresy shodují, zastavte se zde: NAT není váš problém a zbytek seznamu nepomůže.

Zapište obě adresy a model překladače do tiketu. Ten jeden řádek zabrání dalšímu kolu otázek, proč nakonfigurovaný partner neodpovídá.

Krok 2: dohodněte se, kdo iniciuje

Nejčastější dotazy k Azure VPN Gateway uvádějí podporu NAT-T a dodávají, že místní zařízení má iniciovat tunel IPsec, když je za NAT. To odpovídá tomu, jak funguje překlad se stavem, protože překladač drží mapování proto, že vnitřní zařízení poslalo první paket. Pokud se očekává, že iniciuje Azure, a nic nepřijde, aby to mapování vytvořilo, tunel nikdy nezačne.

Nakonfigurujte partnera tak, aby byla chyba pouze odpovídající strany zřejmá, a zkontrolujte, zda zařízení zkouší znovu samo, nebo potřebuje podnět. Některá zařízení zvednou tunel jen tehdy, když se objeví zajímavý provoz, což je v pořádku, dokud zajímavým provozem není zdravotní sonda, která nikdy nepřijde.

Sledujte výměnu IKE na zařízení během ručního spuštění; ticho tam je odpověď směrování nebo firewallu, ne Azure.

Krok 3: nastavte adresu partnera správně

Azure potřebuje dostupnou veřejnou adresu partnera ve svém objektu brány místní sítě, obvykle veřejnou adresu překladače, nikoli vnitřní adresu zařízení. Identita, kterou se zařízení autentizuje, je samostatné pole a může se legitimně lišit od adresy, na kterou Azure vytáčí. Držte obě rovně, protože jejich záměna vytvoří chybu ověřování, která vypadá přesně jako problém s NAT.

Pokud se veřejná adresa změní, musí se s ní změnit i tento objekt. Jméno, které se překládá na zastaralou adresu, je horší než statická adresa, kterou musíte aktualizovat ručně.

Zapište všechny tři hodnoty: místní adresu zařízení, přeloženou veřejnou adresu a nakonfigurovanou identitu partnera.

Krok 4: otevřete jen porty, které NAT-T potřebuje

NAT-T přenáší ESP uvnitř UDP a RFC 3948 popisuje toto zapouzdření s portem 4500 používaným po počátečním vyjednávání na portu 500. Váš firewall i překladač musí povolit výměnu i její zpětný provoz. Povolení nesouvisejícího TCP portu nic o této cestě neprokazuje a pravidlo, které povolí odchozí provoz, ale ne odpověď, stále selže.

Statické přesměrování příchozího portu není automaticky nutné, když partner iniciuje a překladač drží stav. Nutné je, když je mapování nestabilní nebo když něco na cestě agresivně ruší stav.

Zachyťte jednou na obou stranách překladače; rozdíl v zapouzdření je okamžitě vidět.

Krok 5: oddělte vnější přenos od vnitřního směrování

Tunel, který se naváže a nic nepřenáší, je problém směrování, ne NAT-T. Lokality stále potřebují kompatibilní selektory provozu, shodné adresní prostory, pravidla přístupu a zpětnou cestu pro aplikační sítě. Nic z toho úspěšná výměna IKE neposkytuje.

Pokud obě lokality používají překrývající se privátní rozsahy, překlad uvnitř tunelu je samostatný návrh s vlastními pravidly. Nepřečíslovávejte podsíť jen proto, že vnější brána náhodou sedí za domácím routerem.

Než cokoli změníte, klasifikujte selhání podle fáze a tuto klasifikaci ponechte v tiketu, aby příští člověk začal tam, kde jste vy skončili.