VPN në ruter apo përcjellje porti: kush fiton?

Ruteri e përfundon vetë VPN-në, dhe një rregull i vjetër përcjelljeje vazhdon të dërgojë të njëjtin port UDP te një makinë në LAN. Vetëm njëri prej tyre mund të jetë pika e vërtetë e fundit, dhe kernel-i nuk vendos mes tyre. Përkthimi i destinacionit e rishkruan paketën përpara se të konsultohet shërbimi lokal, kështu që procesi i VPN-së pret trafik që tashmë është dërguar diku tjetër. Detyra është të vendoset kush e zotëron portin, dhe më pas rregullat të pajtohen.

Një port, dy pronarë të pretenduar

Një server VPN që ekzekutohet brenda ruterit ka nevojë për një leje hyrëse që të çon te socket-i i tij. Një zë NAT destinacioni për të njëjtin port të çon diku krejt tjetër: te një adresë LAN dhe një vendim përcjelljeje. Këto janë pika të ndryshme fundore me regjistra të ndryshëm dhe mënyra të ndryshme dështimi. Treguesi i zakonshëm është se një familje adresash funksionon dhe tjetra jo, sepse zëri i mbetur u shkrua për një familje të vetme dhe nuk u rishikua kurrë.

Shkruani pretendimin përpara redaktimit: familja, adresa e jashtme, transporti, porti dhe objektivi i përkthyer.

Përkthimi zhvillohet para kontrollit lokal

NAT-i i destinacionit e ndryshon objektivin e paketës në fazën para rrugëtimit, përpara se kernel-i të zgjedhë mes dorëzimit lokal dhe përcjelljes. Sapo objektivi të jetë një host LAN, paketa merr rrugën e përcjelljes. Rregullat hyrëse për socket-in e vetë ruterit nuk konsultohen kurrë, prandaj regjistri i VPN-së mbetet bosh ndërsa klienti pret.

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

Ky rend është i gjithë mekanizmi, dhe ndërfaqet e pajisjeve e fshehin pas kutive të zgjedhjes pa e ndryshuar. Pronari i destinacionit vazhdon të vendosë cilën rrugë merr një paketë.

Nëse host-i i LAN-it është pika e synuar e fundit, përcjellja është e saktë dhe ruteri nuk duhet të dëgjojë gjithashtu në atë port.

Mbani një hartëzim dhe hiqni tjetrin

Listoni zërat NAT për atë port dhe familje dhe zgjidhni të mbijetuarit:

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

Një zë TCP me të njëjtin numër është i parëndësishëm për një dështim UDP, dhe trajtimi i tyre si një objekt i vetëm çon në fshirjen e rregullit të gabuar. Kur socket-i lokal duhet të fitojë, pronari i hartëzimit në konflikt heq ose rishkruan pikërisht atë zë, dhe leja hyrëse për portin e vetë ruterit mbetet në vend. Përcjelljet e palidhura, rruga e administrimit dhe një kopje e grupit të rregullave duhet të mbijetojnë të gjitha ndryshimin.

Nëse VPN-ja jeton në një host të veçantë, përcjellja është objekti i saktë. Një shërbim në një kontejner ose makinë virtuale mund të ketë nevojë për një port të publikuar edhe kur kutia quhet ruter, prandaj ndiqni socket-in dhe hapësirën e tij të emrave, jo etiketën në kuti.

Konfirmoni pronarin nga jashtë

Testoni çdo familje veçmas, sepse një lidhje IPv6 që përfundon në ruter nuk thotë asgjë për një lidhje IPv4 që një rregull i vjetër e ridrejton. Lexoni regjistrin e shërbimit pritës për të parë cila pikë fundore u përgjigj, dhe trajtoni mesazhin e suksesit të klientit si provë të dobët. Nevojitet një fluks i ri për një test kuptimplotë. Dërgoni një sondë nga një host i jashtëm me nc -zvu 203.0.113.7 1194 dhe lexoni regjistrin e fituesit me journalctl -u openvpn@server -n 20. Dëgjuesi i ruterit e regjistron vetë lidhjen, ndërsa një host LAN e regjistron në shërbimin e vet.

Ndjekja e lidhjeve i mban flukset ekzistuese në hartëzimin e tyre origjinal, kështu që një sesion i vendosur mund t’i mbijetojë rregullit që sapo rregulluat.

Pasi pika e synuar e fundit përgjigjet me kontrollet e saj të zakonshme të identitetit, testoni një burim privat pas tunelit. Të arrish dëgjuesin e jashtëm është vetëm hapi i parë; rrugëtimi i brendshëm dhe autorizimi i aplikacionit janë rezultate të veçanta.