Novirzi vienu LAN apakštīklu caur OpenVPN un saglabā noklusējuma maršrutu
Saglabā LAN noklusējuma maršrutu, kamēr viens apakštīkls iet caur tuneli. Salīdzini politikas tabulu ar galvenās tabulas izmaiņām, pēc tam izvēlies NAT vai maršrutu servera pusē.
Ierīces, kas maršrutē LAN un vienlaikus pieslēdzas VPN, nonāk tajā pašā strīdā pašas ar sevi: tunelis grib piederēt noklusējuma maršrutam, un LAN tas ir vajadzīgs atpakaļ. Kad OpenVPN pieslēdzas, tas var instalēt noklusējuma maršrutu caur tuneli vai pāri pus-noklusējuma maršrutu, kas ir pareizi portatīvajam datoram un nepareizi vārtejai, kuras kaimiņi gaida atbildes no tās LAN adreses. Atbilde nav izlaist VPN. Atbilde ir dot abiem lēmumiem dažādas tabulas.
Viens noklusējuma maršruts, divi īpašnieki
Pārsūtītā plūsma un lokāli radītā plūsma nav jāiet vienu ceļu. LAN klientiem tunelis vajadzīgs tikai izvēlētajiem galamērķiem, bet paša resursdatora pārvaldības sesijām un tā atbildēm šiem klientiem vajadzīgs LAN noklusējuma maršruts. Abus sajaucot galvenajā tabulā, viena atbilde tiek uzspiesta diviem dažādiem jautājumiem.
OpenVPN ir slēdzis tieši tam. route-noexec neļauj klientam vispār aiztikt galveno tabulu, un vērtības, ko tas būtu izmantojis, tiek eksportētas uz route-up skriptu kā route_vpn_gateway, dev un saskarnes adreses. Tad jūs izlemjat, kura tabula saņem kuru maršrutu, kodā, ko varēsiet izlasīt vēlāk.
Politikas tabula pret galvenās tabulas pārrakstīšanu
| 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 |
Atsevišķa tabula ir vienīgā iespēja, kas mērogojas tālāk par vienu apakštīklu. Piešķiriet tai nosaukumu vienreiz un pēc tam atsaucieties uz to pēc nosaukuma, lai nevienam nav jāatceras skaitlis:
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 vpnAdreses šeit ir aizstājēji. Pirms kaut ko palaist, aizstājiet LAN prefiksu, tuneļa vārteju un ierīces nosaukumu no sava izvietojuma.
Noteikumam jāsakrīt arī ar resursdatoru
Noteikums, kas sakrīt tikai ar LAN prefiksu, aptver pārsūtītās paketes. Tas neaptver plūsmu, ko rada pati vārteja, un neaptver atbildes, ko tā sūta atpakaļ LAN klientiem un kas kā avotu nes vārtejas LAN adresi. Šie meklējumi iekrīt main un joprojām var iziet caur tuneli.
Pievienojiet otru noteikumu pašas vārtejas LAN adresei vai paplašiniet pirmo noteikumu uz kopu, kas ietver abus. Secība ir svarīga: konkrētāko noteikumu lieciet pirmo un pārbaudiet rezultātu ar meklējumu, kas skaidri nosauc avotu.
ip route get 203.0.113.9 from 192.168.50.1Ja tas uzrāda tuneļa ierīci galamērķim, kam jāpaliek lokālam, noteikumu kopa ir nepareiza neatkarīgi no tā, ko tabula satur.
NAT vai maršruts otrā pusē
VPN serveris zina tuneļa apakštīklu un neko citu. Paketēm, kas pienāk ar LAN avota adresi, nav atgriešanās ceļa, ja vien kāds to nenodrošina, un to nodrošināt ir tieši divi veidi. Maršruta pievienošana LAN prefiksam serverī saglabā sākotnējo avotu redzamu no gala līdz galam, ko parasti vēlas auditēts dizains. Maskašana uz vārtejas pārraksta avotu uz tuneļa adresi un neprasa servera sadarbību.
iptables -t nat -A POSTROUTING -s 192.168.50.0/24 -o tun0 -j MASQUERADEIzvēlieties NAT, ja neuzraugāt serveri un nevarat tur pievienot maršrutus. Izvēlieties maršrutu servera pusē, ja svarīgi ir žurnāli, piekļuves kontrole vai atgriešanās ceļa simetrija, jo maskašana izdzēš sākotnējo adresi no visa, ko otrā puse reģistrē.
Jebkurā gadījumā pārsūtīšanai jābūt ieslēgtai, un stingra apgrieztā ceļa filtrēšana var nomest atbildi, ja main nebūtu izvēlējies tuneli šim avotam. Pārbaudiet faktisko vērtību, pirms vainojat tuneli.
Panāc, lai sadalījums pārdzīvo atkārtotu savienojumu
Ar roku pievienoti noteikumi un maršruti pazūd, kad saskarne tiek izveidota no jauna, un novecojis tabulas ieraksts var pārdzīvot sesiju, kas to attaisnoja. Ievietojiet tabulas noteikumu, tuneļa maršrutu un maskašanas ierakstu klienta route-up skriptā un notīriet tabulu skripta sākumā, lai veca vārteja nevarētu pārdzīvot jaunajā sesijā.
Pārbaudiet no abiem galiem: meklējumu uz vārtejas ar LAN avotu un reālu pieprasījumu no LAN klienta uz galamērķi, kuram jāiet caur tuneli. Maršruts, kas pastāv, bet nekad netiek izvēlēts, uzvedas tieši tāpat kā nekāds maršruts, līdz izlasāt skaitītājus.