Server apo klient: cila njësi OpenVPN në një Pi me rol të dyfishtë

Në një Pi ekzekutohen dy procese OpenVPN që njëkohësisht pranojnë përdorues endacakë dhe arrijnë një ofrues të sipërm, dhe nuk ndajnë pothuajse asgjë përveç harduerit. Njëri dëgjon tunelet hyrëse ndërsa tjetri lidhet nga jashtë. Secili lexon drejtorinë e vet, dhe secili ka mënyrën e vet të dështimit. Rinisja e atij të gabuar është mënyra më e zakonshme me të cilën një rregullim i klientit përfundon duke lëkundur dëgjuesin.

Përputhni emrin e njësisë me drejtorinë që ngarkon

Upstream 2.6 ofron dy njësi shabllon, [email protected] dhe [email protected]. Shablloni i serverit niset në /etc/openvpn/server dhe ngarkon %i.conf prej andej. Shablloni i klientit niset në /etc/openvpn/client. Një instancë e quajtur roaming mund të ekzistojë në të dyja vendet njëkohësisht, si server dhe si klient, me dy konfigurime pa lidhje dhe asnjë lidhje mes tyre përveç vargut.

Pyetni systemd në vend të sistemit të skedarëve, sepse paketuesit shtojnë skedarë shtesë që mund të ndryshojnë drejtorinë e punës ose argumentet që merr binari.

systemctl list-units --type=service 'openvpn-*@*'
systemctl cat [email protected]
systemctl show -p WorkingDirectory -p ExecStart [email protected]

Komanda e parë liston çdo njësi të krijuar, duke përfshirë ato që dështuan dhe mbetën të ngarkuara. E dyta printon skedarin e njësisë bashkë me çdo anulim. E treta është mënyra më e shpejtë për të parë dy faktet që vendosin çështjen: drejtorinë ku niset procesi, dhe rrugën e konfigurimit që iu dha.

Vendosni sipas drejtimit të paketave, jo sipas emrit të ndërfaqes

Një instancë serveri zotëron një socket dëgjimi dhe pranon lidhje. Transporti i saj i kriptuar është hyrje lokale dhe dalje lokale në Pi, ndërsa trafiku që përcjell për përdoruesit ndjek rrugën e përcjelljes dhe i përgjigjet një grupi tjetër rregullash. Një instancë klienti nuk ka dëgjues në atë kuptim: lidhet me një palë, prandaj transporti i saj i kriptuar është dalje lokale drejt shtresës së poshtme.

Ky ndryshim ju tregon se ku përket një rregull. Një rregull që përputhet me një ndërfaqe brenda një zinxhiri përcjelljeje lejon vetëm trafikun që rrugëtimi ka zgjedhur tashmë; nuk e zgjedh kurrë rrugën. Kur paketat e një përdoruesi endacak dalin në rrugën e gabuar, zinxhiri për t'u inspektuar është forward, jo output.

Shikoni socket-et përpara se të teoriconi. Një server i lidhur me udp/1194 tregon një socket dëgjimi. Klienti tregon një shoqërim me adresën e ofruesit dhe asgjë që dëgjon.

ss -lunp | grep openvpn
ss -unp state established '( dport = :1194 or sport = :1194 )'

Rruga e parazgjedhur e një instance mund të kapë përgjigjet e tjetrës

Një redirect-gateway i shtyrë nga klienti i sipërm instalon një rrugë të parazgjedhur që konkurron me gjithçka tjetër në makinë, duke përfshirë përgjigjet që serveri u dërgon përdoruesve endacakë. OpenVPN bën një përjashtim për adresën e palës së vet që tuneli të mbetet i arritshëm, por ky përjashtim nuk thotë asgjë për një telefon në një rrjet hoteli.

Simptoma zakonisht është asimetrike. Shtrëngimi i duarve përfundon, klienti raporton i lidhur, dhe trafiku vdes pas paketës së parë të përgjigjes. Rrugëtimi i politikave bazuar në burim, ose një shenjë pakete e vendosur në instancën e serverit me --mark, i mban dy rrjedhat të ndara; asnjëra nuk është një grup i plotë rregullash më vete, dhe të dyja kanë nevojë për rrugë të vlefshme në tabelën që zgjedhin.

Testoni vendimin lokal në vend të gjendjes së tunelit, sepse kerneli zgjedh burimin dhe ndërfaqen përpara se OpenVPN ta shohë paketën.

ip route get 203.0.113.44
ip rule show

Rinisni një rol dhe provoni që tjetri mbijetoi

Rendi ka rëndësi kur të dy rolet varen nga e njëjta shtresë e poshtme. Rinisni klientin i pari nëse rruga e sipërme duhet të ekzistojë përpara se trafiku i përdoruesve të mund të përcillet, dhe rinisni serverin i pari kur ndryshoni vetëm dëgjuesin ose grupin e tij. Në çdo rast, konfirmoni të dyja njësitë më pas, sepse një rinisje e dështuar mund ta lërë rolin tjetër të punojë me gjendje të vjetruar.

Shkruani kushtin e ndalimit përpara ndryshimit: a i bllokon përdoruesit endacakë humbja e tunelit të sipërm, apo bie përsëri në lidhjen e sipërme të vetë Pi? DNS dhe IPv6 gjithashtu kanë nevojë për një përgjigje të qartë, sepse një zgjidhës i shtyrë shpesh jeton më gjatë se rruga që e bëri të dobishëm.

systemctl restart [email protected]
systemctl is-active [email protected]
journalctl -u [email protected] -n 20 --no-pager

Pranoni ndryshimin vetëm kur tre gjëra vlejnë njëkohësisht: një lidhje e re hyrëse përfundon, një aplikacion i përcjellë arrin destinacionin përmes daljes së synuar, dhe të dy proceset ende raportojnë palën e tyre të pritur. Nëse njëra nga të treja dështon, keni ndryshuar instancën e gabuar ose rrugën e gabuar, dhe hapi tjetër është të rilexoni njësinë në vend që të rinisni diçka tjetër.