Rut ét LAN-undernet gennem OpenVPN og behold standardruten
Behold LAN-standardruten, mens ét undernet kører gennem tunnelen. Sammenlign en policytabel med ændringer af hovedtabellen, og vælg derefter NAT eller en rute på serversiden.
Bokse, der router for et LAN og samtidig ringer op til en VPN, ender i samme diskussion med sig selv: tunnelen vil eje standardruten, og LAN’et har brug for den tilbage. Når OpenVPN forbinder, kan den installere en standardrute gennem tunnelen eller et par halve standardruter, hvilket er rigtigt for en bærbar computer og forkert for en gateway, hvis naboer forventer svar fra dens LAN-adresse. Svaret er ikke at springe VPN’en over. Svaret er at give de to beslutninger forskellige tabeller.
Én standardrute, to ejere
Videresendt trafik og lokalt opstået trafik behøver ikke tage samme vej. LAN-klienter har kun brug for tunnelen til de destinationer, du vælger, mens værtens egne administrationssessioner og dens svar til disse klienter har brug for LAN-standardruten. At blande begge i hovedtabellen tvinger ét svar ned over to forskellige spørgsmål.
OpenVPN har en kontakt netop til dette. route-noexec forhindrer klienten i at røre hovedtabellen overhovedet, og de værdier, den ville have brugt, eksporteres til et route-up script som route_vpn_gateway, dev og interface-adresserne. Derefter bestemmer du, hvilken tabel der får hvilken rute, i kode du kan læse senere.
Policytabel kontra omskrivning af hovedtabellen
| Approach | What it buys | What it costs |
|---|---|---|
| Separate table plus source rule | LAN traffic and host traffic keep independent defaults | Every lookup now depends on rule order |
| Editing the main table only | Fewer moving parts on a single-purpose host | One mistake takes the gateway offline entirely |
| Two half-default routes | Works for a full-tunnel client | Ambiguous on a host that must answer on its LAN address |
Den separate tabel er den eneste mulighed, der skalerer ud over ét undernet. Navngiv den én gang, og henvis derefter til den ved navn, så ingen skal huske et tal:
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 vpnAdresserne her er pladsholdere. Erstat LAN-præfikset, tunnelens gateway og enhedsnavnet fra din egen udrulning, før du kører noget.
Reglen skal også matche værten
En regel, der kun matcher LAN-præfikset, dækker videresendte pakker. Den dækker ikke trafik, som gatewayen selv starter, og den dækker ikke de svar, den sender tilbage til LAN-klienter, som bærer gatewayens LAN-adresse som kilde. De opslag falder igennem til main og kan stadig forlade gennem tunnelen.
Tilføj en anden regel for gatewayens egen LAN-adresse, eller udvid den første regel til et sæt, der omfatter begge. Rækkefølgen er vigtig: sæt den mere specifikke regel først, og kontroller resultatet med et opslag, der navngiver kilden eksplicit.
ip route get 203.0.113.9 from 192.168.50.1Hvis det rapporterer tunnel-enheden for en destination, der burde forblive lokal, er regelsættet forkert, uanset hvad tabellen indeholder.
NAT eller en rute på den anden side
VPN-serveren kender tunnelens undernet og intet andet. Pakker, der ankommer med en LAN-kildeadresse, har ingen returvej, medmindre nogen skaffer én, og der er præcis to måder at skaffe den på. At tilføje en rute for LAN-præfikset på serveren holder den oprindelige kilde synlig hele vejen igennem, hvilket et revideret design normalt ønsker. Maskering på gatewayen omskriver kilden til tunneladressen og kræver intet samarbejde fra serveren.
iptables -t nat -A POSTROUTING -s 192.168.50.0/24 -o tun0 -j MASQUERADEVælg NAT, når du ikke kontrollerer serveren og ikke kan tilføje ruter der. Vælg ruten på serversiden, når logfiler, adgangskontrol eller returvejssymmetri er vigtige, fordi maskering sletter den oprindelige adresse fra alt, hvad den anden side registrerer.
Uanset hvad skal videresendelse være aktiveret, og streng reverse-path-filtrering kan droppe svaret, når main ikke ville have valgt tunnelen for den kilde. Kontroller den effektive værdi, før du bebrejder tunnelen.
Få opdelingen til at overleve en genopkobling
Regler og ruter, der er tilføjet i hånden, forsvinder, når interfacet genskabes, og en forældet tabelpost kan overleve den session, der berettigede den. Læg tabelreglen, tunnelruten og maskeringsposten ind i klientens route-up script, og tøm tabellen i toppen af scriptet, så en gammel gateway ikke kan overleve ind i den nye session.
Kontroller fra begge ender: et opslag på gatewayen med LAN-kilden, og en rigtig anmodning fra en LAN-klient til en destination, der skal gennem tunnelen. En rute, der findes, men aldrig vælges, opfører sig præcis som ingen rute overhovedet, indtil du læser tællerne.