Portebla VPN-kliento sen administraj rajtoj: kio ankoraŭ rompiĝas

Portebla priskribas la instalilon, ne la kernon. Kliento povas alveni kiel unu plenumebla dosiero sur USB-memoro kaj tamen bezoni tunelan aparaton, entiron en la itinera tabelo kaj skribon al la solvilo antaŭ ol la unua paketo moviĝos. Kiun el tiuj tri la cela maŝino lasos vin tuŝi, decidas ĉu tiu konstruo entute funkcias tie. La subaj provoj respondas la demandon en la ordo, en kiu la kliento renkontos ilin.

Portebla kovras tri diversajn promesojn, kaj nur unu estas senpaga

Neniu instalilo signifas, ke la vendanto ne registris servon, ne liveris malinstalilon kaj ne aldonis menuero. Neniu administranto signifas, ke ordinara konto povas lanĉi la klienton kaj fini konekton. Neniu ŝanĝo al la gastiganto signifas, ke la maŝino aspektas identa post kiam vi eliras. Elŝutaj paĝoj, kiuj diras portebla, kutime promesas nur la unuan el tiuj, kaj la aliaj du estas kie la deplojoj malsukcesas. Konstruo povas esti portebla ankaŭ laŭ la mallarĝa senco: ĝi ruliĝas de nurlega medio sen iuj ajn punktdosieraj skriboj, kio ankoraŭ diras nenion pri la reta stako.

La multekostaj promesoj estas la dua kaj la tria. Unu plenumebla dosiero, kiu bezonas adaptilon, itineron aŭ skribon al la solvilo, petas de la operaciumo aŭtoritaton, kiun la etikedo portebla neniam kovris.

Trovu la privilegian helpanton, kiun la kliento vokos

Preskaŭ neniu VPN-kliento mem movas paketojn. En Windows la datenvojo iras tra WFP-filtriloj kaj la Base Filtering Engine, en macOS tra NetworkExtension-provizanto, kiun la uzanto aprobas en Sistemaj agordoj, kaj en Linux tra tun-aparato plus la enkursiga stako. La binara dosiero, kiun vi kopiis, estas stirsurfaco por tiuj komponantoj, ne anstataŭaĵo por ili. Demandu, kiun komponanton la kliento atendas, poste konfirmu, ke ĝi estas instalita, funkcias kaj uzeblas de via konto.

Linux estas la plej facila loko por pruvi la aferon, ĉar la kontrolo estas unu sistema voko. Malfermi /dev/net/tun kaj peti aparaton de la kerno postulas CAP_NET_ADMIN, kaj la kerna dokumentaro pri TUN/TAP indikas kaj la posedan regulon kaj la kapablon. Rulu la provon kiel la konto, kiu lanĉos la klienton, ne kiel root.

ls -l /dev/net/tun
ip tuntap add dev vpntest mode tun
ip link delete vpntest

Permeseraro en la meza linio estas la respondo, kiun vi serĉis: ĉi tiu konto ne povas krei tunelan interfacon, do ajna uzantspaca kliento, kiu bezonas unu, malsukcesas ĉe konekto anstataŭ ĉe elŝuto. La lasta linio forigas la testan aparaton kaj presas nenion, kiam ĝi funkcias. Se ambaŭ linioj sukcesas, la gastiganto ŝanĝis nenion daŭran.

Testu ŝanĝojn de itinero kaj solvilo antaŭ la unua konekto

Disigita tunelado igas konekton enkursiga decido, dum plena tunelo igas ĝin anstataŭigo de la implicita itinero. Ambaŭ estas skriboj al la reta stako de la gastiganto, kaj ambaŭ malsukcesas por konto sen privilegioj eĉ kiam la kliento mem startas pure. La solvilo estas la tria skribo, kaj en gastigantoj kun systemd ĝi kutime estas tiu, kiu rompiĝas laste. Tiu ordo gravas, kiam vi decidas, kie elspezi altigitan instaladon.

Itinera provo bezonas celon, pri kiu vi vere zorgas, do anstataŭigu la lokokupilon sube per subreto el via propra profilo. La aparatan nomon necesas ekzisti, por ke la itinero povu alkroĉiĝi al io.

ip route add 10.20.0.0/16 dev vpntest
ip route del 10.20.0.0/16
resolvectl query intranet.example.internal

Se la unua linio redonas RTNETLINK answers: Operation not permitted, tio signifas, ke la konto ne povas instali la privatan itineron, kiun la profilo postulas. La dua linio pruvas la saman rajton inverse, kio gravas, ĉar kliento, kiu povas aldoni itinerojn sed ne forigi ilin, lasas rompitan tabelon malantaŭe. La demando al la solvilo poste montras, ĉu privataj nomoj solviĝas tra la tunelo aŭ likas al kiu ajn solvilo, kiun la gastiganto jam fidas.

Rulu ĉiujn tri dum la testaparato ankoraŭ ekzistas, poste forigu ĝin. Itinero montranta al aparato, kiu malaperis, estas la plej ofta kialo, ke tekkomputilo perdas konektecon post malsukcesa konekto.

Decidu, kio devas postvivi la seancon

Forigi la dosierujon ne estas puriga plano. Adaptiloj, itineroj, solvilaj agordoj, fidataj atestiloj kaj konservitaj legitimiloj povas ĉiu postvivi la procezon, kaj dumstarta servo povas restarigi kelkajn el ili sen demandi. Skribu, kion la kliento rajtas lasi malantaŭe antaŭ ol ruli ĝin, ne post la unua malsukcesa malkonekto.

La praktika regulo estas fari momentfoton de la tri surfacoj, kiujn vi baldaŭ ŝanĝos, kaj kompari ilin poste. Registru la interfacojn, la ĉefan enkursigan tabelon kaj la staton de la solvilo antaŭ la unua konekto, poste ripetu la samajn tri legadojn, kiam la kliento eliris.

ip -brief addr show
ip route show table main
resolvectl status

Ĉio, kio ĉeestas en la dua kaptaĵo kaj mankas en la unua, bezonas posedanton. Aŭ la kliento forigas ĝin ĉe eliro, aŭ vi forigas ĝin per la samaj komandoj, kiuj kreis ĝin, kaj tiu forigo apartenas al la deplojaj notoj, ne al ies memoro pri tio, kio okazis. En Windows la ekvivalentaj legadoj estas Get-NetAdapter, Get-NetRoute kaj Get-DnsClientServerAddress, kiuj bezonas neniun altigon sed montras la samajn restaĵojn.