OpenVPN në nisjen e Ubuntu: NetworkManager apo systemd?

Shumica e udhëzuesve e paraqesin këtë zgjedhje si kozmetike: ose lini NetworkManager të ngrejë tunelin, ose aktivizoni një instancë systemd dhe kaq. Dy rrugët ndryshojnë në një gjë që vendos rezultatin në një makinë pa ekran, dhe ajo nuk ka asnjë lidhje me atë se cili mjet është më i ri. NetworkManager i shkyç sekretet përmes një sesioni; një instancë systemd nuk ka sesion për të shkyçur. Zgjidhni atë, trajtimi i sekreteve i së cilës përputhet me makinën përpara jush.

Gjithçka tjetër, nga instalimi i rrugëve deri te sjellja në rilidhje, rrjedh nga ai vendimi i parë.

Vargu i çelësave është diferenca për të cilën askush nuk flet

Kur NetworkManager zotëron një profil VPN, fjalëkalimi mund të jetojë në vargun e çelësave të identifikimit, i cili shkyçet kur përdoruesi identifikohet. Kjo funksionon mirë në një laptop: personi është i pranishëm, vargu hapet, tuneli ngrihet. Në një server që niset pa mbikëqyrje nuk ka njeri për të shkyçur asgjë, prandaj profili pret një sekret që nuk vjen kurrë. Lidhja duket e konfiguruar dhe nuk aktivizohet kurrë.

Instanca systemd e shmang atë problem duke lexuar një skedar kredencialesh nga disku, gjë që e bën skedarin atë që ju mbroni. chmod 400 plus pronësia nga root është minimumi, dhe skedari duhet të qëndrojë jashtë rezervave dhe shablloneve të imazhit që nuk i kontrolloni.

Lidhja e VPN-së me një lidhje nuk është garanci nisjeje

Në nm-connection-editor, zgjidhni lidhjen me kabllo ose pa tel në vend të VPN-së, hapni skedën General, shënoni opsionin për t'u lidhur automatikisht me një VPN dhe emërtoni profilin. Më pas NetworkManager aktivizon VPN-në si lidhje dytësore kur ajo primare arrin gjendjen e lidhur. Kjo është varësi, jo rregull muri zjarri. Paketat mund të dalin ende në sekondat përpara se tuneli të ngrihet, dhe një sekret i ruajtur që nuk shkyçet e lë makinën në linjë pa të.

Nëse kërkesa është që asgjë të mos dalë pa tunelin, thojeni dhe ndërtoni një çelës ndalimi, sepse ky rregullim nuk do të ofrojë një. Testoni gjithashtu pezullimin dhe rifillimin, sepse lidhja dytësore rivlerësohet në rrugën e kthimit.

Instanca systemd kërkon një emër skedari që përputhet

Vendoseni profilin në drejtorinë e klientit që pret paketa, si për shembull /etc/openvpn/client/office.conf, dhe referojuni nga brenda skedarit të kredencialeve me auth-user-pass office.cred. Emri i instancës është emri i skedarit pa prapashtesë, kështu që openvpn-client@office lexon office.conf. Aktivizojeni me sudo systemctl enable --now openvpn-client@office dhe konfirmoni përputhjen me systemctl cat openvpn-client@office në vend që të besoni një shembull nga një blog.

Rrugët brenda profilit zgjidhen në lidhje me drejtorinë e punës të njësisë, jo me vetë profilin, prandaj një rresht relativ ca ose auth-user-pass mund të dështojë në nisje edhe pse funksionon kur e testoni me dorë. Përdorni rrugë absolute për gjithçka që njësia duhet të gjejë. Më pas lexoni journalctl -u openvpn-client@office -b pas një nisjeje të vërtetë; një njësi që raporton aktive pa tunel zakonisht emërton një skedar që mungon në atë regjistër.

Paketat më të vjetra sjellin një emër tjetër shablloni, prandaj systemctl list-unit-files 'openvpn*' përcakton cili ekziston në këtë host.

Sjellja në rilidhje është një vendim i veçantë

Një profil me ping-restart rindërton tunelin pasi bie, dhe një njësi me direktivë rinisjeje bën diçka të ngjashme në nivel shërbimi. Këto janë politika që ju zgjidhni, jo vlera të paracaktuara që i trashëgoni. Nëse lidhja duhet të ngrihet vetëm sipas kërkesës, hiqni me qëllim sjelljen e rinisjes dhe shkruani përse. Nëse njësia niset përpara se rrjeti të jetë i përdorshëm, i duhet një politikë ripërpjekjeje, sepse një përpjekje e dështuar në nisje nuk përsëritet vetvetiu.

Ndalja është po aq fjalë për fjalë: sudo systemctl disable --now openvpn-client@office ndalon instancën që po ecën dhe heq lidhjen e nisjes. Vetëm çaktivizimi e lë tunelin duke ecur deri në rinisjen tjetër, gjë që befasojnë këdo që teston duke çaktivizuar dhe sheh ndërfaqen të mbetet lart.

Rinisni dhe më pas kontrolloni katër gjëra me radhë

Rinisja e shërbimit teston shërbimin; rinisja e makinës teston rrugën e nisjes. Pas rinisjes, konfirmoni se njësia u ngrit, më pas se ekziston një rrugë për nënrrjetin e largët, më pas cilën adresë makina i paraqet internetit dhe së fundi se emrat zgjidhen përmes tunelit. Ato katër kontrolle dështojnë pikërisht në atë rend kur diçka nuk shkon, gjë që e bën dështimin e parë të dobishëm.

Një njësi aktive pa rrugë zakonisht do të thotë që profili u lidh, por serveri nuk shtyu asnjë rrugë, ose që rruga u instalua në një ndërfaqe që zhduk më vonë. Një rrugë pa kërkim emrash funksional tregon konfigurimin e DNS dhe jo vetë tunelin.

Vendosni paraprakisht çfarë duhet të ndodhë kur tuneli nuk mund të ngrihet. Kthimi në lidhjen e zakonshme është politikë dhe duhet të shkruhet, në vend që t'i lihet menaxherit që nisi i pari.