Rut ett LAN-undernett gjennom OpenVPN og behold standardruten
Behold LAN-standardruten mens ett undernett går gjennom tunnelen. Sammenlign en policytabell med endringer i hovedtabellen, og velg deretter NAT eller en rute på serversiden.
Bokser som ruter for et LAN og samtidig ringer opp en VPN, havner i samme diskusjon med seg selv: tunnelen vil eie standardruten, og LAN-et trenger den tilbake. Når OpenVPN kobler til, kan den installere en standardrute gjennom tunnelen eller et par halve standardruter, noe som er riktig for en bærbar PC og galt for en gateway der naboene forventer svar fra LAN-adressen. Svaret er ikke å hoppe over VPN-en. Svaret er å gi de to beslutningene forskjellige tabeller.
Én standardrute, to eiere
Videresendt trafikk og lokalt oppstått trafikk trenger ikke ta samme vei. LAN-klienter trenger bare tunnelen for destinasjonene du velger, mens vertens egne administrasjonsøkter og svarene til disse klientene trenger LAN-standardruten. Å blande begge i hovedtabellen tvinger ett svar på to forskjellige spørsmål.
OpenVPN har en bryter nettopp for dette. route-noexec hindrer klienten i å røre hovedtabellen i det hele tatt, og verdiene den ville brukt, eksporteres til et route-up skript som route_vpn_gateway, dev og grensesnittadressene. Deretter bestemmer du hvilken tabell som får hvilken rute, i kode du kan lese senere.
Policytabell kontra omskriving av 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 tabellen er det eneste alternativet som skalerer ut over ett undernett. Gi den navn én gang, og vis deretter til den ved navn, så ingen må huske et tall:
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 vpnAdressene her er plassholdere. Bytt ut LAN-prefikset, tunnelens gateway og enhetsnavnet fra din egen utrulling før du kjører noe.
Regelen må også passe verten
En regel som bare passer LAN-prefikset, dekker videresendte pakker. Den dekker ikke trafikk som gatewayen selv starter, og den dekker ikke svarene den sender tilbake til LAN-klienter, som bærer gatewayens LAN-adresse som kilde. Disse oppslagene faller til main og kan fortsatt gå ut gjennom tunnelen.
Legg til en andre regel for gatewayens egen LAN-adresse, eller utvid den første regelen til et sett som omfatter begge. Rekkefølgen er viktig: sett den mer spesifikke regelen først, og kontroller resultatet med et oppslag som navngir kilden eksplisitt.
ip route get 203.0.113.9 from 192.168.50.1Hvis det rapporterer tunnel-enheten for en destinasjon som skulle forbli lokal, er regelsettet feil uansett hva tabellen inneholder.
NAT eller en rute på den andre siden
VPN-serveren kjenner tunnelens undernett og ingenting annet. Pakker som ankommer med en LAN-kildeadresse, har ingen returvei med mindre noen skaffer en, og det er nøyaktig to måter å skaffe den på. Å legge til en rute for LAN-prefikset på serveren holder den opprinnelige kilden synlig hele veien, noe et revidert design vanligvis ønsker. Maskering på gatewayen skriver om kilden til tunneladressen og trenger ingen samarbeid fra serveren.
iptables -t nat -A POSTROUTING -s 192.168.50.0/24 -o tun0 -j MASQUERADEVelg NAT når du ikke kontrollerer serveren og ikke kan legge til ruter der. Velg ruten på serversiden når logger, tilgangskontroll eller returveisymmetri er viktig, fordi maskering sletter den opprinnelige adressen fra alt den andre siden registrerer.
Uansett må videresending være slått på, og streng reverse-path-filtrering kan droppe svaret når main ikke ville valgt tunnelen for den kilden. Kontroller den faktiske verdien før du gir tunnelen skylden.
Få oppdelingen til å overleve en gjenoppkobling
Regler og ruter som er lagt til for hånd, forsvinner når grensesnittet gjenskapes, og en foreldet tabelloppføring kan overleve økten som rettferdiggjorde den. Legg tabellregelen, tunnelruten og maskeringsoppføringen inn i klientens route-up skript, og tøm tabellen øverst i skriptet så en gammel gateway ikke kan overleve inn i den nye økten.
Kontroller fra begge ender: et oppslag på gatewayen med LAN-kilden, og en ekte forespørsel fra en LAN-klient til en destinasjon som skal gå gjennom tunnelen. En rute som finnes men aldri velges, oppfører seg nøyaktig som ingen rute i det hele tatt, helt til du leser tellerne.