OpenVPN klijent se zaglavi kada njegov server radi na istom hostu

Imao sam laboratorijsku mašinu koja je primala tunel sa udaljene lokacije i istovremeno se povezivala na mrežu dobavljača. Odlazni profil je radio sedmicama. Nakon što je dolazni server dodat, odlazni se povezao i zatim prestao propuštati saobraćaj u roku od nekoliko sekundi, ili je odbio da se pokrene sa greškom da je adresa već u upotrebi. Konfiguracijske datoteke nisu bile promijenjene; host je jednostavno dobio drugi OpenVPN proces sa sopstvenim mišljenjem o portovima i rutama.

Kvar nije slučajan i nije problem autentifikacije. Dva daemona na jednoj mašini takmiče se za isti lokalni socket i istu tablicu rutiranja, a onaj koji se pokrene ili ponovo poveže posljednji obično pobjeđuje. Znanje koje od te dvije kolizije imate odlučuje gdje prvo gledati.

Pročitajte simptom unatrag

Počnite s tim kada tunel umire. Greška pri vezivanju na startu upućuje na stranu slušanja: nešto već posjeduje taj port, a OpenVPN odbija da se pokrene umjesto da ga dijeli. Tunel koji se podigne i zatim utihne upućuje na rutiranje, jer ruta koju je instalirala druga instanca može izvući pakete vanjske veze s njihove putanje.

Oba slučaja proizvode istu korisničku pritužbu, zbog čega petlje ponovnog pokušaja i watchdog skripte ne popravljaju ništa. One ponovo povezuju klijenta u isti sukob. Korisno prvo pitanje je da li proces još radi kada saobraćaj stane.

Jedan socket i jedan uređaj po instanci

Server koji sluša veže svoj port; odlaznom klijentu je također potreban lokalni port za njegov enkapsulirani saobraćaj. Kada oba žive na istom hostu, zadano ponašanje klijenta može se sudariti s portom servera. Lokalni port klijenta može se fiksirati, a vezivanje se može preskočiti tamo gdje partneru nije potreban fiksni izvorni port:

lport 1195
nobind
dev tun1

Ti brojevi su primjeri, ne zahtjev. Važno je da klijent prestane da se takmiči za port servera i da svaka instanca dobije zaseban tunelski uređaj. Dva daemona koja dijele tun0 prepisuju stanje uređaja jedan drugome čak i kada se njihovi portovi razlikuju, pa jedan uređaj po tunelu nije opcionalan.

nobind pripada klijentskoj strani. Server i dalje mora vezati i slušati, zato ne kopirajte liniju u konfiguraciju servera i ne isključujte vezivanje na klijentu čiji partner filtrira na fiksni izvorni port.

Odaberite jednog vlasnika zadane rute

Samo jedna veza može instalirati zadanu rutu. Ako oba profila preusmjeravaju sav saobraćaj, drugo povezivanje tiho zamjenjuje prvo, a prvo izgleda pokvareno. Ili zadržite odlazni tunel razdvojenim i gurajte samo prefikse dobavljača, ili mu dajte zasebnu tablicu rutiranja.

ip rule add from 10.9.0.2 table 120
ip route add default dev tun1 table 120
ip route get 10.9.0.2

Adrese i broj tablice iznad su rezervisani. Odmah nakon dodavanja pravila potvrdite da se vlastita adresa VPN servera još uvijek razrješava kroz normalnu tablicu; tablica koja hvata vanjski transport kvari tunel koji je trebalo zaštititi, a petlja ponovnog povezivanja koja slijedi izgleda kao nepouzdan provajder.

Za postavku koja mora preživjeti ponovna povezivanja i restarte, mrežni namespace je čvršća granica. Drugi klijent radi unutar svog namespacea sa svojim interfejsima i rutama, a izlažu se samo servisi koji moraju preći granicu. Host zadržava jednu zadanu rutu, a ponovno povezivanje namespacea je ne može prepisati.

Provjerite tablicom, ne statusnom linijom

Klijent koji prijavi da je povezan dokazuje samo svoj kontrolni kanal. Zabilježite stanje rutiranja prije i poslije svakog povezivanja, zatim pitajte kernel koji bi uređaj koristilo stvarno odredište:

ip route show
ip route get 10.40.0.20
ss -lunp | grep 1194

Ako se odabrani uređaj za adresu dobavljača promijeni kada se pokrene drugi tunel, imate koliziju ruta. Ako se oba procesa pojave na istom lokalnom portu, imate koliziju socketa. Popravljanje prvog bez drugog samo premješta kvar na sljedeće ponovno povezivanje.

Zapišite portove, uređaje, tablice i vlasnika rute u runbook hosta. Inače će sljedeća osoba koja doda treći tunel ponovo otkriti istu koliziju, a jedini vidljivi dokaz bit će veza koja radi dok se ne restartuje nečiji tuđi daemon.