route-gateway is nie redirect-gateway nie: wat werklik verander
Die opsie lewer net 'n volgende sprong vir roetes wat OpenVPN installeer. Om dit te verwyder skakel nie 'n gestootde vol tonnel af nie, en die regstelling hoort by die herleiding.
Jou tonnel kom op, die private subnet antwoord, en gewone blaaiery verdwyn steeds in die VPN in, al het iemand die gateway-lyn uit die profiel geskrap. Daardie kombinasie is die vingerafdruk van die verkeerde richtlijn wat geredigeer is. Wat verwyder is, het die kliënt 'n volgende sprong gegee vir roetes wat dit installeer; wat aanhou om verkeer vas te vang, het van elders gekom en is deur die bediener gestoot. Dekking en volgende sprong is aparte take, en net een van hulle besluit of openbare bestemmings die tonnel gebruik.
Die lyn wat jy verwyder het, was 'n volgende sprong, nie 'n beleidskakelaar nie
Elke roete wat die kliënt installeer, het 'n gateway-adres nodig om na te wys, en die gateway-richtlijn is waar daardie adres vandaan kom wanneer 'n roete nie self een noem nie. Skrap dit en daardie roetes het nêrens om aan te heg nie, so hulle installeer óf nie, óf beland op 'n pad wat nêrens heen lei. Die private subnet is juis wat so 'n roete gedra het.
Intussen het die gedrag wat oorleef het 'n ander outeur: 'n herleidingsopsie in die gestootde blok, wat gewone uitgaande verkeer volgens sy vlae in die tonnel skuif. Om die gateway te verwyder skakel dit nie af nie en verswak dit nie. Die resultaat is die slegste van beide toestande, met openbare verkeer wat steeds vasgevang word en die private bestemming wat die tonnel geregverdig het, nou onbereikbaar. Dit is waarom die tweede wysiging, in dieselfde gees gemaak, ook niks verander nie.
Vier hefbome, vier verskillende take
Vier richtlijnen word in hierdie bespreking deurmekaar aangehaal, en net een daarvan beheer dekking, dit wil sê watter bestemmings hoegenaamd deur die tonnel gestuur word. 'n Tweede stel die volgende sprong wat roetes gebruik, 'n derde installeer een enkele voorvoegsel, en 'n vierde gooi alles weg wat die bediener gestoot het, insluitend die private roetes wat die ontplooiing nodig het. Die tabel sorteer hulle volgens wat 'n administrateur probeer verander eerder as volgens naam, want dit is die name wat die verwarring veroorsaak. Beskou dit as vier afsonderlike besluite en kies die een wat jy werklik wil omkeer.
In die praktyk kom al vier dikwels in een gestootde blok, lyn vir lyn, wat hulle soos dele van een enkele instelling laat lyk. Hulle is nie, en die OpenVPN-verwysing dokumenteer hulle om daardie rede as afsonderlike meganismes. Om vas te stel watter besluit jy omkeer, is die taak; die wysiging is een lyn.
| What you are trying to change | Directive that decides it | What it leaves alone |
|---|---|---|
| Which destinations use the tunnel | redirect-gateway | Per-prefix routes and resolver choice |
| The next hop a pushed route points at | route-gateway | Coverage of public destinations |
| One reachable prefix | route | Every other destination, default path included |
| All pushed routing and DNS at once | route-nopull | Nothing, which is the problem |
Filtreer die gestootde lyn, hou die volgende sprong
As die dekking waarteen jy beswaar maak as 'n gestootde opsie aankom, is die eng reaksie om daardie opsie by naam te ignoreer en die res van die gestootde blok ongeskonde te laat. As 'n filter geskryf, lyk dit soos die lyn hieronder, en dit hoort in die profiel van die betrokke kliënt, nie in die bedienerkonfigurasie nie.
pull-filter ignore "redirect-gateway"Engheid is die punt. Omdat die filter 'n teksvoorvoegsel vergelyk, pas 'n korter patroon ook op die volgende-sprong-richtlijn, wat juis die inligting stroop waarop die private roetes staatmaak en die oorspronklike fout in 'n nuwe gewaad herhaal. 'n Filter werk ook net op gestootde opsies, so dit raak nooit 'n ekwivalente lyn wat plaaslik geskryf of deur 'n netwerkbestuurder opgelê is nie. Herverbind daarna, want 'n lewende sessie herevalueer nie wat die bediener gestoot het nie.
Lees die opsoek, nie die tabel nie
Nadat jy die profiel herlaai het, vra die kernel waar twee bestemmings werklik sou gaan: een binne die private voorvoegsel en een op die openbare internet. 'n Volle storting van die hooftabel is moeiliker om te lees en makliker om verkeerd te lees, want 'n roete kan bestaan en steeds teen 'n meer spesifieke passing verloor. Onder beleidsroetering hoort die reël, die tabel en die bronadres ook by die kontrole.
ip route get 10.40.7.25
ip route get 203.0.113.77
ip rule showDie def1-variant verdien vertroudheid, want dit laat die ou verstekinskrywing sigbaar terwyl 'n paar half-verstekke die opsoek wen. 'n 0.0.0.0/0-lyn in die uitset bewys dus niks op sigself nie. Die opsoek beantwoord die vraag wat die lys net skynbaar beantwoord.
DNS, IPv6 en die private roete moet steeds werk
Om een IPv4-herleiding te weier sê niks oor die resolver nie, so 'n gestootde DNS-opsie kan steeds navrae in die tonnel instuur terwyl die roetes korrek lyk. 'n IPv6-verstek kan dieselfde doen vir 'n adresfamilie wat die IPv4-kontrole nooit geraak het nie. Albei het 'n eksplisiete besluit nodig eerder as 'n aanname. Bevestig dan dat die private diens steeds antwoord, want 'n split-tonnel wat sy private roete verloor het, is nie 'n split-tonnel nie, dit is 'n stukkende een.
Een wyer instrument verdien 'n waarskuwing: route-nopull gooi elke gestootde roete en gestootde DNS-opsie weg, wat beslis die vol tonnel stop en net so beslis die private roetes breek waarvan die ontplooiing afhanklik is, so dit is 'n veel groter hamer as 'n naamfilter wat op een opsie gemik is. Kontroleer die private bestemming, 'n openbare bestemming en die resolver ná enige verandering, en beskou 'n voltooide handdruk as bewys van niks behalwe die handdruk.