Server ili klijent: koja OpenVPN jedinica na Pi-ju s dvostrukom ulogom

Dva procesa OpenVPN rade na Pi-ju koji istovremeno prima roaming korisnike i doseže gornjeg provajdera, i oni gotovo ništa ne dijele osim hardvera. Jedan sluša dolazne tunele dok se drugi javlja prema van. Svaki čita svoj direktorij, i svaki ima svoj način kvara. Restartovanje pogrešnog je najčešći način da „popravka klijenta“ umjesto toga uzdrma slušaoca.

Uskladite naziv jedinice s direktorijem koji učitava

Upstream 2.6 isporučuje dvije šablonske jedinice, [email protected] i [email protected]. Šablon servera počinje u /etc/openvpn/server i odatle učitava %i.conf. Šablon klijenta počinje u /etc/openvpn/client. Instanca nazvana roaming može postojati na oba mjesta istovremeno, i kao server i kao klijent, s dvije nepovezane konfiguracije i bez veze među njima osim niza znakova.

Pitajte systemd, a ne datotečni sistem, jer paketari dodaju dodatne datoteke koje mogu promijeniti radni direktorij ili argumente koje binarna datoteka prima.

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

Prva naredba navodi svaku instanciranu jedinicu, uključujući one koje su pale i ostale učitane. Druga ispisuje datoteku jedinice zajedno sa svakim prepisom. Treća je najbrži način da vidite dvije činjenice koje odlučuju pitanje: direktorij u kojem proces počinje, i putanju konfiguracije koja mu je dodijeljena.

Odlučite po smjeru paketa, ne po nazivu interfejsa

Serverska instanca posjeduje socket za slušanje i prihvata veze. Njen šifrovani transport je lokalni ulaz i lokalni izlaz na Pi-ju, dok saobraćaj koji prosljeđuje za korisnike slijedi putanju prosljeđivanja i odgovara drugom skupu pravila. Klijentska instanca u tom smislu nema slušaoca: ona se javlja peeru, pa je njen šifrovani transport lokalni izlaz prema donjem sloju.

Ta razlika vam kaže gdje pravilo pripada. Pravilo koje odgovara interfejsu unutar lanca prosljeđivanja samo dozvoljava saobraćaj koji je rutiranje već odabralo; ono nikada ne bira rutu. Kada paketi roaming korisnika izađu pogrešnim putem, lanac koji treba provjeriti je forward, a ne output.

Pogledajte sockete prije nego što teoretizirate. Server vezan na udp/1194 pokazuje socket za slušanje. Klijent pokazuje asocijaciju na adresu provajdera i ništa što sluša.

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

Default ruta jedne instance može uhvatiti odgovore druge

redirect-gateway koji gurne gornji klijent instalira default rutu koja se takmiči sa svim ostalim na mašini, uključujući odgovore koje server šalje roaming korisnicima. OpenVPN pravi izuzetak za vlastitu peer adresu da bi tunel ostao dostupan, ali taj izuzetak ne govori ništa o telefonu na hotelskoj mreži.

Simptom je obično asimetričan. Handshake se završi, klijent prijavi vezu, i saobraćaj umre nakon prvog paketa odgovora. Rutiranje politike zasnovano na izvoru, ili oznaka paketa postavljena na serverskoj instanci sa --mark, drži dva toka odvojenim; nijedno samo po sebi nije potpun skup pravila, i oba trebaju važeće rute u tabeli koju odaberu.

Testirajte lokalnu odluku, a ne stanje tunela, jer kernel bira izvor i interfejs prije nego što OpenVPN vidi paket.

ip route get 203.0.113.44
ip rule show

Restartujte jednu ulogu i dokažite da je druga preživjela

Red je važan kada obje uloge zavise od istog donjeg sloja. Restartujte klijenta prvo ako gornja ruta mora postojati prije nego što se korisnički saobraćaj može prosljeđivati, a restartujte server prvo kada mijenjate samo njegov slušalac ili njegov pool. U svakom slučaju poslije potvrdite obje jedinice, jer neuspjeli restart može ostaviti drugu ulogu da radi sa zastarjelim stanjem.

Zapišite uslov zaustavljanja prije promjene: da li gubitak gornjeg tunela blokira roaming korisnike ili se vraća na Pi-jev vlastiti uplink? DNS i IPv6 također trebaju jasan odgovor, jer gurnuti resolver često nadživi rutu koja ga je učinila korisnim.

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

Prihvatite promjenu samo kada tri stvari vrijede istovremeno: nova dolazna veza se završi, proslijeđena aplikacija stigne do odredišta kroz predviđeni izlaz, i oba procesa još uvijek prijavljuju svog očekivanog peera. Ako jedna od tri ne uspije, promijenili ste pogrešnu instancu ili pogrešnu rutu, i sljedeći korak je ponovno čitanje jedinice, a ne restartovanje bilo čega drugog.