Usmeri eno podomrežje LAN skozi OpenVPN in ohrani privzeto pot

Naprave, ki usmerjajo za LAN in hkrati kličejo VPN, se znajdejo v istem sporu same s sabo: tunel želi imeti privzeto pot, LAN pa jo potrebuje nazaj. Ko se OpenVPN poveže, lahko namesti privzeto pot skozi tunel ali par polovičnih privzetih poti, kar je prav za prenosnik in narobe za prehod, katerega sosedje pričakujejo odgovore z njegovega naslova LAN. Odgovor ni, da VPN izpustiš. Odgovor je, da obema odločitvama daš različni tabeli.

Ena privzeta pot, dva lastnika

Posredovani promet in promet, ki nastane lokalno, ne morata iti po isti poti. Odjemalci LAN potrebujejo tunel samo za cilje, ki jih izbereš, medtem ko lastne seje upravljanja gostitelja in njegovi odgovori tem odjemalcem potrebujejo privzeto pot LAN. Mešanje obojega v glavni tabeli vsili en odgovor na dve različni vprašanji.

OpenVPN ima stikalo prav za to. route-noexec prepreči, da bi se odjemalec sploh dotaknil glavne tabele, vrednosti, ki bi jih uporabil, pa se izvozijo v skript route-up kot route_vpn_gateway, dev in naslovi vmesnika. Nato ti odločiš, katera tabela dobi katero pot, v kodi, ki jo lahko prebereš pozneje.

Tabela pravil proti prepisovanju glavne

Ločena tabela je edina možnost, ki se skalira dlje od enega podomrežja. Poimenuj jo enkrat, nato pa se sklicuj z imenom, da si nihče ne rabi zapomniti številke:

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

Naslovi tukaj so nadomestni. Preden kar koli zaženeš, zamenjaj predpono LAN, prehod tunela in ime naprave iz svoje namestitve.

Pravilo se mora ujemati tudi z gostiteljem

Pravilo, ki se ujema samo s predpono LAN, pokriva posredovane pakete. Ne pokriva prometa, ki ga ustvari prehod sam, niti odgovorov, ki jih pošilja nazaj odjemalcem LAN, ti pa nosijo naslov LAN prehoda kot vir. Ta iskanja padejo na main in lahko še vedno odidejo skozi tunel.

Dodaj drugo pravilo za lastni naslov LAN prehoda ali razširi prvo pravilo na množico, ki vključuje oba. Vrstni red je pomemben: bolj specifično pravilo postavi prvo in rezultat preveri z iskanjem, ki vir izrecno navede.

ip route get 203.0.113.9 from 192.168.50.1

Če to za cilj, ki bi moral ostati lokalen, poroča napravo tunela, je množica pravil napačna ne glede na to, kaj tabela vsebuje.

NAT ali pot na drugi strani

Strežnik VPN pozna podomrežje tunela in nič drugega. Paketi, ki pridejo z izvornim naslovom LAN, nimajo poti nazaj, razen če jo kdo zagotovi, in zagotoviti jo je mogoče natanko na dva načina. Dodajanje poti za predpono LAN na strežniku ohrani izvorni vir viden od konca do konca, kar preverjena zasnova običajno želi. Maskiranje na prehodu prepiše vir na naslov tunela in ne potrebuje sodelovanja strežnika.

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

Izberi NAT, ko strežnika ne nadzoruješ in tam ne moreš dodati poti. Izberi pot na strani strežnika, ko so pomembni dnevniki, nadzor dostopa ali simetrija povratne poti, ker maskiranje izbriše izvorni naslov iz vsega, kar druga stran zabeleži.

V vsakem primeru mora biti posredovanje omogočeno, strogo filtriranje povratne poti pa lahko zavrže odgovor, ko main ne bi izbral tunela za ta vir. Preveri dejansko vrednost, preden okriviš tunel.

Poskrbi, da delitev preživi ponovno povezavo

Ročno dodana pravila in poti izginejo, ko se vmesnik znova ustvari, zastarel vnos v tabeli pa lahko preživi sejo, ki ga je upravičevala. Vstavi pravilo tabele, pot tunela in vnos maskiranja v skript route-up odjemalca in na začetku skripta izprazni tabelo, da stari prehod ne more preživeti v novo sejo.

Preveri z obeh koncev: iskanje na prehodu z virom LAN in resnično zahtevo od odjemalca LAN do cilja, ki mora iti skozi tunel. Pot, ki obstaja, a ni nikoli izbrana, se obnaša natanko tako kot nikakršna pot, dokler ne prebereš števcev.