Klient OpenVPN pro celou LAN na OpenWrt: funkční pořadí
Vlastnictví rozhraní, zónová politika, maskarádování a tabulky pro jednotlivé SSID jsou čtyři oddělené úkoly. Udělejte je v pořadí a tunel pro celý router přestane vzdorovat.
Čtyři nezávislé úkoly dostanou celou LAN routeru za jeden tunel. Zařízení tunelu potřebuje vlastníka, zónu firewallu, cíl překladu směrem k upstreamu a, pokud mají některé klienty zůstat mimo VPN, směrování podle zdrojové adresy. Tunel, který se připojí, ale nic přes něj neprochází, obvykle nemá jednu z těchto čtyř věcí. Práce v pořadí závislostí znamená, že selhání na konci patří ke kroku, který jste právě změnili. Každý krok níže končí něčím, co můžete pozorovat, a tím se další krok nestane hádankou.
Rozhodněte, co tunel sdílí
Router, který rozdává Wi-Fi a DHCP, může klienta spustit sám. Tím se každé připojené zařízení dostane za tunel bez nastavování pro jednotlivá zařízení, a to je uspořádání, které většina malých lokalit chce. Zároveň je to uspořádání s nejširším dopadem, když tunel spadne, protože všechna zařízení ztratí cestu najednou. Nic v LAN si neudrží funkční trasu ven.
Druhý router za prvním, který spouští klienta s vlastní podsítí, omezí tunel na svá vlastní zařízení. Snáz se odstraňuje a snáz se vysvětluje tomu, kdo ho zdědí. Cenou je dostupnost mezi oběma stranami bez trasy nebo přesměrování portu.
Ať tak či onak, udělejte podsítě LAN odlišné. Stejné rozsahy dělají jednu stranu zdánlivě přímo připojenou a vzniklá černá díra vypadá hodiny jako závada VPN.
Dejte tunelu vlastníka
Deklarujte tunel jako síťové rozhraní s názvem, zařízením a bez vlastního protokolu. Síťový systém pak zařízení vytvoří a spravuje a vše navazující se na rozhraní odkazuje jménem, ne zařízením. Právě to zóně umožní ho najít.
Nevytvářejte stejné zařízení na dvou místech. Ručně vyrobený tunel vedle deklarovaného rozhraní vytvoří zařízení, které existuje, ale není v žádné zóně, nebo takové, které při znovunačtení zmizí. Obojí vypadá jako selhání klienta a ani jedno nevydá chybu, která by pojmenovala skutečnou příčinu. Zvolte deklarativní cestu a ruční smažte.
Držte název stejný v konfiguraci sítě, firewallu a VPN. Zóna vypisuje sítě podle názvu, takže překlep nechá tunel mimo všechny zóny, zatímco rozhraní samo vypadá zdravě. Zdravé rozhraní bez politiky je nejhůř rozpoznatelný stav.
Zařaďte ho do zóny a pak do ní přeposílejte
Zóna firewallu je místo, kde žije politika: input, output, forward a masquerade. Tunel v žádné zóně se řídí výchozími hodnotami, které jste nevybrali, a to je málokdy to, co klientský router potřebuje. Níže uvedené bloky deklarují rozhraní, umístí ho do zóny a povolí provozu z LAN vstup do této zóny.
config interface 'vpn'
option device 'tun0'
option proto 'none'
config zone
option name 'vpn'
list network 'vpn'
option input 'REJECT'
option output 'ACCEPT'
option forward 'REJECT'
option masq '1'
config forwarding
option src 'lan'
option dest 'vpn'
Ve vydáních starších než 21.02 se stejný řádek rozhraní píše option ifname, takže před vložením zkontrolujte, kterou podobu instalovaný firmware zpracuje. Blok přeposílání je oprávnění, které vůbec umožní provozu z LAN tunel používat. Bez něj je zařízení nahoře, klient připojený a žádný hostitel v LAN se do tunelu nedostane. To je nejčastější hlášení připojeno, ale bez internetu u klientských routerů.
Masquerade v zóně VPN slije každou adresu LAN do adresy tunelu routeru dřív, než paket odejde. Tím odpadá potřeba zpětné trasy k vaší podsíti na vzdálené straně.
Pokud vzdálená strana už vaši LAN směruje, vypnutí masquerade nechá zdrojové adresy viditelné a udělá protokoly pro jednotlivé klienty smysluplnými. Vyberte jednu možnost a zapište kterou, protože obě volby později přinesou různé dotazy podpory. Odebrání výchozího přeposílání z LAN do WAN je samostatné rozhodnutí s vlastním důsledkem. Odeberte ho a vlastní přístup routeru k internetu odejde s ním.
Pojmenujte skutečný upstream v NAT
Ve firmwaru, kde je pravidlo překladu psané ručně, je chybným polem odchozí rozhraní. Pravidlo s vlan2 neudělá nic, když relace končí na ppp0. Pravidlo úplně bez rozhraní může překládat provoz, který měl zůstat soukromý. Ani jedna chyba se neozve, protože tunel dál funguje.
iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE
Nahraďte ppp0 v tomto pravidle rozhraním z ip route nebo ze seznamu běžících rozhraní a pak sledujte čítač, když hostitel v LAN načítá stránku. Na routeru s jedním poskytovatelem obvykle stačí jedno pravidlo masquerade pro upstream. Druhé pravidlo pro rozhraní tunelu první nenahrazuje.
Potom přidejte klientské volby, které rozhodují, co do tunelu vstoupí. Direktiva redirect-gateway posílá internetový provoz klienta přes VPN a bez ní tunel nese jen trasy, které server protlačí. Než se dotknete DNS, zkontrolujte výslednou směrovací tabulku.
Rozdělte Wi-Fi druhou tabulkou
Jedna směrovací tabulka neudrží dvě výchozí brány. Druhá SSID, která má tunel obejít, proto potřebuje vlastní podsíť a vlastní tabulku. Přidělte tunelované SSID vlastní rozsah a pak směrujte jen ten rozsah do tunelu pravidlem, které vybere tabulku.
Balíčky směrování podle politiky na OpenWrt vyjadřují přesně tuto kombinaci. Ručně to jde taky: pravidlo podle zdroje a tabulka, jejíž výchozí hodnota míří na zařízení tunelu.
Zkontrolujte rozdělení z obou sítí. Klient na tunelované SSID má ukazovat výstupní adresu VPN a klient na běžné SSID adresu poskytovatele. Když oba vypadají stejně, pravidlo chytá špatný zdroj nebo se tabulka nikdy nečte. Testujte i po opětovném připojení, protože pravidlo závislé na názvu rozhraní se rozbije, když se zařízení přečísluje.
Podezírejte hodiny a příznak zařízení
Příznak persist-tun nechává zařízení tunelu na místě i mezi restarty. To se hodí serveru a mate klienta, jehož stav se má postavit od nuly. Při ladění klientského routeru ho odstraňte, protože zařízení, které přežije neúspěšné vyjednávání, skrývá, který krok se skutečně rozbil. Vraťte ho, až se klient bude připojovat spolehlivě, a ne dřív.
Hodiny jsou druhá tichá závada. Router bez hodin na baterii startuje na epoše, což znamená, že kontroly certifikátu selhávají, dokud NTP nedožene. Porovnejte časové značky v logu se skutečným časem, než se dotknete certifikátu, protože klient, který se připojí minutu po startu, obvykle čeká na synchronizaci času.