VPN sa router o pagpapasa ng port: alin ang panalo?
Maaaring nakawin ng pagpapasa ng port ang port mula sa tagapakinig ng VPN sa router. Suriin ang may-ari ng destinasyon, alisin lamang ang magkasalungat na mapping, at subukan ang bawat pamilya.
Ang router mismo ang nagtatapos sa VPN, at ang lumang tuntunin sa pagpapasa ay nagpapadala pa rin ng parehong UDP port sa isang makina sa LAN. Isa lamang sa kanila ang maaaring tunay na dulo, at hindi nagpapasya ang kernel sa pagitan nila. Isinusulat muli ng pagsasalin ng destinasyon ang packet bago tanungin ang lokal na serbisyo, kaya naghihintay ang proseso ng VPN sa trapik na naipadala na sa ibang lugar. Ang gawain ay magpasya kung kanino ang port, at pagkatapos ay pagtugmain ang mga tuntunin.
Isang port, dalawang may-aring nagsasabing nagmamay-ari
Ang isang VPN server na tumatakbo sa loob ng router ay nangangailangan ng papasok na pahintulot na patungo sa sarili nitong socket. Ang entry ng NAT ng destinasyon para sa parehong port ay patungo sa ganap na ibang lugar: isang LAN address at isang desisyon sa pagpapasa. Magkaibang dulo ang mga ito na may magkaibang log at magkaibang paraan ng pagpalya. Ang karaniwang palatandaan ay gumagana ang isang pamilya ng address at hindi ang isa, dahil ang natirang entry ay isinulat para sa isang pamilya lamang at hindi na muling sinuri.
Isulat ang paghahabol bago mag-edit: pamilya, panlabas na address, transport, port at ang isinaling target.
Ang pagsasalin ay nauuna sa lokal na pagsusuri
Binabago ng NAT ng destinasyon ang target ng packet sa yugto bago ang routing, bago pumili ang kernel sa pagitan ng lokal na paghahatid at pagpapasa. Kapag ang target ay isang host sa LAN, tinatahak ng packet ang landas ng pagpapasa. Hindi kailanman sinusuri ang mga tuntunin sa papasok para sa sariling socket ng router, kaya nananatiling walang laman ang log ng VPN habang naghihintay ang kliyente.
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
Ang pagkakasunod-sunod na iyon ang buong mekanismo, at itinatago ito ng mga interface ng aparato sa likod ng mga checkbox nang hindi ito binabago. Ang may-ari ng destinasyon pa rin ang nagpapasya kung aling landas ang tatahakin ng packet.
Kung ang host sa LAN ang inilaan na dulo, tama ang pagpapasa at hindi rin dapat makinig ang router sa port na iyon.
Panatilihin ang isang mapping at alisin ang isa
Ilista ang mga entry ng NAT para sa port at pamilyang iyon at piliin ang matitira:
sudo iptables -t nat -S | grep 1194
sudo ss -lunp | grep :1194
Ang entry ng TCP na may parehong numero ay walang kaugnayan sa pagpalya ng UDP, at ang pagtrato sa kanila bilang isang bagay ay nagdudulot ng pagbura ng maling tuntunin. Kapag dapat manalo ang lokal na socket, tinatanggal o isinusulat muli ng may-ari ng magkasalungat na mapping ang mismong entry na iyon, at nananatili sa lugar ang papasok na pahintulot para sa sariling port ng router. Ang mga walang kaugnayang pagpapasa, ang landas ng pamamahala at isang kopya ng set ng tuntunin ay dapat lahat na makaligtas sa pagbabago.
Kung ang VPN ay naninirahan sa isang hiwalay na host, ang pagpapasa ang tamang bagay. Ang isang serbisyo sa container o virtual machine ay maaaring mangailangan ng nai-publish na port kahit tinatawag na router ang kahon, kaya subaybayan ang socket at ang namespace nito, hindi ang label sa kahon.
Kumpirmahin ang may-ari mula sa labas
Subukan ang bawat pamilya nang hiwalay, dahil ang koneksyong IPv6 na nagtatapos sa router ay walang sinasabi tungkol sa koneksyong IPv4 na ini-redirect ng lumang tuntunin. Basahin ang log ng serbisyong tumatanggap upang makita kung aling dulo ang sumagot, at ituring na mahinang ebidensya ang mensahe ng tagumpay ng kliyente. Kailangan ng bagong daloy para sa makabuluhang pagsubok. Magpadala ng probe mula sa panlabas na host gamit ang nc -zvu 203.0.113.7 1194 at basahin ang log ng panalo gamit ang journalctl -u openvpn@server -n 20. Ang listener ng router ay naglo-log ng koneksyon mismo, habang ang host sa LAN ay naglo-log nito sa sarili nitong serbisyo.
Pinapanatili ng pagsubaybay ng koneksyon ang mga umiiral na daloy sa kanilang orihinal na mapping, kaya ang naitatag na sesyon ay maaaring mabuhay nang mas matagal kaysa sa tuntuning kakalikha mo lang.
Kapag sumagot ang inilaang dulo sa karaniwang pagsusuri ng pagkakakilanlan nito, subukan ang isang pribadong mapagkukunan sa likod ng tunnel. Ang maabot ang panlabas na listener ay unang hakbang lamang; ang panloob na routing at awtorisasyon ng aplikasyon ay magkaibang resulta.