tun i parakrijuar në OpenVPN: krahasimi i dy modeleve të pronësisë

Dikush ka parakrijuar tun1, profili thotë dev tun1, dhe lidhja ende nuk bashkohet. Vetë ekzistenca e emrit në host nuk thotë pothuajse asgjë, sepse bashkimi varet nga hapësira e emrave, lloji i pajisjes, kush zotëron lidhjen dhe çfarë i lejohet demonit. Ripërdorimi i një pajisjeje imponon gjithashtu një vendim që konfigurimi i parazgjedhur e fsheh: cili komponent shkruan adresat dhe rrugët. Mënyrat e dështimit të dy rregullimeve ndryshojnë shumë më tepër sesa rreshtat e konfigurimit, prandaj vendosni përpara se të redaktoni një profil.

Emri nuk është bashkim

dev tun1 i kërkon OpenVPN atë ndërfaqe të emërtuar, dhe ndërtimet tradicionale në hapësirën e përdoruesit do të përpiqen ta hapin. Nëse emri nuk ndjek modelin e zakonshëm tun ose tap, profili ka nevojë edhe për dev-type përkatës, sepse lloji nuk nxirret kurrë nga një varg. Një pajisje TAP nuk është një pajisje TUN me etiketë tjetër: bashkimi i së gabuarës ose dështon menjëherë, ose prodhon një lidhje që mbart kuadro që askush nuk i pret. Kontrolloni llojin përpara çdo gjëje tjetër, sepse çdo kontroll i mëvonshëm supozon se të dyja palët pajtohen për të. Prej andej, konfirmoni se procesi me të vërtetë mund ta hapë pajisjen, e jo vetëm ta shohë.

dev tun1
dev-type tun

Ndërfaqja e rrjetit dhe /dev/net/tun janë objekte të ndryshme: njëra është një lidhje brenda një hapësire emrash, tjetra është pajisja e karaktereve që një program në hapësirën e përdoruesit përdor për t'u bashkuar. Dokumentacioni i Linux TUN/TAP përshkruan atë rrugë bashkimi dhe rregullat e pronësisë për pajisjet e qëndrueshme. Një shell root që mund të ekzekutojë ip link provon vetëm se shell-i ka privilegje, jo se demoni i ka. Pronësia e nyjës së pajisjes, grupi i aftësive të shërbimit dhe përdoruesi nën të cilin ekzekutohet duhet të përputhen të gjitha përpara se hapja të ketë sukses.

Një pajisje që ekziston dhe nuk hapet është problem pronësie, jo problem rrugëtimi. Trajtojeni si të tillë gjatë korrigjimit, përndryshe pasdite shkon duke lexuar tabela rrugëtimi që nuk ishin kurrë problemi.

Kush e konfiguron lidhjen: dy modele pronësie

Në modelin e parë OpenVPN konfiguron adresat dhe rrugët si pjesë e ngritjes së lidhjes. Ky është sjellja e parazgjedhur dhe më e lehta për t'u arsyetuar, sepse një komponent i vetëm e krijon gjendjen dhe pastaj e heq përsëri. Në modelin e dytë një menaxher i jashtëm zotëron ndërfaqen, dhe ifconfig-noexec e pengon OpenVPN të ekzekutojë komandat e tij të konfigurimit të adresave dhe ua dorëzon parametrat skripteve. Atëherë menaxheri duhet të zbatojë vetë konfigurimin e saktë lokal dhe të partnerit, që është më shumë punë sesa sugjeron emri i opsionit. Zgjedhja mes të dyve është një pyetje se kush mund ta ndryshojë lidhjen ndërsa është e ngritur.

ifconfig-noexec mbulon vetëm adresat: tabela e rrugëtimit mbetet e paprekur, dhe konfigurimi i rrugëve i takon route-noexec. Trajtojini dy direktivat si kontrola të veçanta me pronarë të veçantë, sepse vendosja e njërës dhe supozimi i tjetrës është një burim i zakonshëm lidhjesh gjysmë të konfiguruara. Zgjidhni saktësisht një pronar për shtresë, adresat në një vend dhe rrugët në një vend. Një menaxher rrjeti dhe një ndihmës VPN që të dy shkruajnë adresa është mënyra se si një shkëputje fshin gjendjen nga e cila pala tjetër varet ende.

Inspektoni pajisjen nga hapësira e emrave që ka rëndësi

Inspektoni pajisjen nga hapësira e emrave në të cilën ekzekutohet procesi VPN, jo nga ajo në të cilën ndodhet rastësisht shell-i juaj. Dy komandat më poshtë përgjigjen pyetjeve të ndryshme, dhe ndryshimi shfaqet kur një host sheh një ndërfaqe që një kontejner nuk e sheh. Ekzekutojini në rendin e dhënë, sepse e dyta ka kuptim vetëm pasi të dini nëse lidhja ekziston fare.

ip -details link show dev tun1
ip tuntap show

Komanda e parë shtyp lidhjen ashtu siç e sheh kerneli, duke përfshirë flamujt dhe llojin e ndërfaqes, dhe kështu konfirmoni se kjo është pajisja që kishit në mendje. E dyta liston hyrjet e qëndrueshme tun/tap, të cilat ekzistojnë pa i mbajtur asnjë proces. Një ndërfaqe që pret pronarin e saj të caktuar është një situatë e ndryshme nga një tunel i gjallë i bashkuar me një VPN tjetër, dhe vetëm e dyta shpjegon pse bashkimi juaj dështon. Gjeni procesin që mban pajisjen përpara se të ndryshoni çdo gjë, sepse një hyrje e qëndrueshme dhe një ndërfaqe e zënë kanë zgjidhje të ndryshme.

Mbështetja për shumë radhë është një rregullim i caktuar i drejtuesit me kërkesat e veta, jo një leje që procese të palidhura të ndajnë një ndërfaqe. Një sesion i gjallë i një pronari tjetër është problem koordinimi, dhe asnjë redaktim profili nuk e zgjidh.

Dy lloje qëndrueshmërie

Qëndrueshmëria e kernelit dhe persist-tun përshkruajnë jetëgjatësi që ngatërrohen lehtë dhe kushtojnë shtrenjtë. Një pajisje e qëndrueshme ekziston në mënyrë të pavarur nga çdo proces, prandaj i mbijeton një ndalimi dhe nisja tjetër mund ta ripërdorë. persist-tun i ruan burimet përgjatë rinisjeve të buta të mbështetura brenda një procesi OpenVPN, një horizont shumë më i shkurtër. Asnjëra nuk premton se ndalimi i shërbimit i lë rrugët dhe adresat në vendin e tyre, dhe një ndërfaqe që mbetet e dukshme nuk është provë e një sesioni të enkriptuar që funksionon.

Konfirmoni edhe backend-in, sepse një ndërfaqe e parakrijuar nuk thotë asgjë se cila implementim do ta hapë. Ndërtimet e komunitetit që mbartin rrugën e drejtpërdrejtë të të dhënave do të përpiqen ta përdorin, përveç nëse dizajni thotë ndryshe. Aty ku versioni e mbështet çelësin, disable-dco zgjedh në vend të tij rrugën në hapësirën e përdoruesit; motorët më të vjetër dhe klientët e tjerë nuk kanë një direktivë të tillë, prandaj mbani kushtin e versionit pranë opsionit në vend që të supozoni se zbatohet.

Çfarë thyhet kur testoni vetëm nisjen

Një marrëveshje pronësie mund të kalojë testin e parë dhe të dështojë në të fundit, gjë që e bën nisjen vetëm një kontroll të dobët. Vëzhgoni në vend të kësaj dy kalime: një rinisje të butë, dhe një ndalim të plotë të ndjekur nga një nisje.

systemctl status openvpn-client@lab
ip -details link show dev tun1

Nisja është rasti i lehtë: njësia ngrihet, lidhja shfaqet dhe dalja e statusit emërton profilin e ngarkuar. Bashkimi është momenti kur demoni hap pajisjen, prandaj ekzekutoni kontrollin e lidhjes pasi njësia raporton se është aktive, jo përpara. Nëse lidhja ekziston ndërsa statusi ende po aktivizohet, po shikoni një pajisje të qëndrueshme që askush nuk është bashkuar ende me të, jo një tunel që funksionon. Kaloni trafik të vërtetë përmes lidhjes përpara se të vazhdoni, sepse një ndërfaqe e bashkuar pa rrugë të përdorshme është ende dështim.

kill -SIGHUP $(pidof openvpn)
journalctl -u openvpn-client@lab -n 40
systemctl stop openvpn-client@lab
ip -details link show dev tun1

Një rinisje e butë duhet ta lërë sesionin të përdorshëm dhe burimet të paprekura, dhe pikërisht atë punë bën persist-tun. Ndalimi i plotë është vendi ku një menaxher i jashtëm e zbulon veten: nëse lidhja ose adresat e saj i mbijetojnë ndalimit, ato i zotëron dikush tjetër, dhe kjo është ose gjendja që dokumentuat, ose gabimi që sapo gjetët. Shënoni të dyja vëzhgimet pranë profilit, që ndryshimi tjetër të fillojë nga provat dhe jo nga një diagram.