Tunel site-to-site je pripojený, virtuálny počítač je zdravý, ale lokálny klient nič nedostáva. Otvoríte Network Watcher, spustíte overenie toku IP a ono povie Access allowed, takže tiket sa uzavrie ako problém s VPN. Tento výsledok neznamená to, čo sa zdá, pretože overenie toku IP vyhodnocuje bezpečnostné pravidlá pre tok, ktorý ste opísali, a nikdy netestuje, či má Azure trasu k vášmu lokálnemu prefixu.

Otázka filtrovania a otázka smerovania sú oddelené a Network Watcher na ne odpovedá rôznymi nástrojmi. Vedenie o tom, ktorú ste položili, je väčšina diagnózy.

Čo overenie toku IP skutočne rozhoduje

Overenie toku IP vezme virtuálny počítač, sieťové rozhranie, smer, hodnoty pätice a protokol a potom nahlási rozhodnutie pravidla NSG a správcu zabezpečenia pre ten tok. Funguje na TCP a UDP, takže to nie je tester pravidiel ICMP a zablokovaný ping nič o vašej službe nedokazuje. Dajte mu skutočný tok namiesto odhadu. Prichádzajúce pripojenie z lokálnej siete k portu databázy je iný opis než odchádzajúce pripojenie, ktoré iniciuje virtuálny počítač.

Ak brána prekladá adresy, použite zdrojovú adresu, ktorá dosiahne hranicu, ktorú hodnotíte, nie tú v konfigurácii klienta. Čítajte výsledok aj taký, aký je. Access allowed znamená, že filtračná vrstva by paket prepustila, keby dorazil, a nič viac.

Čo vám nemôže povedať, je trasa, ktorú Azure vybral, či hostiteľský firewall povoľuje port alebo či niečo počúva. To žije v iných vrstvách.

Čo pridávajú ďalší hop a efektívne trasy

Ďalší hop odpovedá na otázku preposielania: pre tento cieľ aký typ ďalšieho hopu Azure zvolí, na akej adrese, z ktorej smerovacej tabuľky. Efektívne trasy vypisujú, čo NIC skutočne má. Spustite oboje a získate cestu na strane Azure, ktorú zelené overenie toku IP necháva prázdnu.

Prehľad overenia toku IP od Microsoftu priamo uvádza rozsah filtrovania, zatiaľ čo stránky o ďalšom hope a diagnostike trás pokrývajú stranu preposielania. Citujte správnu stránku, keď píšete zistenie.

Príkazy sú dosť krátke na spustenie z shellu. az network nic show-effective-route-table vypíše trasy použité na rozhraní. az network watcher show-next-hop so zdrojom a cieľom vráti zvolený hop. Porovnajte prefix, na ktorom vám záleží, s touto tabuľkou a potom potvrďte, ktorá položka vyhráva.

Prejdite spätnú cestu z NIC virtuálneho počítača

Robte to z NIC cieľového virtuálneho počítača, pre prefix lokálneho klienta, nie pre internet. Spätná cesta je miesto, kde sa skrývajú poruchy site-to-site, pretože kontrola stavu tunela iba hlási, že pridruženia zabezpečenia sú nadviazané.

Ak očakávaná trasa chýba, skontrolujte vzdialené prefixy, ktoré poskytuje konfigurácia brány, návrh pripojenia VNet a akékoľvek nastavenie šírenia trás. Objekt brány lokálnej siete opisuje lokálnu stranu; jeho existencia nedokazuje, že každý potrebný prefix je na NIC prítomný a preferovaný. To sú rôzne fakty a iba jeden z nich sa objaví v súhrne portálu.

Čítajte typ ďalšieho hopu namiesto kopírovania príkladu

Cesta cez spravovanú bránu VPN zvyčajne ukazuje VirtualNetworkGateway ako typ ďalšieho hopu. VirtualAppliance opisuje iný návrh preposielania, zvyčajne firewall alebo sieťové virtuálne zariadenie.

Nevytvárajte trasu zariadenia k odhadovanému koncovému bodu VPN len preto, že stará odpoveď na fóre použila tento typ. Ak trasa definovaná používateľom prepisuje zamýšľanú cestu, nájdite jej vlastníka a účel, skôr než ju zmeníte. Druhá NIC môže tiež zmeniť, ktoré rozhranie host používa, a jej odstránenie môže pokaziť inú službu namiesto opravy tejto trasy.

Prejdite k hranici, ktorá stále zlyháva

Keď filtrovanie aj smerovanie zodpovedajú návrhu, porucha je inde. Skontrolujte vlastnú smerovaciu tabuľku hosťa, jeho firewall a či je počúvajúci proces naviazaný na očakávanú adresu. Potom skontrolujte chránené selektory prevádzky VPN a lokálnu cestu odpovede. Každá z nich je samostatný test so samostatným výsledkom.

Uzavrite povolenou požiadavkou aplikácie a pozorovaniami z oboch strán. Výsledok allow a správny ďalší hop sú dva kusy dôkazov, nie dôkaz, že spojenie uspelo.

Súvisiace články