OpenVPN server i klijent na istom hostu: zašto klijenti otpadaju

Dodajte klijentski profil na mašinu na kojoj već radi VPN server i prva žrtva je postojeća usluga. Novi tunel se možda nikada ne uspostavi, ili se podigne dok klijenti servera tiho prestanu dobijati odgovore. Dvije kolizije daju oba ishoda: pool tunela koji je već u upotrebi i podrazumijevana ruta koju instalira nova klijentska polovina i koja pokriva cijelu tabelu. Nijedna ne proizvodi OpenVPN poruku o grešci, zato se kvar čita kao problem servera.

Jedna mašina, dvije uloge i dva nespojiva odgovora o tome kuda odgovori treba da idu.

Isti pool, dva servera: ko pobjedi

Svaka instanca servera treba vlastitu tunelsku podmrežu. Kopiranje reda kao što je server 10.8.0.0 255.255.255.0 u drugu konfiguraciju daje dvjema instancama isti prefiks, a ishod je ili odbijanje pokretanja ili tiha borba u kojoj klijenti jednog servera dobijaju adrese za koje i drugi misli da su njegove. Različiti UDP portovi i različita imena uređaja ne pomažu, jer nijedno ne dira adresni prostor. Promijenite drugi pool i promijenite ga svuda gdje ga rute spominju.

Popišite šta je aktivno prije uređivanja: ip -4 addr show prikazuje tunelske uređaje, ss -lunp prikazuje slušaoce, a systemctl list-units imenuje jedinice. Jedan pogled na tunelske adrese odlučuje sudaraju li se poolovi.

Šta klijentski profil dodaje tabeli

Klijentska polovina upisuje rute čim se poveže. redirect-gateway def1 dijeli podrazumijevanu rutu na 0.0.0.0/1 plus 128.0.0.0/1, obje usmjerene kroz novi uređaj, zajedno s host rutom do udaljenog servera koja je namjerno prikovana za fizički interfejs. Ta prikovanost postoji da bi tunel zadržao put za vlastiti transport. Sve ostalo, uključujući odgovore koje lokalni server duguje svojim klijentima, sada slijedi novu podrazumijevanu rutu i izlazi kroz udaljeni link.

Dakle, druga kolizija nije pokvaren tunel. To je ispravan tunel na pogrešnom mjestu u tabeli.

Tri načina da se uloge razdvoje

Najmanje invazivna popravka drži podrazumijevanu rutu izvan klijentskog profila: route-nopull plus eksplicitni redovi route za udaljene prefikse, tako da se lokalna tabela mijenja samo tamo gdje ste tražili. Sljedeći korak je pravilo politike koje izuzima lokalnu tunelsku podmrežu, puštajući odgovore lokalnim klijentima da izađu na interfejsu na koji su stigli, čak i dok podrazumijevana ruta postoji. Najtemeljitije je odvojeni mrežni namespace za klijentsku ulogu, koji potpuno uklanja dijeljenu tabelu i košta drugi kontekst rutiranja za održavanje.

Koji god put odabrali, izuzetak mora imenovati lokalnu tunelsku podmrežu, a ne LAN. Odgovor koji lokalni server šalje ima tunelsku adresu kao odredište, pa se izuzetak u obliku LAN-a nikada ne poklapa s njim.

Koja je od dvije instance kriva

Zaustavite klijentsku instancu i ponovo testirajte postojeće klijente. Trenutni oporavak znači rutiranje, a ne server. Vratite klijenta i pratite jedan odgovor uz ip route get kojem su zadani i izvorni i odredišni adresa, što pokazuje put koji bi kernel odabrao, a zatim gledajte interfejs koji paketi zaista koriste uz tcpdump -ni any port 1194. Statusna datoteka servera, koja se piše svakih nekoliko sekundi kroz direktivu status, nosi listu povezanih klijenata i brojače bajtova za oba smjera.

Čitajte te brojače jedan prema drugom. Saobraćaj koji izađe i nikada se ne vrati je odgovor o rutiranju, a ne problem rukovanja.