Neniu itinero riparas VPN-basenon, kiu koincidas kun via LAN

La aplikaĵo asertas, ke la tunelo estas sana, tamen duono de la celoj, kiujn vi bezonas, neniam respondas. La reflekso estas aldoni itineron aŭ malaltigi metrikon, kaj ĝuste tiu reflekso estas la mito, kiun unue indas mortigi. Kiam la propra LAN de la kliento kaj la baseno de la tunelo postulas la saman prefikson, la itinera tabelo tenas du neakordigeblajn faktojn, kaj nek defaŭlta itinero nek metriko solvas ilin. La riparo estas decido pri adresado, kaj neniu redaktado de itineroj anstataŭas ĝin.

Kial plia itinero ne povas dividi unu prefikson

Itinero ne povas apartigi du postulojn pri unu prefikso, tial la saĝa movo estas ĉesi serĉi la ĝustan itineran linion. La stako ne metos identan prefikson antaŭ la konektita itinero, kaj pli specifa rikordo ja kaptas la adreson, sed faras la lokan gastiganton, kiu posedas ĝin, neatingebla. Tio, kio aspektas kiel itinera problemo, estas adresa kolizio, kaj ambaŭ riparoj ŝanĝas adresojn anstataŭ itinerojn. Provu la aserton sur via propra maŝino antaŭ ol akcepti ĝin.

ip route get 192.168.1.50
route -n get 192.168.1.50
Find-NetRoute -RemoteIPAddress 192.168.1.50

Demandu la sistemon pri unu adreso kaj notu, kiun interfacon ĝi nomas. Linux, macOS kaj Windows ĉiu respondas per nurlega serĉo, kiu raportas la elektitan interfacon kaj la sekvan salton sen sendi ion ajn. Kiam la respondo montras la fizikan adaptilon dum la tunelo estas supre, la kerno traktas la adreson kiel surlokan, ne kiel ion, kion la tunelo povus porti.

Metu la prefikson donitan de la provizanto apud tiu, kiun servas la hejma enkursigilo, kaj komparu ilin kiel signoĉenojn. Ekzakta kongruo estas la klara kazo, kaj pli larĝa provizanta baseno, kiu enhavas la hejman subreton, malsukcesas same, sed estas pli facile preteratenti. Du prefiksoj, kiuj nur aspektas similaj, ne estas kolizio, do skribu ambaŭ antaŭ ol ŝanĝi ion ajn.

Legu la basenon, kiun la kliento efektive ricevis

Legu, kion la kliento ricevis, ne la merkatan paĝon de la provizanto. Pligrandigu la detalecon de la protokolo de OpenVPN-kliento kaj la itineroj puŝitaj de la servilo aperos en ĝi, malkaŝante la tunelajn prefiksojn; aliloke la baseno aperas en la konektaj detaloj aŭ sur la adaptilo mem. Petu de la provizanto la plenan liston de privataj gamoj, kiujn ĝi uzas, ĉar unu /24 hodiaŭ povas esti du morgaŭ. Eviti la kutimajn RFC 1918-blokojn ne samas kiel eviti la atribuon, kiun vi efektive ricevis.

Baseno ankaŭ povas malgrandiĝi aŭ translokiĝi inter regionoj, do la listo bezonas daton kaj posedanton. Traktu ĉiun provizantan respondon pli malnovan ol via lasta planŝanĝo kiel konjekton, ne kiel fakton. Demandu denove antaŭ ol sin ligi al gamo, kaj konservu la respondon kun la retaj notoj, por ke la sekva persono heredas la pruvon.

Renumerado estas la riparo, kiun vi povas fari

Se la VPN-servilo ne estas via por ŝanĝi, movi la hejman LAN estas la sola disponebla riparo, kaj tio estas la kutima situacio ĉe komerca provizanto. Elektu gamon ekster la baseno de la provizanto kaj ekster la gamoj, kiujn vi eble bezonos poste, kaj kontrolu ĝin kontraŭ ĉiu alia retejo, kiun vi atingas per tunelo. Atendu mallongan interrompon kaj pli longan voston de forgesitaj aparatoj: unu, kiu ankoraŭ havas la malnovan adreson, aspektas funkcii ĝis ĝi bezonas la enirejon.

1. Unue inventaru: la propra adreso de la enkursigilo, la DHCP-gamo, rezervoj, pordaj plusendoj kaj ĉiu aparato, kies adreso estis tajpita permane.
2. Poste ŝanĝu la LAN-prefikson de la enkursigilo kaj la DHCP-gamon kune ene de prizorga fenestro, kaj renovigu la dratajn luojn antaŭ la sendrataj.
3. Sekve ĝustigu la statikajn adresojn: printiloj, reta konservado, ĉio kun malmola enireja adreso.
4. Fine rekonektu la VPN-klienton kaj konfirmu, ke la tunela adreso ne plu kolizias kun la LAN.

Trairu la adresojn laŭ tiu ordo anstataŭ ĉiujn samtempe, kaj konservu la malnovan gamon dokumentita dum iom da tempo, por ke kaduka aparato estu rekonebla anstataŭ mistera. Aparato, kiu neniam renovigas, anoncas sin per tio, ke ĝi ne atingas la enirejon, kio estas multe pli bona indico ol telefonvoko al subteno. Se la enkursigilo donas luojn pli longajn ol unu tago, mallongigu ilin por la daŭro de la fenestro.

Kion aliaso povas fari kaj kion ne

Kiam la servilo estas via, tradukado de adresoj sur la kliento povas malkaŝi la malproksiman prefikson ene de libera loka gamo, tiel ke la sama gastiganto respondas ĉe dua adreso. La komunuma OpenVPN faras tion per client-nat, kaj tiu direktivo estas specifa al tiu kliento, foresta en la komercaj kaj porteblaj klientoj, kun kiuj oni kutime komparas ĝin. La aranĝo bezonas itinerojn kongruajn kun la traduko, liberan gamon por la aliaso kaj servilon pretan respondi al la netradukita adreso de la kliento. Nenio el tio helpas, kiam la kliento apartenas al administrata provizanto, kiun vi ne povas agordi.

Post kiam la ŝanĝo validiĝos, atingi lokan kaj malproksiman gastiganton unue per adreso kaj poste per nomo, notante la itineron, kiun la sistemo elektas ĉiufoje. Nomo eble ankoraŭ solviĝas en la malnovan gamon, do adresoj kaj nomoj meritas sendependajn kontrolojn. Restartigu unu klienton kaj unu serviloflankan aparaton, se iu el ili restis ŝaltita dum la ŝanĝo, ĉar konservitaj najbaraj rikordoj vivas pli longe ol la redakto.

Skribu la prefiksojn, pri kiuj vi interkonsentis, tie, kie homoj efektive rigardas: la retaj notoj, la komenta kampo de la enkursigilo, la bonveniga paĝo. Iu elektos 192.168.1.0/24 denove, kaj la kolizio revenos kun li.