Proton VPN sur Pi sen ekrano: aplikaĵo aŭ WireGuard-dosiero?

Instali la Linux-an aplikaĵon sonas kiel unu instrukcio sur Pi sen ekrano, kaj ĝi kaŝas elekton inter du disfaldaj vojoj kun malsamaj subtenaj limoj. Unu estas la oficiala aplikaĵo de la provizanto, kiu portas siajn proprajn postulojn pri distribuo kaj arkitekturo. La alia estas permana agorda dosiero uzata de norma kliento, kiun la operaciumo jam pakaĵas. Ambaŭ atingas la saman servon, kaj ili ne estas interŝanĝeblaj laŭ prizorgado.

La demando pri arkitekturo venas unue, ĉar 64-bita tabulo povas ruli 32-bitan uzantospacon kaj la aplikaĵo liveras nur unu el ili.

Du subtenaj limoj, ne du instaliloj

Legu la nunan instalpaĝon de la provizanto por la aplikaĵo, kiun vi intencas uzi, kaj komparu ĝin kun la tabulo: eldono de la distribuo, paka arkitekturo kaj ajna postulo pri labortablo aŭ seanco. Tio, ke Pi subtenas 64-bitan funkciadon, ne diras, kiu uzantospaco nun estas instalita, kaj ĝuste tiun valoron kontrolas la pakadministrilo. dpkg --print-architecture kaj uname -m respondas tion per po unu linio. Se la eldono aŭ la arkitekturo falas ekster la dokumentitan aron, la aplikaĵo tie ne estas subtenata, eĉ kiam ĝi instaliĝas.

Subteno ankaŭ varias laŭ la paka metodo. Limigo dokumentita por unu paka formato ne aŭtomate validas por konstruo el deponejo, kaj Debian-derivita distribuo ne aŭtomate estas subtenata medio. Komunumaj pakaĵoj kaj malnovaj instalreceptoj alportas sian propran prizorgan modelon, kiun vi povas konscie akcepti sed ne devus akcidente adopti.

Kion la aplikaĵo donas kaj profilo ne

La oficiala aplikaĵo estas pli ol konekto: ĝi kutime portas la haltŝaltilon de la provizanto, DNS-traktadon kaj funkciajn ŝaltilojn, kaj la provizanto subtenas tiujn kondutojn kiel aron. Permana profilo transdonita al norma kliento heredas nenion el tio. La permana kliento posedas la vivociklon de la konekto kaj la lokan fiaskpolitikon, kio estas en ordo kiam vi mem agordas ilin kaj surpriza kiam vi supozas, ke ili venis kun ĝi. Ambaŭ opcioj atingas la samajn servilojn; nur unu inkluzivas la ĉirkaŭan logikon.

Se funkcio gravas, ekzemple blokado de trafiko ekster la tunelo, ĝi devas ekzisti en via agordo anstataŭ en la aplikaĵo de la provizanto.

WireGuard permane: la paŝoj, kiuj gravas

La provizanto dokumentas la kreadon de WireGuard-agordo por normkonforma kliento kaj rekomendas tiun vojon por permanaj agordoj, konservante OpenVPN por pli malnovaj aparatoj. Generu la profilon en la konta panelo, alportu ĝin al la Pi kaj metu ĝin tie, kie nur la posedanto povas legi ĝin. Neniam algluu la dosieron en subtenan fadenon, ĉar amika dosiernomo ne igas la enkonstruitan privatan ŝlosilon publikigebla. Poste testu la tunelon per unu peto antaŭ ol konekti ion alian al ĝi.

Forigo de serviloj estas operacia detalo, kiun homoj forgesas. Permane elektita finpunkto povas esti retirita, kaj la provizanto notas, ke anstataŭa agordo eble necesos. Notu, kiun finpunkton la profilo uzas, por ke posta fiasko estu diagnozebla.

Decidu, ĉu la Pi estas ankaŭ enirejo

Tunelo uzata de la propraj aplikaĵoj de Pi ne aŭtomate fariĝas enirejo por aparatoj malantaŭ ĝi. Plusendado, revena enkursigado, posedo de solvilo kaj ajna politiko malhelpanta trafikon eskapi ekster la tunelon estas aparta dezajno kun propraj fiaskmanieroj. Se aliaj aparatoj estas en la amplekso, taksu ilin kiel propran kazon anstataŭ supozi, ke la konekto de Pi kovras ilin. Tiu apartigo tenas malgrandan disfaldon prizorgebla.

Poste akceptu la vivociklon: freŝa peto de la Pi, nomrezolucio tra la celata solvilo kaj la starta aŭ rekonekta konduto, kiun vi planis. Kontrolu ĉiun el ili anstataŭ supozi, ke la aplikaĵo aŭ la profilo provizas ĝin.

La mito inda forlasi estas, ke Linux-instalilo kaj WireGuard-dosiero reprezentas la saman decidon. Ili estas du operaciaj modeloj kun du malsamaj posedantoj.