pfSense OpenVPN: elérés egy másik router mögötti hálózathoz

A laptopod a VPN-en keresztül eléri a pfSense LAN-ját, mégis kudarcot vall egy két ugrással beljebb lévő szolgáltatás elérésében, és a különbség tulajdonosonként egy útválasztási döntés. Három eszköznek meg kell egyeznie, mielőtt egy csomag befejezi oda-vissza útját: a kliensnek, a tűzfalnak és annak a routernek, amely valóban birtokolja a célhálózatot. Ha bármelyik kimarad, a tünet azonosnak látszik.

Kövess végig egy csomagot ezen a három döntésen, mielőtt szabályt módosítasz, mert minden tulajdonosnak más a vezérlése és más a meghibásodási módja.

Egy csomag, három útválasztási döntés

A kliens dönti el, hogy a cél az alagútba tartozik-e, és csak abból dönthet, amit tud: egy tolt útvonalból, egy helyi útvonalból vagy egy alapértelmezett útvonalból, amely már mindent lefed. A pfSense dönti el, hová küldje a csomagot következőként, ami egy másik router mögötti hálózat esetén statikus útvonalat jelent egy elérhető átjárón keresztül a helyes interfészen. Az alsó router dönti el, hogy ismer-e visszautat a VPN-poolhoz, és ha nem, a válasz eldobódik vagy egy haszontalan helyre kerül. Minden döntés független a másik kettőtől.

Bármelyikük meghibásodása ugyanazt a felhasználói jelentést adja. Ezért a hibakeresés sorrendje fontosabb, mint az eszközök.

Adj a kliensnek előtagot, ne találgatást

Egy pfSense SSL/TLS-kiszolgálón, ahol az IPv4-alagúthálózat nagyobb egy /30-nál, az IPv4 Local network(s) mező útvonalakat oszt ki a klienseknek csatlakozáskor. Add hozzá az alsó előtagot ott, ahelyett hogy a kliensre bíznád a kitalálását. Utána olvasd ki a kliens tényleges táblázatát a csatlakozás után, mert egy route-nopull beállítású profil vagy egy útvonalszűrő figyelmen kívül hagyhatja, amit a kiszolgáló küldött. A kiszolgáló lehet teljesen helyes, miközben a kliens semmit sem telepít.

Más kiszolgálómódoknak és topológiáknak mások a korlátai, és a kliensenkénti vagy kapcsolatonkénti házirend megváltoztathatja, mit kap egy adott kliens. A számító kliensen ellenőrizd, ne azon, amelyiket véletlenül először tesztelted.

Irányítsd a pfSense-t a belső routerre

A pfSense statikus útvonalához definiált és elérhető átjáró kell, és az ahhoz az átjáróhoz választott interfésznek annak kell lennie, amely ténylegesen eléri, ahogy a Netgate statikus útvonalakról szóló útmutatója leírja. Egy szemléltető elrendezésben a tranzitlink 192.168.77.1 a tűzfalon és 192.168.77.2 a belső routeren, a szolgáltatási hálózat pedig 172.16.30.0/25 mögötte. Az útvonal ezután az előtagot és a következő ugrást nevezi meg, nem a szolgáltatás címét. A távoli hálózatból származó cím átjáróként való használata gyakori módja annak, hogy olyan útvonal épüljön, amely helyesnek látszik, és sehová nem továbbít.

Egy interfész elnevezése nem írja le a mögötte lévő hálózatokat. A statikus útvonal az a leírás.

A túloldalnak ismernie kell a poolt

Az alsó routernek visszaútra van szüksége a poolhoz, ebben a példában 10.55.0.0/24 a 192.168.77.1-en keresztül, hacsak egy alapértelmezett útvonal vagy dinamikus protokoll már nem biztosít egyet. Magának a szolgáltatásgépnek az átjárójának afelé a router felé kell vezetnie, ami rendszerint igaz, ha a router az alapértelmezett átjárója, és hamis, ha a gépet kézzel konfigurálták. A tűzfal házirend-alapú útválasztása is felülírhatja a táblázatot adott forgalom esetén, ezért ellenőrizd, hogy egy szabály másik átjárót választ-e, mielőtt arra jutsz, hogy az útvonal hibás.

Ez a kialakítás nem igényel fordítást, és a kliens forráscímének láthatóan hagyása lehetővé teszi az alsó hálózat számára, hogy saját házirendjét alkalmazza.

Az átvételhez kövess végig egy friss kérést az alagút belépésén, a tűzfal belső kilépésén és a cél válaszán. Ha helyette szándékosan fordítást használnak, jegyezd fel, milyen forrást lát az alsó hálózat, és hogyan várható a válasz visszatérése.

Mentsd el a három tulajdonos tervét az engedélyezett alkalmazás mellé, hogy a következő rendszergazda újjáépíthesse az útvonalat, ahelyett hogy újra felfedezné.