A VPN-kliensek elérik a szervert, de a LAN-t nem: melyik megoldás?

Az ügyfél pingeli az OpenVPN-szerver alagút-címét és választ kap, majd kipróbál egy gazdagépet a szerver LAN-ján, és semmit sem kap. Ez a szétválás jelentősen szűkíti a hibát: az alagút áll, a továbbítás valószínűleg működik, és a válasz egy olyan ajtón távozik, amely nem vezet vissza. Három megoldás létezik, és a helyes attól függ, mit irányítasz és miről hajlandó vagy lemondani. Válaszolj az alábbi három kérdésre sorrendben, és a választás többé nem ízlés kérdése.

Először állapítsd meg, melyik irány hibás

A kérés a VPN-készletből származó forrás-címmel érkezik az alagút-interfészre. A szerver továbbítja a LAN-gazdagépnek, az pedig annak a járókapunak válaszol, amelyet a saját táblája megnevez, rendszerint a LAN-routernek. Ha a routernek nincs útvonala a készlethez, a válasz ott elhal, vagy az internet felé téved.

Teszteld mindkét gépet, mielőtt bármelyiket módosítanád. Kérdezd meg a szerver útvonaltábláját, hogyan érné el az ügyfelet; kérdezd meg a LAN-gazdagépet, hogyan érné el ugyanazt a címet. Az első lekérdezés rendszerint az alagútra mutat, a második a LAN-routerre, és ez a különbség a hiba egy sorban. Két lekérdezés olcsóbb, mint egy tűzfalvizsgálat, és eldönti a probléma irányát.

ip route get 10.8.0.37
sysctl -n net.ipv4.ip_forward

Ha a LAN-gazdagép már a VPN-szerverre mutat, a probléma egy tűzfalszabály vagy egy MTU-korlát, nem pedig hiányzó visszaút. Ne adj hozzá útvonalat egy szűrő javításához.

Első kérdés: szerkesztheted a távoli LAN routerét?

Ha a LAN-router a tiéd, tiszta válasz egy statikus útvonal a VPN-készlethez, amelynek következő ugrása a VPN-szerver LAN-címe. Ez érintetlenül hagyja az ügyfelek forrás-címeit, ami számít, amikor a LAN-gazdagépek cím szerint naplóznak, szűrnek vagy korlátozzák a sebességet. Fordításra sem tart igényt a szerveren, így az alagút tiszta útvonal marad. A kötelezettség, amit teremt, a dokumentáció, mert a készletnek, az útvonalnak és a szerver konfigurációjának egyeznie kell.

Csendben elbukik azon a napon, amikor valaki módosítja a készletet. Írd fel egyszer az értéket, és kezeld a három hely bármelyikén végzett módosítást mindhárom módosításaként.

Egy NAS vagy egy Layer 3-as kapcsoló, amely a szolgáltatást futtatja, ugyanezt az útvonalat igényli, kivéve ha mindent olyan routeren keresztül küld, amely rendelkezik vele. Ellenőrizd az eszközt, amely lezárja az alhálózatot, ne csak az internet felé nézőt. Kis hálózatokban gyakran három eszköznek van véleménye az útvonalválasztásról.

Második kérdés: megengedhető, hogy a LAN ne lássa az ügyfélcímeket?

Ha a router valaki másé, a VPN-szerveren végzett fordítás nem igényel együttműködést. A LAN-gazdagép a szerver LAN-címét látja, arra válaszol, és a szerver visszafordítja. Ezért viselkednek így a készülékek és a NAT-alapú távoli hozzáférési szerepek.

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

Az ár a besorolhatóság: az ügyfelenkénti címek eltűnnek a LAN-naplókból. A LAN-gazdagép bármely engedélyezési listájának ekkor a szervert kell megneveznie a készlet helyett.

Akkor válaszd a fordítást, amikor az együttműködés nem elérhető, nem akkor, amikor csupán kényelmetlen. Elrejti az ügyfelet minden jövőbeli vizsgálat elől, azok elől is, ahol tudnod kell, melyik laptop nyitott kapcsolatot. Megbonthat olyan protokollokat is, amelyek címeket ágyaznak a hasznos teherbe, mert a fordítás a fejlécben él. Egyik lehetőség sem fejlettebb; más-más kérdésre válaszolnak a tulajdonjogról.

Harmadik kérdés: a szerver maga egy másik alagút ügyfele?

Képzeld el a másik topológiát: a VPN-szerver egy kereskedelmi szolgáltatót is felhív, tehát két alagútja és két címkészlete van. A saját ügyfeleiért továbbított forgalom a szolgáltatón keresztül távozik, az pedig nem irányítja vissza a válaszokat a készlet címeire. Ezért tűnnek el a válaszok, pedig mindkét alagút egészséges.

A megoldás az, hogy a kimenő alagutat is maszkírozzuk, hogy a szolgáltató csak a szerver alagút-címét lássa. Az ellenkező iránynak saját szabálya kell, mert a szerver, amely kapcsolatot kezdeményez egy saját ügyfeléhez, más folyam. E szabály nélkül az ügyfél olyan címre válaszol, amelyet nem tud irányítani. Tedd a szűk szabályt bármely széles maszkírozás elé, hogy a konkrét fordítás nyerjen.

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o tun1 -j MASQUERADE
iptables -t nat -A POSTROUTING -d 10.8.0.0/24 -o tun0 -j SNAT --to-source 10.8.0.1

A több hálózati csatolójú gazdagépek rokon hibát adnak, amely az ügyfél felől azonosnak látszik. A válasz az alacsonyabb metrikájú interfészen távozik, mert a forrás-címet egy másik táblából választották. Ellenőrizd a visszautat egy lekérdezéssel ahelyett, hogy feltételeznéd, a menetút magában foglalja.

Ezután ellenőrizd mindkét irányt és mindkét méretet

A módosítás után pingelj az ügyféltől egy LAN-gazdagéphez, majd a LAN-gazdagéptől az ügyfélhez. A második irány az, amelyet az emberek kihagynak, és ez tárja fel a hiányos fordítási szabályt. Rögzítsd mindkét eredményt időbélyeggel, hogy egy későbbi regresszió összehasonlítható legyen.

Ezután mozgass valódi adatot, mert egy apró ping, amely sikerül, miközben egy nagy átvitel megakad, MTU-tünet. Ez a hiba rögtön azután jelenik meg, hogy gratuláltál magadnak az útvonal megjavításához.

Végül teszteld újra újraindítás után. A futásidejű útvonal- és tűzfalkapcsolók nem élik túl, és a javítás, amely a következő indításkor eltűnik, újra diagnózisra kerül valaki által, akinek kevesebb kontextusa van. Tedd a módosítást tartóssá úgy, ahogy a rendszered már teszi, majd indítsd újra egyszer szándékosan.