Labora VPN sur Raspberry Pi: unue demandu ĉi tiujn demandojn
Portala URL kaj la vorto Linux ne estas klienta kontrakto. Atingu la respondojn pri protokolo, arkitekturo, aŭtentigo kaj politiko antaŭ ol instali ion ajn.
Kvar respondoj de la dunganto decidas, ĉu Pi povas aliĝi al la labora VPN: kiun enirejan protokolon ĝi parolas, kiujn operaciumojn kaj arkitekturojn ĝi subtenas, kiel aŭtentigo devas okazi, kaj ĉu kliento alia ol la oficiala estas permesata. Portala URL kaj la vorto Linux solvas neniun el ili. Demandu antaŭ ol elŝuti ion ajn, ĉar la respondoj ŝanĝas, kiun pakaĵon vi instalos kaj ĉu senkapula agordo estas entute farebla.
Skribu la kvar respondojn. La resto de ĉi tio estas, kion ĉiu el ili ŝanĝas.
La enireja protokolo decidas la klienton
La enirejo parolas unu aŭ plurajn protokolojn, kaj la kliento devas efektivigi tiun, kiun via organizo efektive uzas. OpenConnect estas sendependa efektivigo, kiu komenciĝis per kongruo kun Cisco AnyConnect kaj nun kovras plurajn aliajn entreprenajn enirejojn; ĝi ne estas la marka kliento de la vendanto, kaj protokola kongruo ne garantias subtenon por ĉiu enireja funkcio, sintena kontrolo aŭ aparata politiko. Konfirmu la protokolon kun la reta teamo anstataŭ dedukti ĝin el la URL de la portalo. Poste konfirmu, ke la dunganto akceptas ĉi tiun klienton por ĉi tiu deplojo.
Pruvoj de kongruo devas veni el la dokumentaro de la dunganto aŭ de kolego, kiu faris ĝin sur la sama modelo, ne el ekzisto de pakaĵo en deponejo.
Arkitekturo ne estas detalo
Notu la OS-version kaj uzantspacan arkitekturon de la Pi, la klientan version, kiun vi intencas uzi, kaj de kie venas tiu pakaĵo. x86-instalilo ne taŭgas por alia arkitekturo nur ĉar ĝia dosiernomo ŝanĝiĝis, kaj vendanta kliento, kiu liveras nur x86-konstruojn, tute ne povas funkcii sur la Pi. Tiu unu fakto povas solvi la tutan demandon antaŭ ol aŭtentigo eĉ diskutiĝos. Kontrolu la prizorgon de la pakaĵa fonto anstataŭ instali hazardan duumon el forumfadeno.
64-bita uzantspaco sur 64-bita kerno estas la simpla kazo; 32-bita uzantspaco sur 64-bita tabulo estas kie homoj instalas la malĝustan pakaĵon. dpkg --print-architecture kaj uname -m respondas ambaŭ duonojn per unu linio ĉiu.
Aŭtentigo decidas la laborfluon
Pasvortoj, MFA kaj retumila ensaluto ĉiu trudas sian propran laborfluon. Atestilo sur aparata ĵetono povas postuli pelilon, kiun la Pi ne havas, dum SSO-fluo povas malfermi retumilan fenestron, kiun senkapula seanco ne povas montri. Iuj enirejoj ofertas aparatkodon aŭ permanan kopiadon ĝuste por tiu kazo, kaj iuj ne. Demandu, kiun metodon la organizo subtenas por senkapula Linux-gastiganto, poste testu ĝin antaŭ ol dependi de ĝi.
Frontend-integriĝo estas aparta elekto de aŭtentigo. NetworkManager-kromaĵo povas aranĝi konekton kaj konservi ĝiajn sekretojn, sed ĝi ne povas igi nesubtenatan aŭtentigan metodon kongrua. Tenu tiujn du demandojn aparte.
Konservu la limon de la dunganto
Se la organizo postulas sian oficialan klienton, administritan aparaton aŭ subtenatan distribuaĵon, sekvu tiun postulon aŭ petu aprobitan alternativon. Malkŝalti atestilkontrolojn, imiti sintenajn rezultojn aŭ malŝalti finpunkajn kontrolojn por ke alia kliento ŝajnu akceptita transformas kongruan problemon en politikan malobservon. Tenu pasvortojn, seanajn kuketojn kaj privatajn ŝlosilojn ekster la ŝela historio kaj babilaj transskriboj. Funkcianta defio-respondo ne estas permeso publikigi la seanajn materialojn.
Post aprobita registriĝo, konfirmu privatan DNS, la celitajn rimedojn, rifuzitan rimedon kaj rekonekton, ĉion el la Pi mem. Ensalutinta tunelo ankoraŭ povas misvojigi aŭ manki rajtigon.
La rezulto estas subtenebla interkonsento kun nomita posedanto: kiu kliento, kiu versio, kiu registriĝa vojo. Tio superas instali la vendanto-proksiman klienton kaj esperi, ke la ceteraj postuloj montriĝos laŭvolaj.