Bokse wat vir ’n LAN routeer en ook ’n VPN skakel, beland in dieselfde argument met hulleself: die tonnel wil die standaardroete besit, en die LAN het dit terug nodig. Wanneer OpenVPN verbind, kan dit ’n standaard deur die tonnel installeer of ’n paar half-standaarde, wat reg is vir ’n skootrekenaar en verkeerd vir ’n poort wat verwag dat bure vanaf sy LAN-adres antwoord. Die antwoord is nie om die VPN oor te slaan nie. Dit is om die twee besluite verskillende tabelle te gee.

Een standaardroete, twee eienaars

Deurgestuurde verkeer en plaaslik ontstane verkeer hoef nie dieselfde pad te neem nie. LAN-kliënte het die tonnel net vir die bestemmings nodig wat jy kies, terwyl die gasheer se eie bestuursessies en sy antwoorde aan daardie kliënte die LAN-standaard nodig het. Om albei in die hooftabel te meng, dwing ’n enkele antwoord op twee verskillende vrae af.

OpenVPN het ’n skakelaar vir presies dit. route-noexec verhoed dat die kliënt die hooftabel enigsins aanraak, en die waardes wat dit sou gebruik het, word aan ’n route-up-skrip beskikbaar gestel as route_vpn_gateway, dev en die koppelvlakadresse. Jy besluit dan watter tabel watter roete kry, in kode wat jy later kan lees.

Beleidstabel teenoor die hooftabel herskryf

ApproachWhat it buysWhat it costs
Separate table plus source ruleLAN traffic and host traffic keep independent defaultsEvery lookup now depends on rule order
Editing the main table onlyFewer moving parts on a single-purpose hostOne mistake takes the gateway offline entirely
Two half-default routesWorks for a full-tunnel clientAmbiguous on a host that must answer on its LAN address

Die aparte tabel is die enigste opsie wat verder as een subnet skaal. Gee dit een keer ’n naam en verwys dan daarby naam, sodat niemand ’n nommer hoef te onthou nie:

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

Die adresse hier is plekhouers. Vervang die LAN-voorvoegsel, die tonnelpoort en die toestelnaam uit jou eie ontplooiing voordat jy enigiets hardloop.

Die reël moet ook by die gasheer pas

’n Reël wat net by die LAN-voorvoegsel pas, dek deurgestuurde pakkette. Dit dek nie verkeer wat die poort self ontstaan nie, en dit dek nie die antwoorde wat dit aan LAN-kliënte terugstuur nie, wat die poort se LAN-adres as bron dra. Daardie opsoeke val deur na main en kan steeds deur die tonnel uitgaan.

Voeg ’n tweede reël by vir die poort se eie LAN-adres, of verbreed die eerste reël na ’n versameling wat albei insluit. Die volgorde maak saak: sit die meer spesifieke reël eerste, en kontroleer die resultaat met ’n opsoek wat die bron eksplisiet noem.

ip route get 203.0.113.9 from 192.168.50.1

As dit die tonneltoestel rapporteer vir ’n bestemming wat plaaslik moet bly, is die reëlstel verkeerd, ongeag wat die tabel bevat.

NAT of ’n roete aan die oorkant

Die VPN-bediener ken die tonnelsubnet en niks anders nie. Pakkette wat met ’n LAN-bronadres aankom, het geen terugpad tensy iemand een voorsien nie, en daar is presies twee maniere om dit te doen. Om ’n roete vir die LAN-voorvoegsel op die bediener by te voeg, hou die oorspronklike bron van punt tot punt sigbaar, wat ’n geouditeerde ontwerp gewoonlik wil hê. Vermomming op die poort herskryf die bron na die tonneladres en het geen samewerking van die bediener nodig nie.

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

Kies NAT wanneer jy nie die bediener beheer nie en nie roetes daar kan byvoeg nie. Kies die roete aan die bedienerkant wanneer logboeke, toegangsbeheer of terugpad-simmetrie saak maak, want vermomming vee die oorspronklike adres uit alles wat die oorkant aanteken.

In albei gevalle moet deurstuur geaktiveer wees, en streng terugpadfiltrering kan die antwoord laat val wanneer main nie die tonnel vir daardie bron sou gekies het nie. Kontroleer die effektiewe waarde voordat jy die tonnel blameer.

Laat die splitsing ’n herverbinding oorleef

Hand-bygevoegde reëls en roetes verdwyn wanneer die koppelvlak herskep word, en ’n verouderde tabelinskrywing kan die sessie wat dit geregverdig het, oorleef. Sit die tabelreël, die tonnelroete en die vermommingsinskrywing in die kliënt se route-up skrip, en spoel die tabel aan die bokant van die skrip uit sodat ’n ou poort nie in die nuwe sessie kan oorleef nie.

Verifieer van beide kante: ’n opsoek op die poort met die LAN-bron, en ’n werklike versoek van ’n LAN-kliënt na ’n bestemming wat deur die tonnel moet gaan. ’n Roete wat bestaan maar nooit gekies word nie, gedra hom presies soos geen roete nie totdat jy die tellers lees.

Verwante artikels