Miért nem éri el a LAN a VPN-kliensen futó szolgáltatást

Az alagút él, a szolgáltatás figyel, a LAN mégsem kap vissza semmit. Senki nem törte el a VPN-t. A LAN felől a laptop alagútcíme addig nem létezik, amíg valami meg nem mondja a LAN-nak, hogyan érje el, és a válasznak ugyanazon az úton kell visszajönnie, amerre a kérés elment. Láttam, ahogy emberek háromszor építettek újra egy teljesen ép alagutat, mielőtt bárki a visszaútra nézett.

Nem az alagút tört el

Mindkét vég privát tartományokon ül, ami a normál eset, nem hibás konfiguráció. Egy 10.8.0.6-hoz hasonló cím valódi az alagúton belül, és mindenhol máshol nem létezik, tehát a LAN-nak nincs oka bármit is küldeni oda. Mielőtt az útválasztáshoz nyúlnál, erősítsd meg, hogy a szolgáltatás egyáltalán elérhető az alagúton belül: a kliensen a ss -ltn megmutatja, hogy a figyelő a 127.0.0.1-re, a LAN-interfészre vagy az alagútcímre köt-e. A csak loopbackre kötött démon senkinek nem válaszol önmagán kívül, és ezen semmilyen útvonal, DNAT vagy porttovábbítás nem változtat.

A 80-as vagy 443-as porton futó proxy más eszköz, más láthatósággal. Kéréseket mozgat, nem csomagokat, tehát rossz réteg egy nyers adatbázis-kapcsolathoz, és épp az érte való nyúlás az, amitől ez a probléma három eszközzel mélyebbre jut, mielőtt bárki bármit mér.

Az útvonal alakja: mondd meg a LAN-nak, hol a gyűjtő

A LAN átjáróján lévő statikus útvonal a legtisztább válasz, ha a LAN és az alagút gyűjtője nem fedi egymást. Irányítsd a gyűjtőt arra a gépre, amely lezárja az alagutat:

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

Ez csak egy irányt javít meg, ezért tűnnek az ilyen változtatások félkész verziói haladásnak. Az alagút oldalának kell a hozzáillő fél, különben a válasz elhagyja a klienst a saját alapértelmezett útvonalán, és útközben elpusztul:

push "route 192.168.1.0 255.255.255.0"

Egy kliens mögött, nem a szerver mögött álló alhálózat esetén a szervernek kell rendszerútvonal és egy iroute bejegyzés is abban a kliensfájlban, a client-config-dir alatt. iroute nélkül az OpenVPN tudja, hogy a prefix létezik, és fogalma sincs, melyik kliens birtokolja: a csomagok megérkeznek, és a démonnak nincs mivel párosítania őket.

Itt a mítosz, amely megérdemli a nevet. Az útvonal elérhetővé tesz egy címet; a túloldalt nem teszi készségessé a válaszra. A telephely-tetejére kapcsolatok még egy réteget tesznek rá, mert a távoli átjáró csak a szabályzatában felsorolt prefixek belsejében lévő forrásokat fogadja el, és az otthoni gyűjtőből érkező laptop nem ezeken belül van.

A NAT alakja: DNAT befelé, és az az SNAT-sor, amelyet mindenki kihagy

Amikor nem nyúlhatsz a LAN átjárójához, vagy pontosan egy portot akarsz közzétenni, a VPN-gazdán futó fordítás a LAN egyetlen útvonala nélkül is működik. Tedd közzé a portot, továbbítsd, és fordítsd a forrást az alagútba vezető úton:

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

A harmadik sor az, amely elmarad. Hagyd ki, és a kliens az eredeti LAN-címet látja forrásként, a saját alapértelmezett útvonalán válaszol, és az a válasz az alagútba megy a LAN felé visszafelé haladás helyett. Hogy a kapcsolat túlél-e, azután olyan útválasztástól függ, amelyet soha nem terveztél. SNAT-tal a kliens a szerver alagútcímét látja, tehát a válasz az alagúton visszafelé halad az egyetlen gazdáig, amely visszafordíthatja a fordítást.

A fogyasztói firmware saját láncneveket használ, és nem generálja ezt a fordítást helyetted. Tomato-n egy bejövő szabály a WANPREROUTING-ba, majd egy wanin-hoz hasonló szűrőláncba kerül, és egy teljesnek tűnő szabálykészletnek is kell egy kézi POSTROUTING-sor. Ez nem firmware-hiba; ez egy csak a bejövő forgalomra írt szabálykészlet.

Miért dobja el a helyesnek tűnő szabály mégis a csomagot

E hibák többsége nem abban a szabályban van, amelyre meredsz. Négy dolgot ellenőrizz ebben a sorrendben, és állj meg az elsőnél, amely nem teljesül:

• Láncsorrend. A iptables -I felülre szúr be, a -A pedig a végére fűz, tehát egy korábbi engedélyező vagy tiltó szabály dönt először.
• Rossz lánc. A magára az útválasztóra címzett forgalom az INPUT-on halad át, és a továbbított forgalom soha nem érinti. Egy szolgáltatás közzététele mindkettőben igényelhet szabályokat.
• Irányjelzők. A -i tun0 a kliensektől érkező forgalommal egyezik, a -o tun0 a feléjük menő forgalommal. Egy rossz jelzős REJECT olyat blokkol, amit nem szerettél volna.
• Forráskorlátozás. Egy továbbítás, amely egy klienscímet fogad el, attól a klienstől működik, és minden más forrást szó nélkül eldob.

A nulla csomagszámlálójú szabály egyáltalán nincs az úton, és a számlálók olvasása a leggyorsabb módja annak, hogy elválasszuk a rossz lánc problémáját a rossz szabály problémájától.

A helyi továbbítás, amikor a LAN-on semmi nem változtatható

Egy helyi SSH-továbbítás megkerüli az egész kérdést. Nem kell útvonal a LAN-on, nem kell a kliens tűzfalának együttműködése, és nem kell sehol közzétett port:

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

A szolgáltatás ekkor az alagutat tartó gép localhost:3000-jén jelenik meg, és sehol máshol. Ez a határ: egy munkaállomás, egy port, és a továbbítás a munkamenettel együtt meghal, hacsak valami újra nem indítja. Egy előkészítő adatbázist ellenőrző adminisztrátornak ez a megfelelő eszköz. Egy kamerához vagy szkennerhez, amelyet másoknak is el kell érniük, nem az, mert minden felhasználónak saját továbbításra lenne szüksége.

Ellenőrizd mindkét irányt, mielőtt újabb szabályt adsz hozzá

A fordítás nyomokat hagy, és ezeket olvasni jobb, mint találgatni. A VPN-gazdán a conntrack -L megmutatja, megtörtént-e egyáltalán a fordítás, a iptables -t nat -L -n -v megmutatja, elmozdultak-e a számlálók, a tcpdump -ni any port 3000 pedig megmutatja, melyik forráscím érkezett meg valójában. A kliensen a ss -ltn megerősíti, hogy a figyelő olyan címen van, amelyet az alagút elér.

Utána válaszd ki azt az alakot, amelyet megtartasz. Egy közzétett port, egy útvonal az egész gyűjtőre és egy továbbítás egyetlen adminisztrátornak három különböző kötelezettség, és ezek keverése az, amitől egy működő beállítás olyanná válik, amelyet fél év múlva senki nem tud elmagyarázni. Írd le, melyik cím honnan érhető el, és a következő ember, aki ezt hibakeresi, a válasznál kezdi, nem az alagútnál.