Azure’i IP-voo kontroll ütleb, et lubatud, aga VPN ikka ei tööta

Site-to-site tunnel on ühendatud, VM on terve, kohalik klient ei saa midagi. Avate Network Watcheri, käivitate IP-voo kontrolli ja see ütleb Access allowed, nii et pilet suletakse VPN-i probleemina. See tulemus ei tähenda seda, millega ta sarnaneb, sest IP-voo kontroll hindab kirjeldatud voolu turvareegleid ega testi kunagi, kas Azure’il on marsruut teie kohaliku prefiksini.

Filtreerimise küsimus ja marsruutimise küsimus on eraldi ning Network Watcher vastab neile erinevate tööriistadega. Teadmine, millise küsimuse esitasite, on suurem osa diagnoosist.

Mida IP-voo kontroll tegelikult otsustab

IP-voo kontroll võtab VM-i, võrguliidese, suuna, viisekordse väärtused ja protokolli ning teatab seejärel selle voolu NSG- ja turbeeksperdi reegli otsuse. See töötab TCP ja UDP-ga, seega ei ole see ICMP reeglite testija ja blokeeritud ping ei tõesta teie teenuse kohta midagi. Andke talle tegelik vool, mitte oletus. Sissetulev ühendus kohalikust võrgust andmebaasi pordini on erinev kirjeldus kui VM-i algatatud väljuv ühendus.

Kui lüüs tõlgib aadresse, kasutage lähteaadressi, mis jõuab teie hinnatava piirini, mitte seda, mis on kliendi konfiguratsioonis. Lugege ka tulemust sellena, mis see on. Access allowed tähendab, et filtreerimiskiht lubaks paketi, kui see saabuks, ja mitte midagi enamat.

Mida see teile öelda ei saa, on Azure’i valitud marsruut, kas külasüsteemi tulemüür lubab porti või kas midagi kuulab. Need elavad teistel kihtidel.

Mida järgmine hüpe ja efektiivsed marsruudid lisavad

Järgmine hüpe vastab edastamise küsimusele: selle sihtkoha jaoks millise järgmise-hüppe tüübi Azure valib, millisel aadressil, millisest marsruuditabelist. Efektiivsed marsruudid loetlevad, mis NIC-l tegelikult on. Käivitage mõlemad ja saate Azure’i-poolse tee, mille roheline IP-voo kontroll tühjaks jätab.

Microsofti IP-voo kontrolli ülevaade märgib filtreerimisulatuse otse, samas kui järgmise hüppe ja marsruudi diagnoosimise lehed katavad edastamise poole. Tsiteerige õiget lehte, kui leidu kirja panete.

Käsud on piisavalt lühikesed, et neid kestast käivitada. az network nic show-effective-route-table loetleb liidesele rakendatud marsruudid. az network watcher show-next-hop allika ja sihtkohaga tagastab valitud hüppe. Võrrelge teid huvitavat prefiksit selle tabeliga ja kinnitage seejärel, milline kirje võidab.

Kõndige tagasiteed VM-i NIC-lt

Tehke seda siht-VM-i NIC-lt kohaliku kliendi prefiksi jaoks, mitte interneti jaoks. Tagasitee on koht, kus site-to-site tõrked peituvad, sest tunneli oleku kontroll teatab ainult, et turbeseosed on üleval.

Kui oodatud marsruut puudub, kontrollige lüüsi konfiguratsiooni antavaid kaugprefikseid, VNet-i ühenduvuse disaini ja kõiki marsruudi levitamise seadeid. Kohaliku võrgu lüüsi objekt kirjeldab kohalikku poolt; selle olemasolu ei tõesta, et iga vajalik prefiks on NIC-l olemas ja eelistatud. Need on erinevad faktid ja ainult üks neist ilmub portaali kokkuvõttes.

Lugege järgmise hüppe tüüpi, mitte ärge kopeerige näidet

Hallatud VPN-lüüsi tee näitab tavaliselt VirtualNetworkGateway järgmise hüppe tüübina. VirtualAppliance kirjeldab teistsugust edastusdisaini, tavaliselt tulemüüri või võrgu virtuaalseadet.

Ärge looge seadme marsruuti oletatava VPN-i lõpp-punkti suunas seetõttu, et vana foorumivastus kasutas seda tüüpi. Kui kasutaja määratud marsruut tühistab kavandatud tee, leidke enne selle muutmist selle omanik ja eesmärk. Teine NIC võib samuti muuta, millist liidest külaline kasutab, ja selle eemaldamine võib selle marsruudi parandamise asemel mõne muu teenuse katki teha.

Liikuge piirini, mis ikka ei tööta

Kui filtreerimine ja marsruutimine mõlemad vastavad disainile, on viga mujal. Kontrollige külalise enda marsruuditabelit, selle tulemüüri ja seda, kas kuulaja on seotud oodatud aadressiga. Seejärel kontrollige VPN-i kaitstud liikluse selektoreid ja kohalikku vastusteede. Igaüks neist on eraldi test eraldi tulemusega.

Lõpetage lubatud rakendusepäringu ja mõlema otsa vaatlustega. Lubamise tulemus ja õige järgmine hüpe on kaks tõenditükki, mitte tõestus, et ühendus õnnestus.