A VPN-port megnyitása nem engedi a klienseket a LAN-ra

A tunnel feljön, a kliens hitelesíti magát, de az átjáró mögötti LAN láthatatlan marad. A szabály, amelynek ezt javítania kellett, engedi a VPN-portot, és pontosan úgy működik, ahogy leírták, mert az a szabály az átjárónak címzett csomagokra vonatkozik. Az átjáró mögötti hoszthoz menő kliensforgalomnak más a célja és más a lánca. A sikeres bejelentkezés nem változtat azon, hogy a kernel melyik láncot nézi.

Két lánc, két különböző cél

A csomag sorsát az dönti el, hová megy, nem az, hogyan érkezett. Az átjáró címére menő forgalom helyben kerül kézbesítésre, és a bemeneti szabályok alapján értékelődik. Az átjáró által továbbított forgalom a továbbítási szabályok alapján értékelődik. Ugyanaz a tunnel-interfész mindkét fajta csomagot előállíthatja, ezért egy szabály nem fedheti le mindkét feladatot.

Az egész mítosz egy mondatban: a figyelő engedélyezése semmit sem mond a mögötte lévő hálózat engedélyezéséről. Két külön döntés külön bizonyítékokkal, és az interfész neve mindkettőn nem egyesíti őket.

Mit engedélyez valójában a figyelő szabálya

A figyelő csomagjai a VPN-folyamatnál végződnek, és éppen ez teszi lehetővé a tunnel létrehozását. Az átjáró adminisztrációs oldala és egy helyi diagnosztikai válasz is a hoszt saját bemeneti útját használja, ezért az átjáró felé irányuló teszt sikerül, miközben minden mögötte meghiúsul. Mindkét eredmény helyes, és egyik sem a LAN-ról szól.

Amikor a folyamat egy másik célra dekapszulálja a kliens forgalmát, a csomag a továbbítási útra lép, és ott engedély kell hozzá. A sikeres hitelesítés eldönti, ki a kliens; nem dönti el, hová mehet. A két kérdésnek más a tulajdonosa, más a naplója és más a hibaüzenete.

Kliensről teszteljen, soha nem az átjáróról

Az átjárón készített teszt a hoszt saját kimeneti útját követi, és sikerülhet, miközben a továbbítási út zárva van. Indítsa a tesztet a kliensről, és figyelje a folyam mindkét végét.

nc -vz 10.40.7.25 445
tcpdump -ni tun0 host 10.40.7.25

Ha a kérés megjelenik a tun0 interfészen, és semmi nem érkezik meg a célhoz, a csomagot érkezés után eldobják, ami a továbbítási szabályokra vagy a cél saját szűrésére utal. Ha a tun0 interfészen semmi sem jelenik meg, a kliens még a tunnelbe sem küldi, és a probléma a kliens útválasztásában van, nem az átjáró házirendjében. Hasonlítsa össze egy helyesen kimenő, de semmit vissza nem adó kéréssel, ami a visszaút esete.

A továbbítás három dolgot igényel, nem egyet

A kernel továbbításának engedélyezve kell lennie, egy szűrőszabálynak el kell fogadnia a folyamot, és a célnak elérhetőnek kell lennie egy úttal a válasz visszatéréséhez. Ha bármelyik hiányzik, a csend a kliens szemszögéből ugyanaz.

sysctl net.ipv4.ip_forward
sudo iptables -S FORWARD
sudo iptables -S INPUT

Olvassa a három kimenetet együtt. Az elsőben lévő nulla a másik kettőt lényegtelenné teszi, a másodikban lévő alapértelmezett eldobási házirend pedig eldobja a kliens csomagjait, miközben az átjáró saját forgalma tovább működik. A harmadik kimenet megmutatja, miért soha nem a figyelő szabály volt a probléma.

Tartsa a két szabálykészletet külön a dokumentációban

Írja a figyelő szabályát és a továbbított szolgáltatás szabályát külön sorokba, külön tulajdonosokkal és indokokkal. Amikor a VPN-port változik, vagy új szolgáltatást tesznek közzé, ez a szétválasztás megakadályozza, hogy az egyik változás csendben kiterjessze a másikat.

Ahelyett, hogy minden hitelesített partnert megbízható LAN-tagnak tekintene, használjon szűk szabályokat azokra a klienssávokra és szolgáltatásokra, amelyeknek szükségük van rájuk. A StrongSwan továbbítási jegyzetei ugyanazon határ visszaút- és fordítási oldalát írják le, ami ismét egy harmadik döntés.

Végül tartsa egyenesen a rétegeket, amikor egy felhasználót elutasítanak. Ha a kérés eléri a hosztot, és az alkalmazás elutasítja a fiókot, javítsa az alkalmazás engedélyét azon a rétegen; a továbbítás szélesítése nem tud fájlmegosztási hitelesítő adatot adni, és szélesíti a hozzáférést minden másnak, aki sikeresen csatlakozik.