Pi VPN s více routery: umístěte každou trasu na zařízení, které rozhoduje
Následný router přidává druhou klientskou podsíť a každé ze čtyř zařízení vlastní jedno rozhodnutí. Umístěte trasy, zkontrolujte zdroj a poté testujte z reálného klienta.
Umístění Wi-Fi krabice za Pi promění jedno směrovací rozhodnutí ve čtyři a plán se rozpadne, když se všechna čtyři učiní na jednom zařízení. První otázka není, kterou trasu přidat. Ale zda nová krabice přemosťuje, nebo směruje, protože tato odpověď určuje, kolik podsítí existuje a která zařízení se o nich musí dozvědět. Nejprve zvolte model připojení; každá trasa z něj vyplývá.
Most nebo směrování: volba, která určuje počet
Most umístí nové klienty do stejné podsítě, kterou Pi už obsluhuje. Jedna podsíť, jedna autorita DHCP a žádné předání ke směrování. To je jednodušší uspořádání a správná volba, když samostatná klientská síť nikdy nebyla požadavkem. Směrované spojení je jiný návrh: krabice si zachovává vlastní podsíť a tento prefix se musí přenášet všude, kam provoz jde.
Zbytek tohoto plánu zachovává následný router a chrání zdrojové adresy klientů. Cílem je jedna soukromá síť VPN, ne úplný výstup do internetu. Zapište model před adresami, protože seznam níže je jen příkladem směrovaného připojení.
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/24Kdo co rozhoduje
| 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 |
Každé zařízení činí jedno rozhodnutí a žádné nemůže učinit rozhodnutí jiného za něj. Pi potřebuje dva záznamy, ne jeden, a zpáteční cesta je ta, na kterou lidé zapomínají. Předávaný provoz správně dorazí do soukromé sítě a pak na zpáteční cestě umře, protože Pi netuší, kde žije 10.41.0.0/24. To vypadá jako problém brány firewall a ve skutečnosti je to chybějící trasa.
Vzdálená strana také potřebuje vlastní trasu. Pokud služba na vzdáleném konci neví, že 10.41.0.0/24 je dostupná přes váš tunel, odpovědi se zastaví na prvním skoku, který nemá odpověď. Přidejte oba směry, než začnete číst filtry paketů.
Další skoky pocházejí z připojení
Další skok musí být adresa v síti, do které se zařízení skutečně dostane. Veřejná adresa VPN partnera není dalším skokem pro soukromou podsíť a vzdálená servisní síť není dalším skokem vůbec. Trasa k nedostupné bráně vypadá v seznamu správně a zahodí každý paket. Ověřte, že brána odpovídá, než obviníte cíl.
Udržujte vnější VPN partner Pi dostupný přes jeho vlastní underlay trasu. Tento záznam je oddělený od tras užitečného zatížení a jejich smíchání dává tunel, který se po změně cesty nedokáže znovu navázat.
Dokumentace statických tras objasňuje rozdíl mezi cílem a bránou, i když každá platforma pojmenovává své nabídky jinak. Čtěte dokumentaci pro zařízení před sebou, místo abyste kopírovali obrazovku jiného výrobce. Příkazy níže ukazují podobu záznamů v Linuxu.
# 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.1Co dělá překlad se zdrojem
Pokud následný router už překládá své klienty na tranzitní adresu, vidí Pi jeden přeložený zdroj místo vlastní adresy každého klienta. To je jiný návrh než ten výše, který zachovává zdroj. Mění politiku založenou na zdroji, protokolování a to, která strana může zahájit spojení. Oba návrhy fungují; odpovídají na různé otázky.
Když upstream služba VPN odmítne směrovat klientský prefix zpět, úzký překlad na výstupu tunelu Pi může být legitimní náhradní řešení. Není to důkaz, že chybějící trasa byla zbytečná. Zaznamenejte, kterou adresu vzdálená síť skutečně vidí a jaká zpáteční cesta z toho vyplývá.
Volba trasy, povolení předávání a překlad zdroje zůstávají tři oddělené úlohy. Vyprázdnění sdíleného NAT řetězce nebo povolení každého rozhraní, protože jeden kabelový klient funguje, je způsob, jak se z fungujícího testu stane otevřený forwarder.
Dokažte to z klientského stroje
Pošlete požadavek ze stroje v následné LAN, pak sledujte jeho zdroj ven a zpět. Ping vydaný Pi nikdy necvičí následnou zpáteční trasu, a proto úspěšný ping dokazuje méně, než se zdá. Přidejte druhý test z kabelového klienta ve vlastní LAN Pi, aby se obě cesty daly porovnat. Oba zopakujte po restartu kteréhokoli zařízení.
Trasy přidané ručně a překlady, které se nikdy neuložily, zmizí společně. Dvojice pak vypadá jako nová porucha, ne jako nedokončená práce.
Uložte model připojení spolu s trasami, povolenou soukromou službou a jakýmkoli překladem do jedné poznámky. Právě tato poznámka brání tomu, aby další člověk považoval bezdrátové umístění za otázku směrovací politiky.