OpenVPN ĉe lanĉo en Ubuntu: NetworkManager aŭ systemd?

Plej multaj gvidiloj prezentas la elekton kiel kosmetikan: aŭ lasu NetworkManager levi la tunelon, aŭ ebligu systemd-instancon kaj finu. La du vojoj malsamas en unu afero, kiu decidas la rezulton sur maŝino sen ekrano, kaj ĝi havas nenion komunan kun tio, kiu ilo estas pli nova. NetworkManager malŝlosas sekretojn per sesio; systemd-instanco havas neniun sesion por malŝlosi. Elektu tiun, kies traktado de sekretoj kongruas kun la maŝino antaŭ vi.

Ĉio alia, de instalo de itineroj ĝis rekonekta konduto, sekvas el tiu unua decido.

La ŝlosilringo estas la diferenco, kiun neniu mencias

Kiam NetworkManager posedas VPN-profilo, la pasvorto povas loĝi en la ensaluta ŝlosilringo, kiu malŝlosiĝas kiam uzanto ensalutas. Tio bone funkcias sur tekkomputilo: la persono ĉeestas, la ŝlosilringo malfermiĝas, la tunelo leviĝas. Sur servilo, kiu lanĉiĝas sen prizorgo, mankas iu ajn por malŝlosi ion ajn, do la profilo atendas sekreton, kiu neniam alvenas. La konekto aspektas agordita kaj neniam aktiviĝas.

La systemd-instanco evitas tiun problemon legante akreditilan dosieron el la disko, kio faras la dosieron tio, kion vi protektas. chmod 400 plus posedo fare de root estas la minimumo, kaj la dosiero devus resti ekster savkopioj kaj bildŝablonoj, kiujn vi ne regas.

Ligi la VPN-on al konekto ne garantias lanĉon

En nm-connection-editor, elektu la kablan aŭ sendratan konekton anstataŭ la VPN-on, malfermu la langeton General, marku la opcion konekti aŭtomate al VPN kaj nomu la profilon. NetworkManager tiam aktivigas la VPN-on kiel sekundaran konekton, kiam la primara atingas konektitan staton. Tio estas dependeco, ne fajromura regulo. Pakaĵoj ankoraŭ povas eliri dum la sekundoj antaŭ ol la tunelo leviĝas, kaj konservita sekreto, kiu malsukcesas malŝlosiĝi, lasas la maŝinon interrete sen ĝi.

Se la postulo estas, ke nenio eliru sen la tunelo, diru tion kaj konstruu mortigilon, ĉar ĉi tiu agordo ne provizos unu. Testu ankaŭ paŭzon kaj rekomencon, ĉar la sekundara konekto ree taksiĝas survoje reen.

La systemd-instanco bezonas kongruan dosiernomon

Metu la profilon en la klientan dosierujon, kiun la pako atendas, ekzemple /etc/openvpn/client/office.conf, kaj referencu de interne al la akreditila dosiero per auth-user-pass office.cred. La instanca nomo estas la dosiernomo sen la sufikso, do openvpn-client@office legas office.conf. Ebligu ĝin per sudo systemctl enable --now openvpn-client@office kaj konfirmu la mapadon per systemctl cat openvpn-client@office anstataŭ fidi ekzemplon el blogo.

Vojoj ene de la profilo solviĝas rilate al la labordosierujo de la unuo, ne al la profilo mem, do relativa linio ca aŭ auth-user-pass povas malsukcesi ĉe lanĉo, dum ĝi funkcias kiam vi testas ĝin permane. Uzu absolutajn vojojn por ĉio, kion la unuo devas trovi. Poste legu journalctl -u openvpn-client@office -b post reala lanĉo; unuo, kiu raportas sin aktiva sen tunelo, kutime nomas mankan dosieron en tiu protokolo.

Pli malnovaj pakoj liveras alian ŝablonan nomon, do systemctl list-unit-files 'openvpn*' decidas, kiu ekzistas sur ĉi tiu gastiganto.

Rekonekta konduto estas aparta decido

Profilo kun ping-restart rekonstruas la tunelon post kiam ĝi falas, kaj unuo kun restartiga direktivo faras ion similan je la servo-nivelo. Tiuj estas politikoj, kiujn vi elektas, ne defaŭltoj, kiujn vi heredas. Se la konekto devas leviĝi nur laŭpostule, forigu la restartigan konduton intence kaj skribu kial. Se la unuo startas antaŭ ol la reto estas uzebla, ĝi bezonas retrekan politikon, ĉar unu malsukcesinta provo ĉe lanĉo ne ripetiĝas per si mem.

Haltigo estas same laŭlitere: sudo systemctl disable --now openvpn-client@office haltigas la rulantan instancon kaj forigas la lanĉan ligilon. Nur malŝalti lasas la tunelon ruliĝi ĝis la sekva restarto, kio surprizas ĉiun, kiu testas malŝaltante kaj observante, ke la interfaco restas supre.

Restartu, poste kontrolu kvar aferojn laŭ ordo

Restarti la servon testas la servon; restarti la maŝinon testas la lanĉan vojon. Post la restarto konfirmu, ke la unuo leviĝis, poste ke ekzistas itinero por la fora subreto, poste kiun adreson la maŝino prezentas al la interreto, kaj fine ke nomoj solviĝas tra la tunelo. Tiuj kvar kontroloj malsukcesas en tiu ordo, kiam io misas, kio faras la unuan malsukceson la utila.

Aktiva unuo sen itinero kutime signifas, ke la profilo konektiĝis sed la servilo ne puŝis iun itinero, aŭ ke la itinero estis instalita sur interfaco, kiu poste malaperis. Itinero sen funkcianta nomserĉado montras al DNS-agordo anstataŭ al la tunelo mem.

Decidu anticipe, kio devus okazi, kiam la tunelo ne povas leviĝi. Reveni al ordinara konekteco estas politiko, kaj ĝi devus esti skribita anstataŭ lasita al tiu administrilo, kiu startis unue.