Ověření toku IP v Azure hlásí povoleno, ale VPN stále selhává

Tunel site-to-site je připojený, virtuální počítač je v pořádku, ale lokální klient nic nedostává. Otevřete Network Watcher, spustíte ověření toku IP a ono řekne Access allowed, takže se tiket uzavře jako problém s VPN. Tento výsledek neznamená to, co vypadá, protože ověření toku IP vyhodnocuje bezpečnostní pravidla pro tok, který jste popsali, a nikdy netestuje, zda má Azure trasu k vašemu lokálnímu prefixu.

Otázka filtrování a otázka směrování jsou oddělené a Network Watcher na ně odpovídá různými nástroji. Vědět, na kterou jste se ptali, je většina diagnózy.

Co ověření toku IP skutečně rozhoduje

Ověření toku IP vezme virtuální počítač, síťové rozhraní, směr, hodnoty pětice a protokol a poté nahlásí rozhodnutí pravidel NSG a správce zabezpečení pro tento tok. Funguje na TCP a UDP, takže to není tester pravidel ICMP a zablokovaný ping nic o vaší službě nedokazuje. Dejte mu skutečný tok, ne odhad. Příchozí připojení z lokální sítě k portu databáze je jiný popis než odchozí připojení, které iniciuje virtuální počítač.

Pokud brána překládá adresy, použijte zdrojovou adresu, která dosáhne hranice, kterou vyhodnocujete, ne tu v konfiguraci klienta. Čtěte výsledek i takový, jaký je. Access allowed znamená, že filtrační vrstva by paket propustila, kdyby dorazil, a nic víc.

Co vám nemůže říct, je trasa, kterou Azure vybral, zda hostitelský firewall povoluje port nebo zda něco poslouchá. To žije v jiných vrstvách.

Co přidávají další hop a efektivní trasy

Další hop odpovídá na otázku předávání: pro tento cíl jaký typ dalšího hopu Azure zvolí, na jaké adrese, ze které směrovací tabulky. Efektivní trasy vypisují, co NIC skutečně má. Spusťte obojí a získáte cestu na straně Azure, kterou zelené ověření toku IP nechává prázdnou.

Přehled ověření toku IP od Microsoftu přímo uvádí rozsah filtrování, zatímco stránky o dalším hopu a diagnostice tras pokrývají stranu předávání. Citujte správnou stránku, když sepisujete zjištění.

Příkazy jsou dost krátké na spuštění z shellu. az network nic show-effective-route-table vypíše trasy použité na rozhraní. az network watcher show-next-hop se zdrojem a cílem vrátí zvolený hop. Porovnejte prefix, na kterém vám záleží, s touto tabulkou a poté potvrďte, která položka vyhrává.

Projděte zpětnou cestu z NIC virtuálního počítače

Dělejte to z NIC cílového virtuálního počítače, pro prefix lokálního klienta, ne pro internet. Zpětná cesta je místo, kde se skrývají závady site-to-site, protože kontrola stavu tunelu pouze hlásí, že přidružení zabezpečení jsou navázaná.

Pokud očekávaná trasa chybí, zkontrolujte vzdálené prefixy, které poskytuje konfigurace brány, návrh připojení VNet a jakékoli nastavení šíření tras. Objekt brány lokální sítě popisuje lokální stranu; jeho existence nedokazuje, že každý požadovaný prefix je na NIC přítomen a preferován. To jsou různé skutečnosti a jen jedna z nich se objeví v souhrnu portálu.

Čtěte typ dalšího hopu, místo abyste kopírovali příklad

Cesta spravované brány VPN obvykle ukazuje VirtualNetworkGateway jako typ dalšího hopu. VirtualAppliance popisuje jiný návrh předávání, obvykle firewall nebo síťové virtuální zařízení.

Nevytvářejte trasu zařízení směrem na odhadovaný koncový bod VPN jen proto, že stará odpověď na fóru tento typ použila. Pokud trasa definovaná uživatelem přepisuje zamýšlenou cestu, najděte jejího vlastníka a účel, než ji změníte. Druhá NIC může také změnit, které rozhraní host používá, a její odebrání může rozbít jinou službu, místo aby tuto trasu opravilo.

Přejděte k hranici, která stále selhává

Když filtrování i směrování odpovídají návrhu, závada je jinde. Zkontrolujte vlastní směrovací tabulku hosta, jeho firewall a zda je naslouchající proces svázán s očekávanou adresou. Poté zkontrolujte chráněné selektory provozu VPN a lokální cestu odpovědi. Každá z nich je samostatný test se samostatným výsledkem.

Uzavřete povoleným požadavkem aplikace a pozorováními z obou stran. Výsledek allow a správný další hop jsou dva kusy důkazů, ne důkaz, že spojení uspělo.