LAN-router és VPN-kliens: két eszköz, két útválasztási tábla

Két eszköz továbbítja a csomagot, és mindegyik a saját tábláját tartja. A LAN-router tudja, hogy a távoli előtag a VPN-klienshez tartozik, a VPN-kliens pedig tudja, hogyan érje el azt az előtagot az alagútján keresztül. Ha csak az első táblát konfigurálja, a csomag olyan géphez érkezik, amelynek nincs megfelelő útvonala, így újra elhagyja az alapértelmezett útvonalon. Ez az egész hiba, és a LAN felől útválasztási huroknak tűnik, mert majdnem az is.

Rajzolja fel a két ugrást, mielőtt útvonalhoz nyúl

Vegyen egy szemléltető elrendezést: LAN-gazdagépek a 192.168.50.0/24 címen, a hétköznapi router a 192.168.50.1 címen, egy dedikált kliens a 192.168.50.15 címen, és egy távoli LAN a 10.60.0.0/24 címen, amely csak azon az alagúton át érhető el, amellyel ez a kliens rendelkezik. A két privát tartomány közül egyik sem fedi át a másikat, és az alagútnak saját címterve van.

Mindkét privát tartomány számít, mert eldöntik, melyik eszköz válaszolhat. A távoli oldal látni fogja, hogy a csomag a kliens alagútcíméről érkezik, és a válaszának utat kell találnia vissza a 192.168.50.0/24 címre. Ha csak a kimenő irány van konfigurálva, a kérés működhet, miközben a válasz eltűnik.

1. lépés: irányítsa a routert a kliensre, ne az alagútra

A LAN-routeren adjon hozzá egy célútvonalat, amelynek következő ugrása a kliens LAN-címe:

ip route add 10.60.0.0/24 via 192.168.50.15
ip route get 10.60.0.55

Ez a bejegyzés azt mondja: „juttasd el ahhoz a géphez, amely tud alagutat építeni”. Semmit nem mond arról, hogyan épül az alagút, és nem helyettesíti a kliens saját útvonalát. Felügyelt routeren a megfelelője az eszköz statikus útvonalak oldalán él; Linux-routeren az LAN-t birtokló interfész konfigurációjához tartozik, nem egy héjhoz, amelyet be fog zárni.

Ellenőrizze a második parancs válaszát. Ha a klienst gateway-ként, a LAN-interfészt pedig device-ként jelenti, az első ugrás helyes, és a fennmaradó munka a másik gépen van.

2. lépés: adjon a kliensnek saját útvonalat az alagút oldalán

A kliens most csomagot kap a 10.60.0.0/24 címre, és megnézi a saját tábláját. Ha az alagút-konfigurációja telepített útvonalat ehhez az előtaghoz, a csomag titkosítva megy tovább. Ha nem, a csomag a szokásos alapértelmezettel egyezik, és visszakerül a 192.168.50.1 címre, amely újra elküldi a kliensnek.

Nézzen körül, mielőtt bármit hozzáad:

ip route show table all | grep -E "10\.60\.0\.0/24|default"
sysctl net.ipv4.ip_forward

A minden táblában hiányzó előtag-útvonal az a lelet, amelyet keres. Adja hozzá az alagút saját konfigurációján keresztül, hogy a következő újracsatlakozás újra telepítse; a kézi ip route add eltűnik a munkamenettel, és a legalkalmatlanabb pillanatban hozza vissza a hibát. A következő ugrás az alagút interfésze vagy a cím, amelyet a VPN a társaként kioszt, a klienstől függően, és a társ címének az aktuális profilból kell jönnie, nem egy régi feljegyzésből.

A hurok, amikor előfordul, a gyakorlatban nem végtelen: a TTL minden körben csökken, és a csomag időtúllépési üzenettel elhal. Ezért sugallhat egy ismétlődő traceroute ciklust, miközben egy kliens, amely egyszerűen nem továbbít, ugyanazt a csomagot csendben eldobja.

3. lépés: engedélyezze a továbbítást, és válassza ki a visszautat

A fogadás és a továbbítás különböző engedélyek. A net.ipv4.ip_forward=1 a kliensen kernel szinten engedi az átjárást, és egy tűzfalszabálynak még mindig engedélyeznie kell a LAN-interfész és az alagút között. Egy szabály, amely a kliens saját kezelőoldalához enged hozzáférést, nem enged átjárást a távoli LAN felé, és ezt a különbséget könnyű elnézni, amikor ugyanaz a gazdagép helyben válaszol a pingekre.

A távoli oldalon a tükörprobléma jelentkezik. Tudnia kell, hogy a 192.168.50.0/24 elérhető ezen a hitelesített kliensen keresztül. OpenVPN esetében ez általában egy kliensenkénti útvonalat jelent, amelyet a szerverkonfiguráció tol ki, vagy egy kliensspecifikus fájlt a szerveren, amely deklarálja a kliens mögötti LAN-t. Enélkül a távoli LAN vagy eldobja a választ, vagy a saját alapértelmezett átjárójára küldi, ami az internet.

A forrásfordítás az alternatíva, amikor a LAN-előtag nem hirdethető meg. Egy hatókörrel rendelkező masquerade-szabály a kliensen átírja a forrást az alagútcímre, és a válaszok akkor természetesen visszatérnek. Elrejti azt is, melyik LAN-gazdagép indította a kérést, és önmagában nem engedi, hogy a távoli oldal befelé indítson kapcsolatokat. Válassza ezt a kompromisszumot tudatosan, ahelyett hogy egy mindenre kiterjedő masquerade-ot adna hozzá, és később fedezné fel a mellékhatást.

4. lépés: tegye mindkét döntést maradandóvá, majd tesztelje a valódi utat

Minden útvonalnak van gazdája, és a gazda az a konfiguráció, amely rendszerindításkor vagy újracsatlakozáskor újra létrejön. A routeren ez lehet statikus útvonalbejegyzés; a kliensen lehet a VPN-profil, a NetworkManager vagy a systemd-networkd. Ellenőrizze az alagút újracsatlakoztatásával és a kliens újraindításával, majd olvassa el újra a táblát, ahelyett hogy megbízna a szerkesztésben.

Hagyja érintetlenül az alapértelmezett útvonalat, amely az alagút külső kapcsolatát hordozza. Az „egyszerűsítés” érdekében történő lecserélése eltöri a titkosított utat, mielőtt bármilyen belső forgalom használhatná, és a tünet egy alagút, amely a változtatás után soha nem áll helyre.

Egy hétköznapi LAN-gazdagépről teszteljen, ne a kliensről, mert a kliensen keletkező kérés soha nem gyakorolja a router első ugrását. Szerezzen be egy szolgáltatást, amely csak a távoli LAN-on létezik, és erősítse meg a válasz törzsét, majd nézze meg a kliens számlálóit vagy naplóit, hogy lássa az átjárást. Egy belső traceroute, amely privát ugrásokat mutat, a továbbítást bizonyítja, nem a titkosítást: a külső út külön megfigyelés, és csak az alagút saját interfész-számlálói mutatják, mi távozott rajta.