Du VPN-klientoj samtempe: kiu gajnas la defaŭltan itineron?
Du VPN-klientoj postulas la defaŭltan itineron kaj nur unu gajnas. Legu la metrikon, la /1-paron kaj la dividon de la solvilo antaŭ ol elekti tunelan ordon.
Ruli du VPN-klientojn samtempe estas diskuto pri enkursigado, ne privateca agordo. Kiun tunelon posedas la pli specifa itinero, tiu ricevas la trafikon, kaj la alia restas konektita sed senokupa. La korporacia pordego tiam vidas konekton alvenantan el la persona eliro, dum la korporacia kliento en via maŝino ankoraŭ vidas ĉiun adaptilon. Decidi, kiu el tiuj du faktoj gravas, estas la tuta ekzerco.
La itinera tabelo elektas unu gajnanton
Kaptu la tabelon antaŭ kaj post la starto de la korporacia kliento kaj legu la interfacan kolumnon anstataŭ nur la celon. Ordinara defaŭlta itinero el la ekstera tunelo estas facile anstataŭigebla, ĉar /1-paro estas pli specifa ol /0. La laŭvorta paro 0.0.0.0/1 kaj 128.0.0.0/1 kovras la tutan IPv4-spacon en du duonoj kaj venkas ĉiun unuopan defaŭlton. Post ĝia instalado, la ekstera tunelo ankoraŭ montriĝas konektita kaj portas nenion.
ip route show default
ip route show | grep -E '^(0.0.0.0/1|128.0.0.0/1)'Politika enkursigado povas tute superregi la ĉefan tabelon, do legu la regulojn same kiel la itinerojn. Regulo, kiu sendas markitan trafikon al alia tabelo, gajnas antaŭ ol la ĉefa tabelo estas konsultita. Tiel unu aplikaĵo povas resti sur la fizika ligo dum ĉio alia uzas la tunelon.
ip rule showVindozo decidas per metrikoj
En Vindozo la gajnanto estas la itinero kun la plej malalta metriko por la celo, kaj du klientoj povas ambaŭ instali defaŭltan itineron kun diversaj metrikoj. Legu la tabelon kaj la interfacan agordon kune, ĉar la adaptilo kun la pli malalta metriko ne ĉiam estas tiu, kiun vi atendas. Kliento, kiu ankaŭ agordas interfacan metrikon, povas movi la defaŭlton sen aldoni eĉ unu itineron. La malgajninta adaptilo restas aktiva kaj simple ricevas nenion.
route print -4
Get-NetIPConfiguration | Select-Object InterfaceAlias, IPv4DefaultGatewayKomparu la du eligojn kaj nomu la interfacon, kiu posedas 0.0.0.0/0. Se ambaŭ klientoj postulas ĝin, la metriko decidas, kaj tial testo de konekta ordo povas ŝajni malkonsekvenca inter maŝinoj. Se neniu eligo montras defaŭltan pordegon, la kliento ne funkcias en plena tunelo kaj la ĉena argumento estas senobjekta.
Du observantoj, du diversaj vidpunktoj
La fora pordego vidas unu konekton alvenantan el la ekstera eliro plus ĉion, kion la kliento plusendas en sian tunelon. La loka kliento vidas adaptilojn, itinerojn kaj la ekziston de alia tunelo, ĉar ĝi ruliĝas kun privilegioj por krei ilin. Disigi tiujn vidpunktojn estas la celo; aserti, ke la kliento ne povas rimarki, ne estas.
Supozu, ke la kliento povas listigi kion ajn ĝi volas, kaj planu anstataŭe por la vidpunkto de la pordego. Dezajno dependanta de tio, ke la kliento restu blinda, estas unu ĝisdatigo for de rompiĝo.
DNS kaj IPv6 estas la lokoj, kie la ĉeno likas
DNS sekvas tiun solvilan agordon, kiu gajnas, kaj tio ne nepre estas la vojo, kiun la pakaĵoj prenas. Korporacia solvilo atingata tra la korporacia tunelo kongruas kun la dezajno; loka solvilo atingata ekster ĝi ne, kaj ĝi malkaŝas nomojn, kiujn la tunelo celis kaŝi. IPv6 estas la dua liko: duobla stako daŭre uzas IPv6 al celoj, kiujn la tunelo portas nur super IPv4. Kontrolu la familiojn aparte, ĉar tunelo nur-IPv4 diras nenion pri IPv6-itineroj aŭ solviloj.
ip -6 route show default
resolvectl status | grep -A2 'DNS Servers'Riparu la solvilon kaj la IPv6-itineron intence anstataŭ staki duan tunelon supre. Duobla enkapsuligo ankaŭ kostas MTU, do pli malgranda interna MTU estas la unua afero provenda, kiam paĝoj haltas post la starigo de la ĉeno. Solvilo, kiu respondas rapide, ne estas pruvo, ke ĝi estas la ĝusta solvilo.