A VPN-átjárónak IP-továbbítás kell: mit ellenőrizzünk

Az ügyfél pingelheti az átjáró címét, miközben a mögötte lévő minden erőforrás elérhetetlen marad. Ez a két megfigyelés egy hozzá beszélő gazdagépet és egy nem irányító forgalomirányítót ír le, amelyek különböző szerepek ugyanazon a gépen. A továbbítás a köztük lévő kapcsoló.

A két szerep független, és a két címcsalád is az.

A saját címére válaszolni semmit sem bizonyít

Amikor egy csomag magának az átjárónak a címére szól, a helyi verem feldolgozza, és nem születik továbbítási döntés. Ezért egy sikeres ping az alagút címére vagy egy felügyeleti interfészre azt mondja, hogy a démon él és az alagút áll, miközben semmit sem mond a doboz mögötti hálózatnak szánt forgalomról. A kernel csak azoknál a csomagoknál nézi a továbbítási útvonalát, amelyek nem neki szólnak.

A követelményt szerepként olvassa, nem beállításként: ennek a gazdagépnek két interfész között kell csomagokat mozgatnia. Egy hordozható gép, amelynek csak egy távoli hálózatot kell elérnie, soha nem veszi fel ezt a szerepet, egy telephely-telephely végpont pedig mindig felveszi. A követelmény ilyen olvasása magyarázza, miért hibázik egy működő ügyfélkonfiguráció, amikor átjáróra helyezik.

Ugyanez a mondat érvényes a továbbítási döntés előtti tűzfalra, amelynek saját szabályzata van arról, mi továbbítható.

Minden címcsaládot külön ellenőrizzen

Az IPv4-továbbítás egy kapcsoló, az IPv6-továbbítás pedig egy másik, saját, interfészenkénti viselkedéssel. Az első engedélyezése semmit sem mond a másodikról, és egy kettős veremű ügyfél elérheti egy hálózat felét, miközben a többi sötét marad. Ezért két különböző családhoz tartozó ügyfél vitatkozhat ugyanarról az átjáróról. Kérdezze meg, melyik családot használta a hibázó ügyfél, mielőtt bármelyik beállítást szerkeszti. Erősítse meg mindkettőt, mielőtt arra jut, hogy az útválasztási terv hibás.

sysctl net.ipv4.ip_forward
sysctl -a --pattern 'net.ipv6.conf.(all|default).forwarding'
nft list ruleset | head -n 40

Sok disztribúción a futásidőben olvasott értéket egy szolgáltatás vagy egy konfigurációs fájl tette oda, ezért az egyszeri paranccsal végrehajtott változtatás eltűnhet újraindításkor. Keresse meg a beállítást birtokló fájlt, mielőtt a futásidejű értéket szerkeszti.

A továbbítás négy követelmény egyike

Egy működő továbbított folyamathoz egyszerre négy dolog kell: az ügyfélnek tudnia kell, hogy a cél az alagút mögött van, az átjárónak továbbvezető útvonala kell legyen, a válaszoknak visszautat kell kapniuk, és a tűzfalmak engedélyeznie kell a forgalmat. A forrásfordítás opcióként, nem szabályként tartozik ehhez a tervhez, mert a szimmetrikus útvonalú privát irányított hálózatnak nincs rá szüksége, az aszimmetrikusnak pedig általában van. A négy közül mindegyik önállóan hibázik, ezért az egyik javítása ritkán mozdítja el a tünetet. Írja le mind a négyet, mielőtt bármelyiket megváltoztatja.

A felhőplatformok ötödik szempontot adnak hozzá. Némelyik példányokon forrás- és célcím-ellenőrzést kényszerít ki, ami a továbbított csomagokat eldobja, függetlenül attól, hogyan van beállítva a vendég kernelje. Ott a platform saját hálózati dokumentációja a mérvadó, nem a VM-en belüli sysctl-kimenet.

Az ügyféltől teszteljen, ne az átjárótól

Az átjáró saját héjában futtatott teszt nem halad át azon a továbbítási útvonalon, amelyet épp most engedélyezett. Az ügyféltől generálja a forgalmat, akinél a probléma van, és erősítse meg, hogy az átjáró mögötti valamit ér el, nem magát az átjárót. Ez az egyetlen teszt, amely a megváltoztatott szerepet gyakorolja.

Tartsa külön a figyelő szabályokat és a továbbítási szabályokat a fejében és a változási naplóban. A VPN-port megnyitása beengedi az ügyfeleket a szolgáltatásba; semmit sem ad nekik a mögötte lévő hálózaton, és a kettő azonosnak látszik egy évek alatt megnőtt tűzfallistán.

Ha a csomagok megérkeznek, és a szolgáltatás utána elutasítja a felhasználót, már túljutott a hálózatkezelésen. Folytassa az alkalmazás-engedélyezéssel, ahelyett hogy újra szélesítené a továbbítási szabályzatot.