Zergatik zure LANak ezin duen VPN bezero bateko zerbitzu batera iritsi

Zure tunela martxan dago, zerbitzua entzuten ari da, eta bulegoko LANak oraindik ez du ezer jasotzen. Inork ez du VPNa hautsi. LANaren aldetik, ordenagailu eramangarriaren tunel helbidea ez da existitzen norbaitek LANari hara nola iritsi esaten dion arte, eta erantzunak eskaera irten zen bide beretik itzuli behar du. Ikusi ditut jendea guztiz osasuntsu dagoen tunel bat hiru aldiz berreraikitzen, inork itzulerako bidea begiratu aurretik.

Tunela ez da hautsi dena

Bi muturrak barruti pribatuetan daude, eta hori da kasu arrunta, ez konfigurazio okerra. 10.8.0.6 bezalako helbide bat erreala da tunelaren barruan eta ez da inon beste lekurik existitzen, beraz LANak ez du arrazoirik hara ezer bidaltzeko. Bideratzea ukitu aurretik, egiaztatu zerbitzua tunelaren barruan irisgarria den: bezeroan, ss -ltn tresnak erakusten du entzulea 127.0.0.1 helbidera, LAN interfazera edo tunel helbidera lotzen den. Loopback-era soilik lotuta dagoen daemon batek ez dio inori erantzuten bere buruari izan ezik, eta hori ez du inolako bidek, DNATek edo ataka-birbideratzeak aldatzen.

80 edo 443 atakako proxy bat beste tresna bat da, ikusgaitasun beste bat duena. Eskaerak mugitzen ditu, ez paketeak, beraz geruza okerra da datu-basearekiko konexio gordin baterako, eta hura eskuraeratzea da arazo hau hiru tresna sakonera iristea inork ezer neurtu aurretik.

Bidearen forma: esan LANari non dagoen multzoa

LANaren atebideko bide estatiko bat da erantzunik garbiena LANak eta tunelaren multzoak bat egiten ez dutenean. Zuzendu multzoa tunela amaitzen duen makinara:

ip route add 10.8.0.0/24 via 192.168.1.12
route add -p 10.8.0.0 mask 255.255.255.0 192.168.1.12   # Windows, persistent

Horrek norabide bakarra konpontzen du, eta horregatik aldaketa honen bertsio erdi-eginek aurrerapen itxura dute. Tunelaren aldeak dagokion erdia behar du, bestela erantzunak bezeroa uzten du bere bide lehenetsitik eta bidean hiltzen da:

push "route 192.168.1.0 255.255.255.0"

Bezero baten atzean dagoen azpisare baterako, zerbitzariaren atzean egon beharrean, zerbitzariak sistema-bide bat eta bezero horren fitxategian iroute sarrera bat behar ditu client-config-dir pean. iroute gabe, OpenVPN jakitun da aurrizkia existitzen dela eta ez du ideiarik zein bezerok duen horren jabe: paketeak iristen dira eta daemonak ez du haiekin bat egiteko ezer.

Hona hemen izena merezi duen mitoa. Bide batek helbidea iristeko modukoa egiten du; ez du beste aldea erantzuteko prest jartzen. Gunez guneko bikotekideek beste geruza bat eransten dute gainean, urruneko atebideak bere politikan zerrendatutako aurrizkien barruko iturburuak soilik onartzen baititu, eta etxeko multzo batetik datorren ordenagailu eramangarria ez dago horien barruan.

NATaren forma: DNAT barrura eta denek saltatzen duten SNAT lerroa

LANaren atebidea ukitu ezin duzunean, edo ataka bat zehazki argitaratu nahi duzunean, VPN ostalarian itzulpenak LANean inolako biderik gabe funtzionatzen du. Argitaratu ataka, birbideratu eta itzuli iturburua tunelera bidean:

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 8080 -j DNAT --to-destination 10.8.0.6:3000
iptables -A FORWARD -i eth0 -o tun0 -p tcp -d 10.8.0.6 --dport 3000 -j ACCEPT
iptables -t nat -A POSTROUTING -o tun0 -d 10.8.0.6 -p tcp --dport 3000 -j SNAT --to-source 10.8.0.1

Hirugarren lerroa da desagertzen dena. Saltatu eta bezeroak jatorrizko LAN helbidea ikusten du iturburu gisa, bere bide lehenetsitik erantzuten du, eta erantzun hori tunelera doa LANera itzuli beharrean. Konexioak bizirik iraungo duen ala ez, inoiz planifikatu ez zenuen bideratzearen araberakoa da orduan. SNATekin bezeroak zerbitzariaren tunel helbidea ikusten du, beraz erantzunak tunela jarraitzen du itzulpena desegin dezakeen ostalari bakarrera arte.

Kontsumo-firmwareak bere kate-izenak erabiltzen ditu eta ez du itzulpen hori zuretzat sortzen. Tomaton, sarrerako arau bat WANPREROUTING barruan erortzen da eta gero wanin bezalako iragazki-kate batean, eta osoa dirudien arau-multzo batek oraindik POSTROUTING lerro bat behar du eskuz. Hori ez da firmwarearen akatsa; sarrerako trafikoarentzat soilik idatzitako arau-multzoa da.

Zergatik uzten duen paketea zuzen dirudien arauak ere

Hutsegite hauetako gehienak ez daude begira ari zaren arauan. Egiaztatu lau gauza ordena honetan, eta gelditu betetzen ez den lehenengoan:

• Kateen ordena. iptables -I goian txertatzen du eta -A amaieran gehitzen du, beraz lehenagoko arau baimengarri edo blokeatzaile batek erabakitzen du lehenengo.
• Kate okerra. Routerrari berari zuzendutako trafikoak INPUT zeharkatzen du, eta birbidalitako trafikoak ez dio inoiz ukitzen. Zerbitzu bat argitaratzeko bietan arauak behar izaten dira.
• Norabide-bandera. -i tun0 bezeroengandik datorren trafikoarekin bat dator eta -o tun0 horiengana doan trafikoarekin. Bandera okerreko REJECT batek nahi ez zenuen zerbait blokeatzen du.
• Iturburu-murrizketa. Bezero helbide bat onartzen duen birbideratze bat bezero horretatik funtzionatzen du eta beste iturburu guztiak isildu gabe botatzen ditu.

Pakete-kontagailua zero duen arau bat ez dago bideean batere, eta kontagailuak irakurtzea da kate okerreko arazoa arau okerreko arazotik bereizteko modurik azkarrena.

Tokiko birbideratzea, LANean ezin denean ezer aldatu

SSH tokiko birbideratze batek galdera osoa saihesten du. Ez du biderik behar LANean, ez bezeroaren suebakiaren laguntzarik, ez inon argitaratutako atakarik:

ssh -N -f -L 3000:10.8.0.6:3000 user@vpn-host

Zerbitzua tunela mantentzen duen makinaren localhost:3000 helbidean agertzen da orduan, eta ez beste inon. Hori da muga: lan-estazio bat, ataka bat, eta birbideratzeak saioarekin batera hiltzen da zerbait berrabiarazten ez badu. Prestaketa datu-base bat egiaztatzen ari den administratzailearentzat tresna egokia da. Beste pertsona batzuek iritsi behar duten kamera edo eskaner baterako ez da, erabiltzaile bakoitzak bere birbideratzea beharko bailuke.

Egiaztatu bi norabideak beste arau bat gehitu aurretik

Itzulpenak arrastoak uzten ditu, eta horiek irakurtzea asmatzea baino hobea da. VPN ostalarian, conntrack -L tresnak erakusten du itzulpena gertatu ote zen, iptables -t nat -L -n -v tresnak kontagailuak mugitu ote ziren, eta tcpdump -ni any port 3000 tresnak zein iturburu helbide iritsi zen benetan. Bezeroan, ss -ltn tresnak baieztatzen du entzulea tunelak iristeko moduko helbide batean dagoela.

Gero aukeratu eutsiko diozun forma. Argitaratutako ataka bat, multzo osoarentzako bide bat eta administratzaile bakar baterako birbideratze bat hiru konpromiso desberdin dira, eta horiek nahastea da funtzionatzen duen konfigurazio bat sei hilabete geroago inork azaldu ezin duen beste bat bihurtzeko modua. Idatzi zein helbide den nondik iristeko modukoa, eta hau araztuko duen hurrengo pertsonak erantzunetik hasiko du, tunelatik beharrean.