Azure P2S: Windows bezero batek bideak galtzen ditu VNet aldaketaren ondoren

Bi eramangarrik Azure point-to-site gateway berberaren aurrean autentifikatzen dute, eta bakarra iristen da duela gutxi konektatutako VNet-era. Biek Connected erakusten dute, beraz autentifikazioa ez da aldea; bakoitzak dituen helmuga-bideak dira aldea. Huts egiten duen bezerotik hasi, helmuga bakarra alderatu, eta geroago erabaki ea hutsunea gateway paketearena edo tokiko bide-taularena den.

Hasi huts egiten duen bezerotik, ez gatewaytik

Egiaztatu topologia eramangarria errudun egin aurretik. Begiratu zein VNet dauden gateway-ren VNet-era konektatuta eta sare berria zuzenean peeratuta dagoen edo site-to-site tunel bereizi baten bidez iristen den. VNet berria gateway-ren VNet-era batere konektatuta ez badago, bezero pakete batek ere ezin du hara bideratu, eta funtzionatzen duen eramangarria azaldu beharreko anomalia da. Idatzi erantzuna, horrek erabakitzen baitu bezero bat edo gateway bat arazten ari zaren.

Topologia zuzen dagoenean, jarri bi eramangarriak elkarren ondoan. Gateway bera, helbide-pool bera, protokolo bera eta bezero bertsio bera dira nahi duzun alderaketa; beste edozein gauza geroago kendu beharko duzun bigarren aldagaia da.

Alderatu helmuga bat route print erabiliz

Aukeratu baimendutako baliabide IP bat eta alderatu bi eramangarriak bitan: deskonektatuta, gero konektatuta. Windows-en route print -4 komandoak IPv4 bideak zerrendatzen ditu helmuga-prefixarekin, interfazearekin, hurrengo jauziarekin eta metrikarekin. Idatzi helmuga horretarako benetan irabaziko lukeen errenkada, VPN hitza duten sarrerak zenbatu beharrean.

Hautaketa prefixurik luzeenarekin hasten da, gero metrikarekin, beraz tokiko bide zehatzago batek tunelaren bidea garaitu dezake okerrik eman gabe. Nahi den helmuga 10.24.0.0/16 barruan badago, bezero osasuntsuak bat datorren bidea erakusten du VPN interfazean, eta huts egiten duen bezeroak helbide bera bidaltzen dio bere gateway lehenetsiari.

Tokiko prefixu gatazkatsu batek sintoma bera sor dezake. Ezer gehitu aurretik, erabaki bi kasuetatik zein duzun: tunel biderik batere ez, edo prefixu zehatzago baten aurka galtzen duen tunel bidea.

TTL expired ez da bide-banaketaren akats bat

TTL expired in transit itzultzen duen ping batek paketeak jauzi-kupoa agortu duela esaten du, eta horrek normalean birbidalketa begizta bat esan nahi du, ez VPN kontrolatzaile hautsia. Windows ping-ek 255era arteko TTL onartzen du, eta balioa igotzeak ez du begizta konpontzen; errore bera atzeratzen du soilik. Mezua bidearen sintomatzat hartu, ez bide-banaketari buruzko froga gisa.

Erabili tracert -4 10.24.1.10 bidea non errepikatzen den ikusteko. Bi jauzi berak behin eta berriz agertzen badira, bilatu tunelera doan trafikoa tunelera edo atzera bidaltzen duen tokiko bideratzailera itzultzen duen bidea.

Birsortu paketea jabea den gateway-an

Microsoft-ek dokumentatzen du Windows bezero paketeak berriro deskargatu eta instalatu behar direla topologia aldaketa garrantzitsuen ondoren. Hartu profil hau zerbitzatzen duen Azure gateway-tik uneko paketea, eta aplikatu bezero horretarako onartutako prozesuarekin. Erlazionatuta ez dagoen VPN aplikazio baten exekutagarria ordezkatzea ez da gateway-aren berariazko ezarpenak birsortzearen eragiketa bera. Paketea berriro deskargatzea merkea da; tokiko bideak asmatzea ez.

Konektatu berriro eta irakurri berriro jatorrizko helmugaren bidea. Gorde aurretik eta ondorengo errenkadak aldaketaren erregistroarekin, emaitza bezeroa berriz instalatu nuen baino zehatzagoa izan dadin.

Azure P2S bideratze-egoerek zuzenean peeratutako VNet-ak beste tunel batzuen bidez iristen diren sareetatik bereizten dituzte, eta pakete berri batek ezin du peeratzea iragankor bihurtu. Windows site-to-site edo BGP egoera batzuek eskuz konfiguratutako urruneko bideak behar dituzte ere, beraz paketea freskatzea ez da bide-banaketarako mekanismo unibertsala.

Eduki bide bat aldi baterako

Bide eskuzko batek falta den bezero bidea isolatu dezake, baina diseinu errealetik eraiki: route add 10.24.0.0 mask 255.255.0.0 172.16.0.1 if 42, bandera iraunkorrik gabe, berrabiaraztean desagertu dadin. Aukeratu interfazearen indizea eta hurrengo jauzia konektatutako VPN egokigailutik, ez suposiziotik.

Ez utzi bide esperimental bat lehiakide jabe iraunkor gisa. Etorkizuneko profil eguneraketek prefixu bera metrika ezberdinarekin gehi dezakete, eta orduan eskuzko sarrerak isilpean erabakitzen du zein bide irabazten duen. Idatzi kentzeko urratsa aldaketan.

Bide zuzena aktibo dagoenean, probatu helburuko aplikazioa ping baten ordez. Paketeak Azure-ra iristen badira baina zerbitzuak huts egiten jarraitzen badu, egiaztatu sareko segurtasun-taldea eta itzulera-bidea, horiek bereiziak baitira eramangarriak prefixua ikasi duen ala ez.