Klienta hoko aŭ servila hoko? Kie ruliĝas OpenVPN-skripto

La tasko estas klara: kiam tekkomputilo konektiĝas, io sur la tekkomputilo devus ŝanĝiĝi. La agordo redaktata apartenas al la servilo, kaj ĝuste tie la supozo rompiĝas. Vojo en servila dosiero nomas dosieron sur tiu servilo, kaj neniu kvanto da puŝado ŝanĝas, kies procezo ĝin plenumas. Elekti inter la du hokoj estas plejparte demando pri decidi, kiu maŝino posedas la laboron, kaj akcepti la limojn, kiuj sekvas.

Du maŝinoj, du demandoj respondendaj unue

Demandu, kie la statoŝanĝo devas okazi, poste demandu, kiu evento respondecas al ĝi. Se la ŝanĝo estas peruzanta rajtigo aŭ perklienta agorda decido, ĝi apartenas tien, kie la uzanta dosierujo estas konata: la servilo. Se la ŝanĝo estas vojo, agordo de solvilo aŭ loka helpilo sur finpunkto, ĝi apartenas al la finpunkto, kaj nur la finpunkto povas fari ĝin.

Respondi tiujn du demandojn en la mala ordo estas kiel homoj finiĝas provante puŝi batch-dosieron al Windows-tekkomputilo. La servilo scias, kiu konektiĝis; la tekkomputilo scias, kiel aspektas ĝia propra reta stako. Neniu havas la informojn de la alia, kaj la provo kutime malsukcesas silente anstataŭ per klara eraro.

Trian demandon indas starigi antaŭ ambaŭ: ĉu la platformo eĉ proponas la hokon, kiun vi volas? Aparato, kiu mem generas sian agordon, eble ne proponas la samajn eventnomojn, kaj labortabla kliento, kiu importas .ovpn-dosieron, ne nepre estas la sama kliento, por kiu la dosiero estis verkita. Konfirmi la platformon unue ŝparas al vi desegnadon ĉirkaŭ hoko, kiu tie ne ekzistas. Ĝi ankaŭ diras al vi, kiu dokumentaro efektive validas por la maŝino antaŭ vi.

La servila opcio: evento por ĉiu konekto

client-connect-skripto ruliĝas en la proceza kunteksto de la servilo, kiam aŭtentigita kliento konektiĝas, kaj ĝi ricevas dokumentitajn konektopartikularojn kiel la common name kaj la asignita adreso. Ĝi estas la ĝusta loko por skribi perklientan agordan fragmenton, trudi politikan decidon aŭ registri staton, kiun la servilo posedas.

La distingo, kiun homoj maltrafas, estas la diferenco inter tiu hoko kaj servila up-hoko. La up-hoko ekfunkcias, kiam la servilo malfermas sian tunelan aparaton, kio sur servilo kun pluraj klientoj okazas unufoje ĉe demona starto. Ĝi ne estas evento po ensaluto, kaj kodo metita tie ruliĝas, kiam la servo startas, anstataŭ kiam uzantoj konektiĝas.

Sur aparato kun reta interfaco uzu la subtenatan etendan mekanismon anstataŭ redakti generitajn demonajn dosierojn. Generitaj dosieroj estas reskribataj ĉe la sekva konservo, kaj la reskribo silente forigas vian ŝanĝon en la plej malbona ebla momento. Konservu kopion de la etenda teksto ekster la aparato, por ke firmvara ĝisdatigo ne perdu ankaŭ la intencon.

La klienta opcio: laboro, kiu devas ruliĝi loke

Komunuma kliento povas ruli lokan skripton, kiam la tunela aparato ekfunkcias, kaj denove, kiam itineroj instaliĝas. Tiuj estas du malsamaj momentoj, kaj elekti la malĝustan kreas la klasikan konkurson, en kiu helpilo startas antaŭ ol ekzistas la itinero, de kiu ĝi dependas.

La helpilo devas ekzisti sur tiu kliento, esti legebla kaj plenumebla de la konto, kiu rulas la klienton, kaj esti permesita de eksplicita script-security-agordo. Skripto, kiu funkcias, kiam vi lanĉas la klienton kiel administranto, diras al vi nenion pri servo antaŭ ensaluto aŭ pri la sesio de alia uzanto.

Nomado ankaŭ gravas. La up-hoko respondas al kreado de aparato kaj route-up al instalado de itineroj, sed tasko, kiu bezonas atingeblan privatan reton, devus kontroli atingeblon anstataŭ supozi, ke kreado de aparato signifas, ke ĉiu itinero, solvila enskribo kaj aplikaĵo estas pretaj.

Kial puŝado de plenumebla kodo ne estas sur la menuo

Puŝitaj opcioj estas intence limigitaj, kaj opcioj, kiuj plenumas skriptojn, estas inter la kategorioj, kiujn la servilo ne rajtas transdoni. Tiu limo ekzistas ĉar la alternativo permesus al kompromitita aŭ mise agordita servilo ruli arbitrajn komandojn sur ĉiu kliento, kiu iam konektiĝas.

Ŝalti skriptan plenumadon loke ne ŝanĝas tion. Via script-security-agordo permesas lokajn skriptojn, kiujn vi elektis; ĝi ne rajtigas la servilon provizi novajn.

Se la celo estas simple instali VPN-itinerojn, uzu la subtenatan itinero-agordon anstataŭ elpensi skemon de fora plenumado. Se la celo vere postulas lokan kodon, disdonu ĝin per la finpunkta administrado de la organizo kaj revizuu ĝin kiel ajnan alian programaron, kiu ruliĝas kun la privilegioj de la uzanto.

Kion kontroli antaŭ ol fidi iun el la du hokoj

Notu kvar aferojn por ĉiu hoko: la maŝinon, la eventan nomon, la konton, sub kiu ĝi ruliĝas, kaj la statoŝanĝon, kiun ĝi devas produkti. Poste testu la konekton, rekonekton kaj la purigan vojon, ĉar hoko, kiu likas staton ĉe rekonekto, estas pli malbona ol tiu, kiu neniam ruliĝis.

Testu sub la konto, kiu efektive plenumos ĝin, en la momento, kiam ĝi efektive plenumiĝos. La manlibro openvpn(8) dokumentas ambaŭ hokajn familiojn kaj la puŝajn limojn; la platformo, sur kiu vi deplojas, dokumentas, ĉu ĝi entute elmetas ilin. Skripto, kiu sukcesas en interaga administranta terminalo, estas hipotezo, ne kontrolo.