Enkursigu unu LAN-subreton tra OpenVPN kaj konservu la defaŭltan itineron
Konservu la defaŭltan itineron de la LAN dum unu subreto veturas tra la tunelo. Komparu politikan tabelon kun redaktoj de la ĉefa tabelo, poste elektu NAT aŭ itineron ĉe la servila flanko.
Maŝinoj, kiuj enkursigas por LAN kaj samtempe alvokas VPN, finas en la sama disputo kun si mem: la tunelo volas posedi la defaŭltan itineron, kaj la LAN bezonas ĝin reen. Kiam OpenVPN konektiĝas, ĝi povas instali defaŭltan itineron tra la tunelo aŭ paron da duon-defaŭltoj, kio pravas por tekkomputilo kaj malpravas por pordego, kies najbaroj atendas respondojn el ĝia LAN-adreso. La respondo ne estas preterlasi la VPN-on. La respondo estas doni al la du decidoj malsamajn tabelojn.
Unu defaŭlta itinero, du posedantoj
Plusendita trafiko kaj loke originita trafiko ne devas sekvi la saman vojon. LAN-klientoj bezonas la tunelon nur por la celoj, kiujn vi elektas, dum la propraj administraj seancoj de la gastiganto kaj ĝiaj respondoj al tiuj klientoj bezonas la defaŭltan itineron de la LAN. Miksi ambaŭ en la ĉefa tabelo trudas unu solan respondon al du malsamaj demandoj.
OpenVPN havas ŝaltilon ĝuste por tio. route-noexec malhelpas la klienton tuŝi la ĉefan tabelon tute, kaj la valoroj, kiujn ĝi uzus, estas eksportitaj al route-up skripto kiel route_vpn_gateway, dev kaj la interfacaj adresoj. Poste vi decidas, kiun tabelon ricevas kiu itinero, en kodo kiun vi povos legi pli poste.
Politika tabelo kontraŭ reverkado de la ĉefa
| 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 |
La aparta tabelo estas la sola opcio, kiu skaliĝas preter unu subreto. Nomu ĝin unufoje, poste referencu ĝin per la nomo, por ke neniu memoru numeron:
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 vpnLa adresoj ĉi tie estas lokokupiloj. Anstataŭigu la LAN-prefikson, la tunelan pordegon kaj la aparatan nomon el via propra deplojo antaŭ ol lanĉi ion ajn.
La regulo devas kongrui ankaŭ kun la gastiganto
Regulo, kiu kongruas nur kun la LAN-prefikso, kovras plusenditajn pakaĵojn. Ĝi ne kovras trafikon, kiun la pordego mem originas, nek la respondojn, kiujn ĝi resendas al LAN-klientoj, kiuj portas la LAN-adreson de la pordego kiel sian fonton. Tiuj serĉoj falas al main kaj ankoraŭ povas eliri tra la tunelo.
Aldonu duan regulon por la propra LAN-adreso de la pordego, aŭ plivastigu la unuan regulon al aro, kiu inkluzivas ambaŭ. La ordo gravas: metu la pli specifan regulon unue, kaj kontrolu la rezulton per serĉo, kiu eksplicite nomas la fonton.
ip route get 203.0.113.9 from 192.168.50.1Se tio raportas la tunelan aparaton por celo, kiu devus resti loka, la aro da reguloj malpravas, sendepende de tio, kion la tabelo enhavas.
NAT aŭ itinero ĉe la malproksima flanko
La VPN-servilo konas la tunelan subreton kaj nenion alian. Pakaĵoj alvenantaj kun LAN-fonta adreso ne havas revenan vojon se iu ne provizas ĝin, kaj ekzistas precize du manieroj provizi ĝin. Aldoni itineron por la LAN-prefikso sur la servilo tenas la originalan fonton videbla de fino al fino, kion reviziita dezajno kutime volas. Maskado sur la pordego reverkas la fonton al la tunela adreso kaj bezonas neniun kunlaboron de la servilo.
iptables -t nat -A POSTROUTING -s 192.168.50.0/24 -o tun0 -j MASQUERADEElektu NAT kiam vi ne kontrolas la servilon kaj ne povas aldoni itinerojn tie. Elektu la itineron ĉe la servila flanko kiam protokoloj, alirkontrolo aŭ simetrio de la reva vojo gravas, ĉar maskado forviŝas la originalan adreson el ĉio, kion la malproksima flanko registras.
En ambaŭ kazoj plusendado devas esti ŝaltita, kaj strikta filtrado de la reva vojo povas forĵeti la respondon kiam main ne estus elektinta la tunelon por tiu fonto. Kontrolu la efektivan valoron antaŭ ol kulpigi la tunelon.
Igu la dividon postvivi rekonekton
Reguloj kaj itineroj aldonitaj permane malaperas kiam la interfaco estas rekreiata, kaj malnova tabela ero povas postvivi la seancon, kiu pravigis ĝin. Metu la tabelan regulon, la tunelan itineron kaj la maskadan eron en la skripton route-up de la kliento, kaj malplenigu la tabelon ĉe la supro de la skripto, por ke malnova pordego ne povu postvivi en la novan seancon.
Kontrolu de ambaŭ finoj: serĉo sur la pordego kun la LAN-fonto, kaj reala peto de LAN-kliento al celo, kiu devus trapasi la tunelon. Itinero, kiu ekzistas sed neniam estas elektata, kondutas precize kiel neniu itinero, ĝis vi legos la nombrilojn.