VPN maršrutizatoriuje ar prievado peradresavimas: kas laimi?

Maršrutizatorius pats užbaigia VPN, o sena peradresavimo taisyklė vis dar siunčia tą patį UDP prievadą į LAN esantį kompiuterį. Tik vienas iš jų gali būti tikrasis galutinis taškas, o branduolys tarp jų nenusprendžia. Paskirties vertimas perrašo paketą prieš kreipiantis į vietinę tarnybą, todėl VPN procesas laukia srauto, kuris jau nusiųstas kitur. Užduotis yra nuspręsti, kam priklauso prievadas, ir tada suderinti taisykles.

Vienas prievadas, du pretenduojantys savininkai

Maršrutizatoriaus viduje veikiantis VPN serveris turi gauti įeinantį leidimą, vedantį į jo paties lizdą. Tos pačios prievados paskirties NAT įrašas veda visai kitur: į LAN adresą ir peradresavimo sprendimą. Tai skirtingi galutiniai taškai su skirtingais žurnalais ir skirtingais gedimo būdais. Įprastas požymis yra tai, kad viena adresų šeima veikia, o kita ne, nes likęs įrašas buvo parašytas vienai šeimai ir niekada nebuvo peržiūrėtas.

Užsirašykite pretenziją prieš redaguodami: šeima, išorinis adresas, transportas, prievadas ir išverstas tikslas.

Vertimas vyksta prieš vietinę patikrą

Paskirties NAT pakeičia paketo tikslą prieš maršrutizavimą, prieš branduoliui pasirenkant tarp vietinio pristatymo ir peradresavimo. Kai tikslas tampa LAN mazgu, paketas eina peradresavimo keliu. Įvesties taisyklės maršrutizatoriaus pačio lizdui niekada nenagrinėjamos, todėl VPN žurnalas lieka tuščias, kol klientas laukia.

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

Ši tvarka yra visas mechanizmas, o įrenginių sąsajos ją slepia už žymimųjų langelių jos nekeisdamos. Paketo kelią vis tiek nusprendžia paskirties savininkas.

Jei LAN mazgas yra numatytas galutinis taškas, peradresavimas yra teisingas ir maršrutizatorius neturėtų taip pat klausytis to prievado.

Palikite vieną susiejimą ir pašalinkite kitą

Išvardykite to prievado ir šeimos NAT įrašus ir pasirinkite išlikusį:

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

TCP įrašas su tuo pačiu numeriu yra nereikšmingas UDP gedimui, o traktuojant juos kaip vieną objektą ištrinama netinkama taisyklė. Kai turi laimėti vietinis lizdas, prieštaringo susiejimo savininkas pašalina arba perrašo tą vieną įrašą, o įeinantis leidimas maršrutizatoriaus pačiam prievadui lieka vietoje. Nesusiję peradresavimai, valdymo kelias ir taisyklių rinkinio kopija turėtų išgyventi pakeitimą.

Jei VPN gyvena atskirame mazge, peradresavimas yra tinkamas objektas. Tarnybai konteineryje ar virtualioje mašinoje gali prireikti paskelbto prievado, net kai dėžė vadinama maršrutizatoriumi, todėl sekite lizdą ir jo vardų erdvę, o ne etiketę ant korpuso.

Patvirtinkite savininką iš išorės

Išbandykite kiekvieną šeimą atskirai, nes IPv6 ryšys, pasibaigiantis maršrutizatoriuje, nieko nesako apie IPv4 ryšį, kurį nukreipia pasenusi taisyklė. Skaitykite priimančios tarnybos žurnalą, kad pamatytumėte, kuris galutinis taškas atsakė, ir laikykite kliento sėkmės pranešimą silpnu įrodymu. Prasmingam bandymui reikia naujo srauto. Siųskite zondą iš išorinio mazgo su nc -zvu 203.0.113.7 1194 ir skaitykite nugalėtojo žurnalą su journalctl -u openvpn@server -n 20. Maršrutizatoriaus klausytojas pats registruoja ryšį, o LAN mazgas jį registruoja savo tarnyboje.

Ryšių sekimas palaiko esamus srautus jų pradiniame susiejime, todėl užmegztas seansas gali pergyventi taisyklę, kurią ką tik pataisėte.

Kai numatytas galutinis taškas atsako savo įprastais tapatybės patikrinimais, išbandykite privatų išteklių už tunelio. Pasiekti išorinį klausytoją yra tik pirmas žingsnis; vidinis maršrutizavimas ir programos autorizacija yra atskiri rezultatai.