Azure P2S: unu Windows-kliento perdas itinerojn post VNet-ŝanĝo

Du tekokomputiloj aŭtentiĝas ĉe la sama Azure point-to-site-pordego, kaj nur unu atingas la ĵuse konektitan VNet-on. Ambaŭ montras Connected, do aŭtentigo ne estas la diferenco; la celitineraro, kiun ili tenas, estas. Komencu ĉe la kliento, kiu malsukcesas, komparu unu solan celon, kaj nur poste decidu, ĉu la pordega pakaĵo aŭ la loka itinertabelo posedas la breĉon.

Komencu ĉe la kliento, kiu malsukcesas, ne ĉe la pordego

Konfirmu la topologion antaŭ ol kulpigi la tekokomputilon. Kontrolu, kiuj VNet-oj estas konektitaj al la pordega VNet, kaj ĉu la nova reto estas rekte peerita aŭ atingebla per aparta site-to-site-tunelo. Se la nova VNet tute ne estas konektita al la pordega VNet, neniu klienta pakaĵo povas itineri al ĝi, kaj la funkcianta tekokomputilo estas la anomalio klarigenda. Skribu la respondon, ĉar ĝi decidas, ĉu vi sencimigas klienton aŭ pordegon.

Kiam la topologio ĝustas, metu la du tekokomputilojn unu apud la alia. Sama pordego, sama adresaro, sama protokolo kaj sama klienta versio estas la komparo, kiun vi volas; io ajn alia estas dua variablo, kiun vi devos ekskludi poste.

Komparu unu celon per route print

Elektu permesitan IP de rimedo kaj komparu ambaŭ tekokomputilojn dufoje: malkonektitaj, poste konektitaj. En Windows route print -4 listigas IPv4-itinerojn kun celprefikso, interfaco, sekva salto kaj metriko. Notu la vicon, kiu efektive venkus por tiu celo, anstataŭ kalkuli erojn enhavantajn la vorton VPN.

La elekto estas unue la plej longa prefikso, poste la metriko, do pli specifa loka itinero povas venki la tunelan itineron sen aspekti malĝusta. Se la celata celo estas ene de 10.24.0.0/16, sana kliento montras kongruan itineron sur la VPN-interfaco, dum la fiaskanta kliento sendas la saman adreson al sia defaŭlta pordego.

Konflikta loka prefikso povas kaŭzi la saman simptomon. Antaŭ ol aldoni ion, decidu, kiun el la du kazoj vi havas: tute neniun tunelan itineron, aŭ tunelan itineron, kiu perdas al pli specifa.

TTL expired ne estas itinera distribua cimo

Ping, kiu redonas TTL expired in transit, diras, ke la pakaĵo elĉerpis sian saltokvanton, kio kutime signifas plusendan buklon, ne rompitan VPN-pelilon. Windows-ping akceptas TTL ĝis 255, kaj plialtigi la valoron ne riparas buklon; ĝi nur prokrastas la saman eraron. Traktu la mesaĝon kiel simptomon de la vojo, ne kiel pruvon pri itinera distribuo.

Uzu tracert -4 10.24.1.10 por vidi, kie la vojo ripetiĝas. Se la samaj du saltoj aperas denove kaj denove, serĉu itineron, kiu resendas tunelceltan trafikon en la tunelon aŭ en lokan enkursigilon, kiu plusendas ĝin reen.

Regenu la pakaĵon ĉe la pordego, kiu posedas ĝin

Microsoft dokumentas, ke Windows-klientaj pakaĵoj devas esti elŝutitaj kaj instalitaj denove post signifaj topologiaj ŝanĝoj. Prenu la aktualan pakaĵon de la Azure-pordego, kiu servas ĉi tiun profilon, kaj apliku ĝin per la subtenata procezo por tiu kliento. Anstataŭigi plenumeblon de nerilata VPN-aplikaĵo ne estas la sama operacio kiel regieneri pordegspecifajn agordojn. Elŝuti la pakaĵon denove estas malmultekosta; diveni lokajn itinerojn ne estas.

Rekonektiĝu kaj relegu la itineron por la origina celo. Konservu la vicojn antaŭ kaj post kune kun la ŝanĝregistro, por ke la rezulto estu pli preciza ol mi reinstalis la klienton.

La Azure P2S-itineraj scenaroj apartigas rekte peeritajn VNet-ojn de retoj atingataj per aliaj tuneloj, kaj nova pakaĵo ne povas igi peeradon transira. Iuj Windows site-to-site aŭ BGP-scenaroj ankaŭ bezonas permane agorditajn malproksimajn itinerojn, do pakaĵa refreŝigo ne estas universala itinera distribua mekanismo.

Lasu provizoran itineron provizora

Permana itinero povas izoli mankan klientan itineron, sed konstruu ĝin el la reala dezajno: route add 10.24.0.0 mask 255.255.0.0 172.16.0.1 if 42, sen la persista flago, por ke ĝi malaperu ĉe restarto. Elektu la interfacan indekson kaj sekvan salton el la konektita VPN-adaptilo, ne el supozo.

Ne lasu eksperimentan itineron kiel permanentan konkurencan posedanton. Estontaj profilaj ĝisdatigoj povas aldoni la saman prefikson kun alia metriko, kaj tiam la permana ero silente decidas, kiu vojo venkas. Notu la forigpaŝon en la ŝanĝo.

Kiam la ĝusta itinero estas aktiva, testu la celan aplikaĵon anstataŭ ping. Se pakaĵoj atingas Azure sed la servo ankoraŭ malsukcesas, kontrolu la retan sekurecan grupon kaj la revenan vojon, ĉar tiuj estas apartaj de tio, ĉu la tekokomputilo lernis la prefikson.