VPN-itinero fiksita al interfaca indekso rompiĝas ĉe rekonekto

La itinero funkciis dum semajnoj kaj poste komencis sendi trafikon nenie, dum la celloko restis senŝanĝa kaj nenio estis redaktita. Tio, kio ŝanĝiĝis, estas la numero: itinero kreita kontraŭ difinita interfaca indekso referencas adaptilon kiu ne plu ekzistas post rekonekto, kaj la celloka prefikso daŭre montras al infrastrukturo kiu estis anstataŭigita. Aldoni persiston al tiu komando ne helpas, ĉar la problemo neniam estis ĉu la itinero postvivas restartigon. La solvo estas ligi la intencon al la konekto, kiu postvivas adaptilajn ŝanĝojn laŭkonstrue.

Kontrolu al kio la itinero efektive montras

Komencu legante la itineran enskribon kaj la adaptilojn unu apud la alia. Itinero kun sekva salto sur la VPN-interfaco kaj indekso kiu kongruas kun neniu nuna adaptilo estas la signo de ĉi tiu paneo; la sama prefikso sur alia indekso estas aŭ restaĵo aŭ la itinero kiun vi efektive volas. Legu ambaŭ listojn antaŭ ol ŝanĝi iun ajn, ĉar la interesa komparo estas inter la numero en la itinero kaj la numeroj kiuj nun ekzistas. Se la indekso de la itinero aperas en la adaptilla listo, la indekso ne estas via problemo kaj la serĉo moviĝas al metrikoj, politiko aŭ la malproksima flanko. Se ĝi ne aperas, nenio plu devas esti diagnozita: la itinero estas ligita al infrastrukturo kiu ne plu ekzistas.

Get-NetRoute -DestinationPrefix '10.77.0.0/16' | Select-Object DestinationPrefix, NextHop, InterfaceIndex, Store
Get-NetAdapter | Where-Object InterfaceDescription -like '*VPN*' | Select-Object Name, InterfaceIndex, InterfaceDescription
Get-VpnConnection -Name 'Lab VPN' | Select-Object Name, ServerAddress, SplitTunneling

La kolumno Store distingas enskribon kiu daŭras tra restartigoj disde unu kiu malaperas kun la adaptilo, kaj tiu diferenco determinas ĉu la paneo reaperos morgaŭ. Enskribo en la persista konservejo kiu montras al malaperinta indekso estas la plej malbona kazo, ĉar ĝi postvivas restartigojn dum ĝi neniam kongruas kun io ajn.

Ligu la prefikson al la profilo, ne al la adaptilo

Denaska Windows-VPN povas porti sian propran itineran liston, do la konekto reuzas la ĝustan adaptilon kiam ajn ĝi aperas. Tiam la itinero sekvas la profilon anstataŭ numeron kiun vi observis unufoje, kaj neniu skripto devas diveni indekson post ĉiu vokado. Aldoni prefikson ankaŭ estas malfarebla per la responda foriga komando, kio tenas la ŝanĝon aŭdebla. La prefikso konserviĝas kun la konekto anstataŭ en praŝarga skripto, do profilo kopiita al alia uzanto portas la intencon kun si.

Add-VpnConnectionRoute -ConnectionName 'Lab VPN' -DestinationPrefix '10.77.0.0/16' -PassThru

La referenco por Add-VpnConnectionRoute dokumentas la ligon al la konekto, kaj la amplekso de la telefonlibro gravas: profilo por unu uzanto kaj profilo por ĉiuj uzantoj estas malsamaj objektoj. Ĉi tiu mekanismo apartenas al la propra VPN-kliento de Windows, do vendista adaptilo administrata de sia propra servo povas preni siajn itinerojn el tute alia politika fonto.

Purigu malnovajn itinerojn antaŭ ol aldoni la novan

Du itineroj kun la sama prefikso kaj malsamaj posedantoj estas pli malbone ol unu malĝusta itinero, ĉar la venkinto dependas de metrikoj kiujn neniu skribis. Inspektu kio jam ekzistas por la prefikso, inkluzive enskribojn en la persista konservejo, kaj forigu nur tion kio apartenas al la malsukcesa provo. Restaĵo el antaŭa dezajno estas kutima en ĉi tiu areo, ĉar la paneanta itinero kutime anstataŭigis ion kio funkciis. Notu kiuj enskriboj apartenas al kiu konekto antaŭ ol forigi ion ajn, kaj konservu la liston en la ŝanĝprotokolo.

Get-NetRoute -AddressFamily IPv4 | Where-Object DestinationPrefix -like '10.77.*'
Remove-NetRoute -DestinationPrefix '10.77.0.0/16' -NextHop '0.0.0.0' -Confirm:$false

Kongruigu prefikson, sekvan salton, konservejon kaj posedanton kune anstataŭ forigi ĉion kio aspektas simila. Alia konekto povas laŭleĝe dependi de parto de tiu spaco, kaj balaa forigo transformas ordan riparon en subtenan incidenton.

Rekonektu en alia ordo

Reproduktu la kondiĉon anstataŭ esperi ke la unua provo estis reprezenta. Malkonektu, rekonektu, kaj konfirmu la elektitan vojon al la sama malproksima rimedo dum la tunelo estas aktiva; kun pluraj VPN-oj en la ludo, levu ilin en alia ordo kaj observu ĉu la elektita vojo ŝanĝiĝas. Ordo estas la variablo plej multaj preterlasas, kaj ĝi estas tiu kiu malkaŝas itineron ligitan al la malĝusta konekto.

rasdial 'Lab VPN' /disconnect
rasdial 'Lab VPN'
Find-NetRoute -RemoteIPAddress 10.77.5.20 | Select-Object -First 1

La rezulto kiun vi volas ne estas ke adaptilo konservu sian numeron unufoje. Ĝi estas ke la itinero aperu kun kiu ajn numero la konekto ricevas, ĉiufoje, kaj malaperu kiam la konekto fermiĝas. Rekonekti dufoje estas la plej malmultekosta maniero distingi tiujn rezultojn.

Sciu kion la itinero ne povas fari

Profila itinero provizas vojon kaj nenion alian. Ĝi ne malfermas malproksiman fajroŝirmilon, ne kreas returnan itineron ĉe la malproksima fino, nek solvas du retejojn kiuj uzas la saman adresaron; ĉiu el tiuj estas aparta agordo kun aparta posedanto. Konfirmi la vojon estas do la komenco de la akcepta testo, ne la tuto.

Tenu la prefikso-liston kun la profilo kaj notu sub kiu amplekso ĝi estis aldonita, por ke la sekva persono povu legi la celitan dezajnon anstataŭ dedukti ĝin el itinera tabelo. Itineroj kiuj ekzistas nur en la memoro de iu estas tiuj kiuj rekreiĝas malĝuste post la sekva rekonekto. Unulinia komento en la disfaldaj notoj kostas malpli ol tuta posttagmezo de retrovado.