Proveďte jednu podsíť LAN přes OpenVPN a zachovejte výchozí trasu

Zařízení, která routují pro LAN a zároveň se připojují k VPN, se dostanou do stejného sporu sami se sebou: tunel chce vlastnit výchozí trasu a LAN ji potřebuje zpět. Když se OpenVPN připojí, může nainstalovat výchozí trasu tunelem nebo dvojici polovičních výchozích tras, což je správně pro notebook a špatně pro bránu, jejíž sousedé očekávají odpovědi z její adresy v LAN. Odpověď není VPN vynechat. Odpověď je dát oběma rozhodnutím různé tabulky.

Jedna výchozí trasa, dva vlastníci

Přeposílaný provoz a provoz vzniklý lokálně nemusí jít stejnou cestou. Klienti LAN potřebují tunel jen pro cíle, které zvolíte, zatímco vlastní správní relace hostitele a jeho odpovědi těmto klientům potřebují výchozí trasu LAN. Smíchání obojího v hlavní tabulce vnutí jednu odpověď dvěma různým otázkám.

OpenVPN má přepínač přesně pro tohle. route-noexec zabrání klientovi, aby se hlavní tabulky vůbec dotkl, a hodnoty, které by použil, se exportují do skriptu route-up jako route_vpn_gateway, dev a adresy rozhraní. Pak rozhodujete, která tabulka dostane kterou trasu, v kódu, který si můžete později přečíst.

Tabulka zásad versus přepisování hlavní

Samostatná tabulka je jediná možnost, která škáluje za jednu podsíť. Pojmenujte ji jednou a pak na ni odkazujte jménem, aby si nikdo nemusel pamatovat číslo:

echo "10 vpn" >> /etc/iproute2/rt_tables
ip rule add from 192.168.50.0/24 table vpn
ip route add default via 10.8.0.1 dev tun0 table vpn

Adresy jsou zde zástupné. Před spuštěním čehokoli nahraďte prefix LAN, bránu tunelu a název zařízení z vašeho vlastního nasazení.

Pravidlo musí odpovídat i hostiteli

Pravidlo, které odpovídá jen prefixu LAN, pokrývá přeposílané pakety. Nepokrývá provoz, který sama brána vytváří, ani odpovědi, které vrací klientům LAN, a ty nesou adresu brány v LAN jako svůj zdroj. Tato vyhledávání propadnou do main a stále mohou odejít tunelem.

Přidejte druhé pravidlo pro vlastní adresu brány v LAN, nebo rozšiřte první pravidlo na množinu, která zahrnuje obojí. Na pořadí záleží: konkrétnější pravidlo dejte první a výsledek ověřte vyhledáním, které zdroj výslovně uvede.

ip route get 203.0.113.9 from 192.168.50.1

Pokud to pro cíl, který má zůstat lokální, hlásí zařízení tunelu, je sada pravidel špatná bez ohledu na to, co tabulka obsahuje.

NAT, nebo trasa na vzdálené straně

Server VPN zná podsíť tunelu a nic jiného. Pakety přicházející se zdrojovou adresou LAN nemají zpáteční cestu, pokud ji někdo neposkytne, a poskytnout ji lze právě dvěma způsoby. Přidání trasy pro prefix LAN na serveru udrží původní zdroj viditelný od konce ke konci, což auditovaný návrh obvykle chce. Maskování na bráně přepíše zdroj na adresu tunelu a nepotřebuje žádnou součinnost serveru.

iptables -t nat -A POSTROUTING -s 192.168.50.0/24 -o tun0 -j MASQUERADE

Zvolte NAT, když server neovládáte a nemůžete tam přidat trasy. Zvolte trasu na straně serveru, když záleží na protokolech, řízení přístupu nebo symetrii zpáteční cesty, protože maskování maže původní adresu ze všeho, co vzdálená strana zaznamená.

V obou případech musí být zapnuté přeposílání a striktní filtrování zpětné cesty může odpověď zahodit, když by main pro tento zdroj tunel nezvolil. Před obviňováním tunelu zkontrolujte skutečnou hodnotu.

Ať dělení přežije opětovné připojení

Ručně přidaná pravidla a trasy zmizí, když se rozhraní znovu vytvoří, a zastaralý záznam v tabulce může přežít relaci, která ho ospravedlňovala. Vložte pravidlo tabulky, trasu tunelu a záznam maskování do skriptu route-up klienta a na začátku skriptu tabulku vyprázdněte, aby stará brána nemohla přežít do nové relace.

Ověřte z obou konců: vyhledání na bráně se zdrojem z LAN a skutečný požadavek z klienta LAN na cíl, který má projít tunelem. Trasa, která existuje, ale nikdy se nevybere, se chová přesně jako žádná trasa, dokud nepřečtete čítače.