VPN á beininum eða portflutningur: hvor vinnur?

Beinirinn lýkur VPN-tengingunni sjálfur, og gömul framrásarregla sendir enn sama UDP-portið á vél í staðarnetinu. Aðeins önnur þeirra getur verið raunverulegi endapunkturinn, og kjarninn úrskurðar ekki á milli þeirra. Þýðing áfangastaðar endurskrifar pakkann áður en spurt er um staðbundnu þjónustuna, svo VPN-ferlið bíður eftir umferð sem þegar hefur verið send annað. Verkefnið er að ákveða hver á portið, og fá svo reglurnar til að stemma.

Eitt port, tveir eigendur að nafninu

VPN-þjónn sem keyrir inni í beininum þarf inngönguheimild sem leiðir að eigin sokk. Færsla í áfangastaðar-NAT fyrir sama port leiðir allt annað: á staðarnetsfang og framrásarákvörðun. Þetta eru mismunandi endapunktar með mismunandi annálum og mismunandi bilunarháttum. Venjulega vísbendingin er sú að ein fjölskylda fanga virkar og hin ekki, því eftirstandandi færsla var skrifuð fyrir eina fjölskyldu og aldrei endurskoðuð.

Skrifaðu kröfuna niður áður en þú breytir: fjölskylda, ytra fang, flutningur, port og þýðingarmarkið.

Þýðingin fer fram fyrir staðbundnu athugunina

Áfangastaðar-NAT breytir marki pakkans í fyrirleiðsögn, áður en kjarninn velur á milli staðbundinnar afhendingar og framrásar. Þegar markið er hýsill í staðarnetinu fer pakkinn framrásarleiðina. Inntaksreglur fyrir eigin sokk beinisins eru aldrei skoðaðar, þess vegna helst VPN-annállinn tómur á meðan biðlarinn bíður.

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

Þessi röð er allt ferlið, og viðmót tækjanna fela hana bak við gátreiti án þess að breyta henni. Eigandi áfangastaðarins ákveður samt hvaða leið pakki fer.

Ef hýsillinn í staðarnetinu er ætlaði endapunkturinn er framrásin rétt og beinirinn ætti ekki líka að hlusta á það port.

Haltu einni vörpun og fjarlægðu hina

Teldu upp NAT-færslurnar fyrir það port og þá fjölskyldu og veldu þá sem lifir af:

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

TCP-færsla með sama númeri er óviðkomandi fyrir UDP-bilun, og að meðhöndla þær sem einn hlut leiðir til að röng regla er eyðilögð. Þegar staðbundni sokkinn á að vinna fjarlægir eða endurskrifar eigandi misvísandi vörpunarinnar þá einu færslu, og inngönguheimildin fyrir eigið port beinisins helst á sínum stað. Ótengdar framrásir, stjórnunarleiðin og afrit af reglusettinu ættu öll að lifa breytinguna af.

Ef VPN-ið býr á sér hýsli er framrásin rétti hluturinn. Þjónusta í gámi eða sýndarvél gæti þurft birt port þó að kassinn heiti beinir, svo fylgdu sokkinum og nafnrýminu hans frekar en merkimiðanum á kassanum.

Staðfestu eigandann utan frá

Prófaðu hverja fjölskyldu fyrir sig, því IPv6-tenging sem endar á beininum segir ekkert um IPv4-tengingu sem gömul regla beinir vísað. Lestu annál móttökurþjónustunnar til að sjá hvaða endapunktur svaraði, og líttu á árangursskilaboð biðlarans sem veikar sannanir. Nýtt flæði þarf fyrir merkilega prófun. Sendu könnun frá ytri hýsli með nc -zvu 203.0.113.7 1194 og lestu annál sigurvegarans með journalctl -u openvpn@server -n 20. Hlustari beinisins skráir tenginguna sjálfur, en hýsill í staðarnetinu skráir hana í eigin þjónustu.

Tengingarekstur heldur núverandi flæðum á upprunalegu vörpuninni, svo komin seta getur lifað lengur en reglan sem þú lagaðir rétt í þessu.

Þegar ætlaði endapunkturinn svarar með venjulegum auðkenningarprófunum sínum, prófaðu einkaaðauðlind bak við göngin. Að ná ytri hlustaranum er aðeins fyrsta stökkið; innri leiðsögn og heimild forrits eru aðskildar niðurstöður.