OpenVPN klijent staje kada njegov poslužitelj radi na istom hostu

Imao sam laboratorijsko računalo koje je primalo tunel s udaljenog lokaliteta i istovremeno se povezivalo na mrežu dobavljača. Odlazni profil radio je tjednima. Nakon što je dodan dolazni poslužitelj, odlazni se povezao i zatim prestao propuštati promet u roku od nekoliko sekundi, ili je odbio pokrenuti se s greškom da je adresa već u upotrebi. Konfiguracijske datoteke nisu bile promijenjene; host je jednostavno dobio drugi OpenVPN proces sa svojim mišljenjem o portovima i rutama.

Kvar nije slučajan i nije problem autentifikacije. Dva daemona na jednom stroju natječu se za isti lokalni socket i istu tablicu usmjeravanja, a onaj koji se pokrene ili ponovno poveže posljednji obično pobjeđuje. Znanje koje od te dvije kolizije imate odlučuje gdje prvo pogledati.

Pročitajte simptom unatrag

Počnite s time kada tunel umire. Greška pri povezivanju na startu upućuje na stranu slušanja: nešto već posjeduje taj port, a OpenVPN odbija se pokrenuti umjesto da ga dijeli. Tunel koji se podigne i zatim utihne upućuje na usmjeravanje, 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 ponovno povezuju klijenta u isti sukob. Korisno prvo pitanje je radi li proces još uvijek kada promet stane.

Jedan socket i jedan uređaj po instanci

Poslužitelj koji sluša veže svoj port; odlaznom klijentu također treba lokalni port za njegov enkapsulirani promet. Kada oba žive na istom hostu, zadano ponašanje klijenta može se sudariti s portom poslužitelja. 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 natjecati se za port poslužitelja i da svaka instanca dobije zaseban tunelski uređaj. Dva daemona koja dijele tun0 prepisuju stanje uređaja onoga drugoga čak i kada se njihovi portovi razlikuju, pa jedan uređaj po tunelu nije opcionalan.

nobind pripada klijentskoj strani. Poslužitelj i dalje mora vezati i slušati, zato ne kopirajte liniju u konfiguraciju poslužitelja 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 promet, 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 usmjeravanja.

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 rezervirani. Odmah nakon dodavanja pravila potvrdite da se vlastita adresa VPN poslužitelja još uvijek razrješava kroz normalnu tablicu; tablica koja hvata vanjski transport kvari tunel koji je trebala zaštititi, a petlja ponovnog povezivanja koja slijedi izgleda kao nepouzdan pružatelj.

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

Provjerite tablicom, ne statusnim retkom

Klijent koji prijavi da je povezan dokazuje samo svoj kontrolni kanal. Zabilježite stanje usmjeravanja 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 ponovno otkriti istu koliziju, a jedini vidljivi dokaz bit će veza koja radi dok se ne restartuje nečiji tuđi daemon.