Azure IP-fluo-kontrolo diras permesita, sed la VPN ankoraŭ malsukcesas

Reteja-al-reteja tunelo konektita, VM sana, la loka kliento ricevas nenion. Vi malfermas Network Watcher, rulas IP-fluo-kontrolon, kaj ĝi diras Access allowed, do la bileto fermiĝas kiel VPN-problemo. Tiu rezulto ne signifas tion, kion ĝi ŝajnas, ĉar IP-fluo-kontrolo taksas la sekurecajn regulojn por la fluo, kiun vi priskribis, kaj neniam testas, ĉu Azure havas itineron al via loka prefikso.

La filtra demando kaj la enkursiga demando estas apartaj, kaj Network Watcher respondas ilin per malsamaj iloj. Scii, kiun vi demandis, estas la plej granda parto de la diagnozo.

Kion IP-fluo-kontrolo efektive decidas

IP-fluo-kontrolo prenas VM, retan interfacon, direkton, kvinoblajn valorojn kaj protokolon, poste raportas la decidon de la NSG-regulo kaj de la sekureca administranto por tiu fluo. Ĝi funkcias sur TCP kaj UDP, do ĝi ne estas testilo de ICMP-reguloj, kaj blokita ping pruvas nenion pri via servo. Donu al ĝi la realan fluon anstataŭ konjekton. Envenanta konekto de la loka reto al datumbaza pordo estas alia priskribo ol eliranta konekto, kiun la VM iniciatas.

Se la pordego tradukas adresojn, uzu la fontadreson, kiu atingas la limon, kiun vi taksas, ne tiun en la klienta agordo. Legu la rezulton ankaŭ por tio, kio ĝi estas. Access allowed signifas, ke la filtra tavolo permesos la paketon se ĝi alvenus, kaj nenion pli.

Kion ĝi ne povas diri al vi estas la itinero, kiun Azure elektis, ĉu la gastiga fajroŝirmilo permesas la pordon, aŭ ĉu io aŭskultas. Tiuj vivas en aliaj tavoloj.

Kion la sekva salteto kaj efikaj itineroj aldonas

La sekva salteto respondas plusendan demandon: por ĉi tiu celloko, kiun sekvan-saltet-tipon Azure elektas, ĉe kiu adreso, el kiu itinera tabelo. Efikaj itineroj listigas, kion la NIC efektive havas. Rulu ambaŭ kaj vi ricevas la Azure-flankan vojon, kiun verda IP-fluo-kontrolo lasas malplena.

La superrigardo de IP-fluo-kontrolo de Microsoft rekte indikas la filtran amplekson, dum la paĝoj pri sekva salteto kaj itinera diagnozo kovras la plusendan flankon. Citu la ĝustan paĝon, kiam vi skribas la konstaton.

La komandoj estas sufiĉe mallongaj por ruli ilin el ŝelo. az network nic show-effective-route-table listigas la itinerojn aplikatajn al la interfaco. az network watcher show-next-hop kun fonto kaj celloko redonas la elektitan salteton. Komparu la prefikson, kiu gravas al vi, kun tiu tabelo, poste konfirmu, kiu ero venkas.

Piediru la revenan vojon de la NIC de la VM

Faru tion de la NIC de la cela VM, por la prefikso de la loka kliento, ne por la interreto. La reena vojo estas kie kaŝiĝas retej-al-retejaj fuŝoj, ĉar tunela statokontrolo nur raportas, ke la sekurecaj asocioj estas aktivaj.

Se la atendata itinero mankas, kontrolu la malproksimajn prefiksojn, kiujn la pordega agordo liveras, la VNet-konektecdezajnon kaj ajnan itinero-disvastigan agordon. Loka retpordega objekto priskribas la lokan flankon; ĝia ekzisto ne pruvas, ke ĉiu bezonata prefikso ĉeestas kaj preferatas ĉe la NIC. Tiuj estas malsamaj faktoj, kaj nur unu el ili aperas en pordega resumo.

Legu la sekvan-saltet-tipon anstataŭ kopii ekzemplon

Vojo tra administrata VPN-pordego kutime montras VirtualNetworkGateway kiel sekvan-saltet-tipon. VirtualAppliance priskribas alian plusendan dezajnon, kutime fajroŝirmilon aŭ retan virtualan aparaton.

Ne kreu aparatan itineron al konjektita VPN-finpunkto ĉar malnova forumrespondo uzis tiun tipon. Se uzant-difinita itinero anstataŭigas la celatan vojon, trovu ĝian posedanton kaj celon antaŭ ol ŝanĝi ĝin. Dua NIC ankaŭ povas ŝanĝi, kiun interfacon la gasto uzas, kaj forigi ĝin povas rompi alian servon anstataŭ ripari ĉi tiun itineron.

Transiru al la limo, kiu ankoraŭ malsukcesas

Kiam filtrado kaj enkursigo ambaŭ kongruas kun la dezajno, la fuŝo estas aliloke. Kontrolu la propran itineran tabelon de la gasto, ĝian fajroŝirmilon kaj ĉu la aŭskultanto estas ligita al la atendata adreso. Poste kontrolu la protektitajn trafik-selektilojn de la VPN kaj la lokan respondan vojon. Ĉiu el ili estas aparta testo kun aparta rezulto.

Fermu per permesita aplika peto kaj observoj de ambaŭ flankoj. Permesa rezulto kaj ĝusta sekva salteto estas du pecoj da pruvo, ne pruvo, ke la konekto sukcesis.