Pi VPN több routerrel: tedd minden útvonalat arra az eszközre, amely dönt
Egy alsóbb router második kliens alhálózatot ad hozzá, és a négy eszköz mindegyike egy-egy döntést birtokol. Helyezd el az útvonalakat, ellenőrizd a forrást, majd tesztelj egy valódi kliensről.
Egy Wi-Fi doboz Pi mögé helyezése egy útválasztási döntést négyre változtat, és a terv összeomlik, ha mind a négyet egy eszközön hozzák. Az első kérdés nem az, melyik útvonalat kell hozzáadni. Hanem hogy az új doboz hidat képez vagy routol, mert ez a válasz dönti el, hány alhálózat létezik, és mely eszközöknek kell tudniuk róluk. Először a csatlakozási modellt válaszd; minden útvonal abból következik.
Híd vagy routolás: a döntés, amely a számot meghatározza
A híd az új klienseket arra az alhálózatra teszi, amelyet a Pi már kiszolgál. Egy alhálózat, egy DHCP hatóság, és semmi átadás a routoláshoz. Ez az egyszerűbb elrendezés, és akkor a helyes, ha külön klienshálózat soha nem volt követelmény. A routolt kapcsolat más tervezés: a doboz megtartja a saját alhálózatát, és ezt az előtagot mindenhová vinni kell, amerre a forgalom megy.
A terv többi része megtartja az alsóbb routert, és megőrzi a kliensek forrás-címeit. A cél egy privát VPN-hálózat, nem teljes internetes kijárat. Írd le a modellt a címek előtt, mert az alábbi lista csak egy routolt csatlakozás példája.
client subnet 10.41.0.0/24
client gateway 10.41.0.1
router-to-Pi link 192.168.71.2
Pi on that link 192.168.71.1
private target 10.72.9.0/24Ki mit dönt
| Decision owner | Entry that encodes the decision | Failure when the entry is missing |
|---|---|---|
| Pi VPN host | Return route for 10.41.0.0/24 via 192.168.71.2, and a tunnel route for 10.72.9.0/24 | Replies to downstream clients die at the Pi |
| Owner of the remote network | A path for 10.41.0.0/24 over the permitted tunnel | Replies stop at the first unaware hop |
| LAN router behind the Pi | Specific route for 10.72.9.0/24 via 192.168.71.1, or a suitable default | Clients never send private traffic to the Pi |
| Client machine | Default via 10.41.0.1, or a specific entry for 10.72.9.0/24 | The private network is unreachable from the client |
Minden eszköz egy döntést hoz, és egyik sem hozhatja meg a másikét helyette. A Pinek két bejegyzésre van szüksége, nem egyre, és a visszaút az, amit az emberek elfelejtenek. A továbbított forgalom helyesen eléri a privát hálózatot, majd meghal visszafelé, mert a Pinek fogalma sincs, hol lakik a 10.41.0.0/24. Ez tűzfalproblémának látszik, és valójában egy hiányzó útvonal.
A távoli oldalnak is szüksége van a saját útvonalára. Ha a távoli vég szolgáltatása nem tudja, hogy a 10.41.0.0/24 elérhető az alagutadon keresztül, a válaszok az első ugrásnál megállnak, amelynek nincs válasza. Add hozzá mindkét irányt, mielőtt csomagszűrőket olvasol.
A következő ugrások a csatlakozásból jönnek
A következő ugrásnak olyan hálózaton kell lennie, amelyet az eszköz ténylegesen elér. A VPN-társ nyilvános címe nem következő ugrás egy privát alhálózat számára, és a távoli szolgáltatáshálózat egyáltalán nem következő ugrás. Az elérhetetlen átjáró felé vezető útvonal helyesnek látszik egy listában, és minden csomagot eldob. Ellenőrizd, hogy az átjáró válaszol-e, mielőtt a célt hibáztatod.
Tartsd a Pi külső VPN-társát elérhetően a saját alapszintű útvonalán keresztül. Ez a bejegyzés külön áll a hasznos teher útvonalaitól, és összekeverésük olyan alagutat ad, amely egy útvonalváltozás után nem tud újra felépülni.
A statikus útvonalak dokumentációja világossá teszi a cél és az átjáró közötti különbséget, bár minden platform másképp nevezi el a menüit. Olvasd el az előtted lévő eszköz dokumentációját ahelyett, hogy egy másik gyártó képernyőjét másolnád. Az alábbi parancsok a bejegyzések formáját mutatják Linuxon.
# on the Pi
ip route add 10.41.0.0/24 via 192.168.71.2
ip route add 10.72.9.0/24 dev tun0
# on the downstream router
ip route add 10.72.9.0/24 via 192.168.71.1Mit tesz a fordítás a forrással
Ha az alsóbb router már lefordítja a klienseit a tranzitcímre, a Pi egyetlen lefordított forrást lát minden kliens saját címe helyett. Ez más tervezés, mint a fenti forrásmegőrző. Megváltoztatja a forrásalapú szabályzatot, a naplózást és azt, melyik oldal kezdeményezhet kapcsolatokat. Mindkét tervezés működik; különböző kérdésekre válaszolnak.
Amikor egy felsőbb VPN-szolgáltatás megtagadja a kliens előtag visszairányítását, a Pi alagút-kimeneténél végzett szűk fordítás jogos ideiglenes megoldás lehet. Ez nem bizonyítja, hogy a hiányzó útvonal szükségtelen volt. Jegyezd fel, melyik címet látja valójában a távoli hálózat, és milyen visszaút adódik.
Az útvonalválasztás, a továbbítási engedély és a forrásfordítás három külön feladat marad. Egy megosztott NAT-lánc ürítése vagy minden interfész engedélyezése, mert egy vezetékes kliens működik, az az út, ahogy egy működő teszt nyitott továbbítóvá válik.
Bizonyítsd kliensgépről
Küldj kérést az alsó LAN egy gépéről, majd kövesd a forrását kifelé és vissza. A Pi által küldött ping soha nem gyakorolja az alsó visszautat, ezért egy sikeres ping kevesebbet bizonyít, mint aminek látszik. Adj hozzá egy második tesztet egy vezetékes kliensről a Pi saját LAN-ján, hogy a két út összehasonlítható legyen. Ismételd meg mindkettőt bármelyik eszköz újraindítása után.
A kézzel hozzáadott útvonalak és a soha nem mentett fordítások együtt tűnnek el. Ekkor a pár új hibának látszik, nem befejezetlen munkának.
Mentsd el a csatlakozási modellt az útvonalakkal, az engedélyezett privát szolgáltatással és bármilyen fordítással egyetlen jegyzetben. Ez a jegyzet az, ami megakadályozza, hogy a következő ember a vezeték nélküli elhelyezést útválasztási szabály kérdéseként kezelje.