VPN na ruteru ili prosljeđivanje porta: ko pobjeđuje?

Ruter sam prekida VPN, a staro pravilo prosljeđivanja još uvijek šalje isti UDP port na računalo u lokalnoj mreži. Samo jedno od toga može biti prava krajnja točka, a jezgro ne odlučuje između njih. Prevođenje odredišta prepisuje paket prije nego što se konzultira lokalna usluga, pa VPN proces čeka promet koji je već poslan negdje drugdje. Zadatak je odlučiti ko posjeduje port, a zatim uskladiti pravila.

Jedan port, dva tvrdnjena vlasnika

VPN server koji radi unutar rutera treba dolaznu dozvolu koja vodi do njegovog vlastitog socketa. Unos odredišnog NAT-a za isti port vodi sasvim drugdje: na adresu lokalne mreže i odluku o prosljeđivanju. To su različite krajnje točke s različitim zapisima i različitim načinima kvara. Uobičajen znak je da jedna porodica adresa radi, a druga ne, jer je preostali unos napisan za jednu porodicu i nikad nije ponovo pregledan.

Zapišite tvrdnju prije uređivanja: porodica, vanjska adresa, transport, port i prevedeno odredište.

Prevođenje ide prije lokalne provjere

Odredišni NAT mijenja cilj paketa u fazi prije usmjeravanja, prije nego što jezgro izabere između lokalne isporuke i prosljeđivanja. Kad cilj postane host u lokalnoj mreži, paket ide putem prosljeđivanja. Ulazna pravila za vlastiti socket rutera nikad se ne razmatraju, zato VPN zapis ostaje prazan dok klijent čeka.

Intended local entry:
WAN UDP 1194 -> router local socket -> input path

Conflicting old entry:
WAN UDP 1194 -> DNAT 192.168.50.10:1194 -> forward path

Taj poredak je cijeli mehanizam, a sučelja uređaja ga skrivaju iza potvrdnih okvira ne mijenjajući ga. Vlasnik odredišta i dalje odlučuje kojim putem paket ide.

Ako je host u lokalnoj mreži namjeravana krajnja točka, prosljeđivanje je ispravno i ruter ne bi trebao također slušati na tom portu.

Zadržite jedno mapiranje i uklonite drugo

Navedite NAT unose za taj port i porodicu i odaberite preživjelog:

sudo iptables -t nat -S | grep 1194
sudo ss -lunp | grep :1194

TCP unos s istim brojem nije relevantan za UDP kvar, a tretiranje njih kao jednog objekta dovodi do brisanja pogrešnog pravila. Kada lokalni socket treba pobijediti, vlasnik sukobljenog mapiranja uklanja ili prepisuje taj jedan unos, a dolazna dozvola za vlastiti port rutera ostaje na mjestu. Nepovezana prosljeđivanja, put za upravljanje i kopija skupa pravila trebaju svi preživjeti promjenu.

Ako VPN živi na odvojenom hostu, prosljeđivanje je pravi objekt. Usluzi u kontejneru ili virtualnoj mašini može trebati objavljeni port čak i kada se kutija zove ruter, pa pratite socket i njegov namespace, a ne naljepnicu na kućištu.

Potvrdite vlasnika izvana

Testirajte svaku porodicu odvojeno, jer IPv6 veza koja se završava na ruteru ne govori ništa o IPv4 vezi koju preusmjerava zastarjelo pravilo. Pročitajte zapis usluge koja prima da vidite koja je krajnja točka odgovorila, a poruku o uspjehu klijenta tretirajte kao slab dokaz. Za smislen test potreban je novi tok. Pošaljite probu s vanjskog hosta pomoću nc -zvu 203.0.113.7 1194 i pročitajte zapis pobjednika pomoću journalctl -u openvpn@server -n 20. Ruterov slušač bilježi vezu sam, dok je host u lokalnoj mreži bilježi u svojoj usluzi.

Praćenje veza zadržava postojeće tokove na njihovom izvornom mapiranju, pa uspostavljena sesija može nadživjeti pravilo koje ste upravo popravili.

Kad namjeravana krajnja točka odgovori svojim uobičajenim provjerama identiteta, testirajte privatni resurs iza tunela. Dosezanje vanjskog slušača samo je prvi skok; unutrašnje usmjeravanje i autorizacija aplikacije odvojeni su ishodi.