VPN bideratzailean edo ataka-birbideratzea: zeinek irabazten du?

Bideratzaileak berak amaitzen du VPNa, eta birbideratze arau zahar batek UDP ataka bera bidaltzen dio oraindik LANeko makinari. Horietako bat baino ezin da benetako amaiera-puntua izan, eta kernelak ez du bien artean erabakitzen. Helmugaren itzulpenak paketea berridazten du tokiko zerbitzua kontsultatu aurretik, beraz VPN prozesuak beste nonbait bidalitako trafikoaren zain egoten da. Zeregina ataka norena den erabakitzea da, eta gero arauak bat etortzea.

Ataka bat, bi jabe aldarrikatu

Bideratzailearen barruan exekutatzen den VPN zerbitzariak bere socket propiora daraman sarrerako baimena behar du. Ataka bererako helmugako NAT sarrera erabat beste leku batera doa: LANeko helbide batera eta birbideratze erabaki batera. Amaiera-puntu desberdinak dira, erregistro desberdinak eta hutsegite modu desberdinak dituztenak. Ohiko arrastoa da helbide familia bat funtzionatzen ari dela eta bestea ez, gainerako sarrera familia bakarrerako idatzi zelako eta ez zelako inoiz berrikusi.

Idatzi aldarrikapena editatu aurretik: familia, kanpoko helbidea, garraioa, ataka eta itzulitako helburua.

Itzulpena tokiko egiaztapenaren aurretik doa

Helmugako NATak paketearen helburua aldatzen du bideratze aurreko fasean, kernelak tokiko entrega eta birbideratzea aukeratu aurretik. Helburua LANeko host bat denean, paketeak birbideratze bidea hartzen du. Bideratzailearen beraren socketerako sarrera arauei ez zaie inoiz kontsultatzen, horregatik VPN erregistroa hutsik geratzen da bezeroak denbora agortzen duen bitartean.

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

Ordena hori da mekanismo osoa, eta gailuen interfazeek kontrol-laukitzen atzean ezkutatzen dute, aldatu gabe. Helmugaren jabeak erabakitzen du oraindik paketeak zein bide hartuko duen.

LANeko host-a nahi den amaiera-puntua bada, birbideratzea zuzena da eta bideratzaileak ez luke ataka horretan ere entzun behar.

Mantendu mapaketa bat eta kendu bestea

Zerrendatu ataka eta familia horretarako NAT sarrerak eta aukeratu biziraulea:

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

Zenbaki bereko TCP sarrera bat ez da UDP hutsegite baterako garrantzitsua, eta biak objektu bakar gisa tratatzeak arau okerra ezabatzera eramaten du. Tokiko socketak irabazi behar duenean, gatazkako mapaketaren jabeak sarrera hori kentzen edo berridazten du, eta bideratzailearen beraren atakarako sarrerako baimena lekuan geratzen da. Erlazionatu gabeko birbideratzeek, kudeaketa bideak eta arau-multzoaren kopiak aldaketari eutsi beharko liokete.

VPNa host bereizi batean bizi bada, birbideratzea da objektu egokia. Edukiontzi edo makina birtual bateko zerbitzu batek argitaratutako ataka bat behar dezake, kaxa bideratzaile deitzen den arren, beraz jarraitu socketa eta haren izen-espazioa, ez kaxaren etiketa.

Egiaztatu jabea kanpotik

Probatu familia bakoitza bereizita, bideratzailean amaitzen den IPv6 konexio batek ez baitu ezer esaten arau zaharra birbideratzen ari den IPv4 konexioari buruz. Irakurri hartzen duen zerbitzuaren erregistroa zein amaiera-puntuk erantzun duen ikusteko, eta hartu bezeroaren arrakasta mezua froga ahultzat. Proba esanguratsu baterako fluxu berria behar da. Bidali zunda kanpoko host batetik nc -zvu 203.0.113.7 1194 erabiliz eta irakurri irabazlearen erregistroa journalctl -u openvpn@server -n 20 erabiliz. Bideratzailearen entzuleak konexioa bera erregistratzen du, LANeko host batek bere zerbitzuan erregistratzen duen bitartean.

Konexioen jarraipenak lehendik dauden fluxuak jatorrizko mapaketan mantentzen ditu, beraz ezarritako saio batek zuk oraintxe konpondu duen araua baino gehiago iraun dezake.

Nahi den amaiera-puntuak bere identitate-egiaztapen ohikoekin erantzun ondoren, probatu tunelaren atzeko baliabide pribatu bat. Kanpoko entzulea iristea lehen jauzia baino ez da; barne bideratzea eta aplikazioaren baimena emaitza bereiziak dira.