OpenVPN Ubuntu-n abiatzean: NetworkManager ala systemd?

Gida gehienek aukera kosmetikotzat aurkezten dute: edo NetworkManager-ek tunela altxatzen uzten duzu, edo systemd instantzia bat gaitu eta kito. Bi bideek pantailarik gabeko makinan emaitza erabakitzen duen gauza bakarrean bereizten dira, eta ez du zerikusirik zein tresna berriagoa den. NetworkManager-ek sekretuak saio baten bidez desblokeatzen ditu; systemd instantzia batek ez du desblokesteko saiorik. Aukeratu sekretuen kudeaketa zure aurrean duzun makinarekin bat datorrena.

Beste guztia, ibilbideen instalaziotik berriro konektatzeko jokabidera, lehen erabaki horretatik dator.

Giltza-sorta da inork aipatzen ez duen aldea

NetworkManager-ek VPN profila duenean, pasahitza saioa hasteko giltza-sortan bizi daiteke, erabiltzailea saioa hasten denean desblokeatzen dena. Horrek ondo funtzionatzen du eramangarrian: pertsona han dago, giltza-sorta irekitzen da, tunela altxatzen da. Gainbegiratu gabe abiatzen den zerbitzari batean ez dago ezer desblokeatuko duen inor, beraz profila inoiz iristen ez den sekretu baten zain geratzen da. Konexioa konfiguratuta dirudi eta ez da inoiz aktibatzen.

systemd instantziak arazo hori saihesten du diskatik kredentzial-fitxategi bat irakurriz, eta horrek fitxategia zuk babesten duzun gauza bihurtzen du. chmod 400 eta root-en jabetza da gutxienekoa, eta fitxategiak zuk kontrolatzen ez dituzun segurtasun-kopietatik eta irudi-txantiloietatik kanpo egon beharko luke.

VPN-a konexio bati lotzea ez da abio-bermea

nm-connection-editor atalean, hautatu kablezko edo haririk gabeko konexioa VPN-a beharrean, ireki General fitxa, markatu VPN batera automatikoki konektatzeko aukera eta eman izena profiloari. Ondoren NetworkManager-ek VPN-a bigarren mailako konexio gisa aktibatzen du lehen mailakoa konektatuta egoerara iristen denean. Mendekotasuna da, ez suebakiko araua. Paketeak oraindik irten daitezke tunela altxatu aurreko segundoetan, eta desblokeatzen ez den gordetako sekretu batek makina sarean uzten du hura gabe.

Baldintza tunelik gabe ezer ez irtetea bada, esan hori eta eraiki kill switch bat, ezarpen honek ez baitu bat emango. Eseki eta jarraitu ere probatu, bigarren mailako konexioa berriro ebaluatzen baita itzultzean.

systemd instantziak bat datorren fitxategi-izena behar du

Jarri profila paketeak espero duen bezero-direktorioan, adibidez /etc/openvpn/client/office.conf, eta erreferentzia ezazu barrutik kredentzial-fitxategiari auth-user-pass office.cred erabiliz. Instantziaren izena luzapenik gabeko fitxategi-izena da, beraz openvpn-client@office fitxategiak office.conf irakurtzen du. Gaitu sudo systemctl enable --now openvpn-client@office erabiliz eta egiaztatu mapaketa systemctl cat openvpn-client@office erabiliz, blog bateko adibideari fidatu beharrean.

Profilaren barruko bideak unitatearen lan-direktorioarekiko ebazten dira, ez profilarekiko, beraz ca edo auth-user-pass lerro erlatiboak huts egin dezake abiatzean, eskuz probatzean funtzionatzen duen arren. Erabili bide absolutuak unitateak aurkitu behar duen guztiarentzat. Ondoren irakurri journalctl -u openvpn-client@office -b benetako abio baten ondoren; tunelik gabe aktibo dagoela jakinarazten duen unitateak normalean falta den fitxategi bat aipatzen du erregistro horretan.

Pakete zaharrek txantiloi-izen desberdina dakarte, beraz systemctl list-unit-files 'openvpn*'-k erabakitzen du zein dagoen ostalari honetan.

Berriro konektatzeko jokabidea erabaki bereizia da

ping-restart duen profil batek tunela berreraikitzen du erori ondoren, eta berrabiarazte-direktiba duen unitate batek antzeko zerbait egiten du zerbitzu mailan. Zuk aukeratutako politikak dira, ez heredatutako lehenetsiak. Konexioa eskaeran bakarrik altxatu behar bada, kendu berrabiarazte-jokabidea nahita eta idatzi zergatik. Unitatea sareak erabilgarri izan aurretik abiatzen bada, berriro saiatzeko politika behar du, abiatzean huts egindako saiakera bat ez baita berez errepikatzen.

Gelditzea ere berdina da hitzez hitz: sudo systemctl disable --now openvpn-client@office exekuzioan dagoen instantzia gelditzen du eta abio-esteka kentzen du. Desgaitzeak bakarrik tunela martxan uzten du hurrengo berrabiaraztea arte, eta horrek harritzen du desgaituz eta interfazea zutik geratzen dela ikusiz probatzen duen edonor.

Berrabiarazi, eta gero egiaztatu lau gauza ordenan

Zerbitzua berrabiarazteak zerbitzua probatzen du; makina berrabiarazteak abio-bidea probatzen du. Berrabiarazi ondoren, egiaztatu unitatea altxatu dela, gero urruneko azpisarearentzat ibilbidea badagoela, gero makina zein helbide aurkezten dion interneti, eta azkenik izenak tuneletik ebazten direla. Lau egiaztapen horiek ordena horretan huts egiten dute zerbait gaizki dagoenean, eta horrek lehen hutsegitea egiten du erabilgarri.

Ibilbiderik gabeko unitate aktiboak esan nahi du normalean profila konektatu zela baina zerbitzariak ez zuela ibilbiderik bultzatu, edo ibilbidea geroago desagertu zen interfaze batean instalatu zela. Izenen bilaketa funtzionalik gabeko ibilbide batek DNS konfiguraziora seinalatzen du, ez tunelera bertara.

Erabaki aurretik zer gertatu behar den tunela altxatu ezin denean. Konektagarritasun arruntera itzultzea politika bat da, eta idatzi egin beharko litzateke, lehenengo abiatu zen kudeatzaileari utzi beharrean.