Du VPN-klientoj en unu komputilo: kio kolizias kaj kio funkcias

Via dua kliento konektiĝas, la rimedoj de la unua ĉesas solviĝi, kaj la bileto diras, ke la labora VPN rompis la personan. Nenio rompiĝis en la senco de difekto: ambaŭ klientoj faris tion, por kio ili estis konstruitaj, kaj la maŝino havas nur unu itinertabelon. La kolizio temas pri kvar rimedoj, kiujn ĉiu kliento supozas posedi. Prilaboru ilin laŭorde, kaj la riparo kutime fariĝas dezajna elekto anstataŭ riparo.

Paŝo 1: trovu, kiu kliento posedas la eliron

Legu la nunan elirdedukton antaŭ ol ŝanĝi ion ajn. La itinera serĉo por publika adreso diras al vi, kiun interfacon kaj sekvan salton pakaĵo uzus ĝuste nun, kaj tio estas la respondo al kiu venkis. Komparu ĝin kun la interfacaj nomoj, kiujn la klientoj kreis, kiuj kutime portas la produkton aŭ protokolan nomon. Se la serĉo montras al la tunelo, kiun vi ne atendis, vi jam trovis la kolizion.

ip route get 1.1.1.1
ip route show default
route print

Iuj klientoj tute ne anstataŭigas la defaŭltan itineron; ili aldonas du duonojn, unu por la malsupra duono de la adresspaco kaj unu por la supra duono, kiuj kune kovras ĉion. Tio lasas la originalan defaŭltan itineron videbla kaj igas manan riparon aspekti ĝusta dum trafiko ankoraŭ eliras tra la tunelo. Legu la metrikon kaj la longon de la prefikso, ne nur la ĉeeston de defaŭlta enskribo.

Haltu, se ambaŭ klientoj postulas la saman prefikson kun la sama metriko. La kerno elektos unu, kaj la alia aperos konektita dum ĝi portas nenion.

Paŝo 2: kontrolu la solvilon kaj la koincidantajn prefiksojn

DNS estas la dua kolizio, kaj ĝi produktas distingan simptomon: nomoj malsukcesas dum adresoj funkcias. Ĉiu kliento trudas sian propran solvilon, kaj la lasta skribanto venkas por la sekvaj demandoj. Demandu la solvilan servon, kion ĝi uzas por ĉiu ligo, anstataŭ legi la agordan paĝon de la kliento.

resolvectl status
Get-DnsClientServerAddress
dig +short intranet.corp.example

Poste komparu la privatajn prefiksojn, kiujn la du retoj uzas. Se ambaŭ flankoj asignas el la sama gamo, neniu klientflanka aranĝo riparos ĝin, ĉar la maŝino ne povas diri, kiu celloko 10.0.0.0/8 apartenas al kiu tunelo. Unu flanko devas esti renumerita aŭ tradukita, kaj tio estas konversacio kun la retposedantoj, ne agorda ŝanĝo. Koincido estas la sola kolizio, kie la honesta respondo estas, ke la dezajno devas ŝanĝiĝi.

Haltu ĉi tie, se la prefiksoj koincidas. Ĉio posta en ĉi tiu kontrolo supozas, ke ili ne koincidas.

Paŝo 3: elektu apartigan ŝablonon, kiu teniĝos

La fidindaj ŝablonoj evitas funkciigi du klientojn kontraŭ la sama itinertabelo. Unu kliento kun split-tunela politiko, kiu atingas ambaŭ privatajn retojn estas la plej simpla, kondiĉe ke la celoj ne koincidas kaj la posedanto de la politiko konsentas. Virtuala maŝino aŭ reta nomspaco estas la sekva paŝo, ĉar ĉiu ricevas sian propran tabelon kaj sian propran solvilon.

sudo ip netns add vpn2
sudo ip netns exec vpn2 ip link show
sudo ip netns exec vpn2 curl -sI https://intranet.corp.example/

Nomspaco donas la saman apartigon kiel virtuala maŝino sen la dua operaciumo, sed ĝi havas krudajn randojn: la tunela aparato devas esti movita en ĝin, kaj la aplikaĵo devas esti startigita interne. Aparta fizika aparato ofte estas la plej malmulte surpriza opcio por persona VPN apud administrata labora kliento. Stakigi unu tunelon en alia ne estas apartiga ŝablono; la interna finpunkto devas resti atingebla tra la ekstera tunelo, kaj la aranĝo aldone aldonas problemojn pri MTU kaj latenteco.

Elektu unu ŝablonon kaj notu kial. Miksi nomspacon por unu aplikaĵo kun split-tunelo por la resto rekreas la originan kolizion en pli malfacile sencimigebla formo.

Paŝo 4: kontrolu ambaŭ retojn el la sama seanco

Testu unu rimedon en ĉiu privata reto el la medio, kie la aplikaĵo vere funkcias, ne el via ŝelo se la aplikaĵo funkcias ene de nomspaco. Kontrolu la eliran interfacon, la solvitan adreson kaj la respondan kodon kune, ĉar sukceso en unu el la tri povas kaŝi malsukceson en la aliaj. Ripetu post restartigo, ĉar la ordo, en kiu klientoj startas, decidas kiu venkas. Ĝuste tiun ordon homoj forgesas noti.

curl -sI https://intranet.corp.example/
curl -sI https://files.personal.example/
ip route get 10.20.30.40

Notu la klientajn versiojn, la interfacojn, la staton de la solvilo kaj la prefiksojn por ĉiu reto. Kiam kliento ĝisdatiĝas kaj ŝanĝas sian itineran konduton, tiu noto estas la diferenco inter kvin-minuta riparo kaj rekonstruo. La sekva persono ne dividos vian memoron pri tio, kiu tunelo supreniĝis unue.

La kontrolo estas kompleta, kiam vi povas nomi la interfacon, kiu posedas la defaŭltan itineron, la solvilon, kiun uzas ĉiu nomo, la ŝablonon, kiu apartigas la duan tunelon, kaj la rezulton de unu peto por reto post restartigo. Io ajn malpli estas agordo, kiu hazarde funkcias hodiaŭ.