Wat OpenVPN se route-nopull werklik verhoed dat die bediener stoot
route-nopull laat vaar gestootde roetes en DHCP-opsies, nie die handskud nie. Kies tussen dit, pull-filter of niks, en voeg die roetes dan self by.
Jy plaas route-nopull in ’n kliëntprofiel om te verhoed dat die tonnel jou verstekroete insluk, en nou is die kantoor-subnet onbereikbaar terwyl die kliënt steeds sê hy is gekonnekteer. Beide waarnemings is waar, en niks het gefaal nie. Die vlag sê vir die kliënt om die roetes en DHCP-inskrywings oor te slaan wat die bediener stoot, wat ’n nouer opdrag is as wat die meeste mense verwag wanneer hulle dit byvoeg. Wat oorbly, is ’n werkende tonnel met geen mening oor watter bestemmings dit moet gebruik nie.
Daardie gaping is die hele besluit waaroor hierdie artikel gaan. Óf die bediener beskryf die netwerk, óf die kliënt doen dit, en die vlag gee daardie taak aan die kliënt sonder om enigiets daarvan vir jou te doen.
Wat die vlag by verbindingstyd afskakel
’n Kliënt wat OpenVPN trek, neem gewoonlik ná verifikasie ’n bondel van die bediener oor: roetes, ’n herleiding van die verstekpoort, DNS-bedieners en ’n paar instellingsriglyne. Met route-nopull van krag aanvaar die kliënt steeds die sessie, verifieer steeds sertifikate, onderhandel steeds sifers en keepalives, en bring steeds die koppelvlak op. Wat dit laat vaar, is die toepassing van gestootde route-reëls en gestootde dhcp-option-reëls, DNS ingesluit.
Die verwarring kom van ’n groen aanduiding langs ’n dooie toepassing. Die tonnel bestaan; die kartering van bestemmings na daardie tonnel nie. Niks in die kliënt se statuspaneel onderskei ‘gekonnekteer en roeteer’ van ‘gekonnekteer en onaktief’ nie, want uit die tonnel se oogpunt is albei dieselfde toestand.
Waarom ’n lewende tonnel steeds niks kan roeteer nie
Die koppelvlak verskyn met sy eie adres en, op ’n punt-tot-punt-skakel, dikwels niks meer spesifiek as ’n gasheerroete na die eweknie nie. ’n Privaat subnet word eers bereikbaar wanneer een of ander roete met die regte voorvoegsel na daardie koppelvlak wys, en met die stoot afgeskakel kom daardie roete nooit nie. Die afgelaaide profiel kan gewoonlik ook nie help nie, want dit is geskryf op die aanname dat die bediener presies hierdie inligting sou verskaf. Dis hoekom die koppelvlak gesond kan lyk terwyl die subnet donker bly.
Om die profiel te lees bewys dus baie min. Lees eerder die lopende toestand op die gekonnekteerde masjien:
ip addr show tun0
ip route show dev tun0
ip route get 10.20.5.10’n Adres sonder ’n subnetroete in die tweede opdrag is die kenmerk van hierdie probleem. Die derde opdrag beantwoord dan die vraag waaraan gebruikers regtig aandag gee, want dit rapporteer die koppelvlak wat die kern vir ’n spesifieke bestemming sou kies eerder as die lys wat jy gehoop het dit sou gebruik. As dit deur jou fisiese skakel antwoord, is die tonnel glad nie in die pad nie.
Naamoplossing faal om ’n verwante rede, nie ’n afsonderlike een nie. Gestootde dhcp-option DNS-inskrywings word deur dieselfde vlag oorgeslaan, so navrae vir interne gashere gaan na watter oplosser die plaaslike netwerk ook al verskaf het. Daardie oplosser het geen sone vir die kantoor nie, so die navraag faal of gee ’n openbare antwoord, en die mislukking lyk soos ’n bedienerprobleem terwyl dit ’n kliëntkonfigurasieprobleem is. Om ’n adres voor ’n naam te toets, is wat die twee skei.
Om tussen die vlag en ’n voorvoegselfilter te kies
Die twee opsies los verskillende vorms van dieselfde klag op, en sleg kies is wat die gekonnekteer-maar-nuttelose toestand veroorsaak. Die een vervang die gestootde beleid in sy geheel, terwyl die ander dit per voorvoegsel wysig. Die tabel gee die kort weergawe, en die paragraaf daarna dek die deel wat mense uitvang.
| Setting | What the client keeps | Reasonable when |
|---|---|---|
| no option | every pushed route and DHCP entry | the server's view of the network is correct |
route-nopull | the session, none of the pushed routing or DNS | you will write the full local policy yourself |
pull-filter | everything except lines matching your prefixes | the push is nearly right and one or two lines are wrong |
pull-filter is ’n voorvoegselpasder met drie werkwoorde, so dit kan ’n familie reëls aanvaar, dit stilweg ignoreer, of die verbinding heeltemal verwerp wanneer ’n voorvoegsel verskyn. Daardie laaste gedrag is die een wat die moeite werd is om te ken: ’n verwerpingsreël maak van ’n beleidsverskil ’n mislukte handskud eerder as ’n stille weglating. Die OpenVPN 2.6-handleiding lys die aanvaarde voorvoegsels en die presiese semantiek van elke werkwoord.
’n Algemene middeweg is om redirect-gateway alleen te verwerp en die kantoorroetes en DNS soos bedoel te laat aankom. Dit hou die stoot werkend vir die dele wat die bediener beter verstaan as jy, terwyl dit die een reël wat jou verstekroete sou oorneem verhoed.
Om roetes en ’n oplosser met die hand by te voeg
As jy die vlag behou, moet die profiel sê wat die bediener sou gesê het. Kliëntkant-route-riglyne word toegepas nadat die verbinding tot stand gekom het, so hulle werk saam met die vlag eerder as om daardeur geblokkeer te word. Sit hulle in die profiel, nie in ’n interaktiewe opdraglyn nie, anders sal die volgende herverbinding nie die werkende toestand herskep nie.
route-nopull
route 10.20.0.0 255.255.0.0
dhcp-option DNS 10.20.0.53Die DNS-reël staan in ’n ongemaklike posisie: dit is ’n kliëntkant-riglyn, maar sommige kliënte pas dit net deur die platform se DNS-integrasie toe, wat dit kan oorskryf wanneer die skakel verander. Op ’n systemd-gasheer is dit meer voorspelbaar om die oplosser direk op die tonnelkoppelvlak te stel as om te hoop die kliënt wen die prioriteitswedstryd:
resolvectl dns tun0 10.20.0.53
resolvectl domain tun0 ~corp.example.comDie roeteringsdomein maak net soveel saak soos die adres. Sonder dit kan navrae vir openbare name ook na die interne oplosser gestuur word, en enige interne oplosser wat rekursie weier, sal navigasie breek terwyl die privaat sone werkend bly. Met dit word net name onder daardie agtervoegsel na die tonneloplosser geroteer en alles anders volg die fisiese skakel.
Om die resultaat te toets: adres, naam en die buitenste pad
Drie toetse skei die moontlike mislukkings. Haal die privaat adres per IP, dan dieselfde gasheer per naam, dan ’n gewone openbare werf. ’n Werkende IP met ’n falende naam wys na die oplosser; ’n falende IP met ’n werkende naam wys na roetering; albei wat faal beteken gewoonlik die tonnel is nie in die pad nie.
Kyk dan na buite eerder as na binne. Die tonnel-eindpunt se eie roete moet die verandering oorleef, en enige blokkeringsfout moet tot die tonnel beperk word sonder om die eindpunt vas te vang. ’n Kliënt wat aanhou navigeer nadat die tonnel val, is ’n beleidsprobleem, nie ’n roeteringsprobleem nie, en dit sal nie in enige van die drie toetse hierbo wys nie.
Skryf die finale lys in die profiel se dokumentasie: die roetes, die oplosser, die domeine en die rede waarom elkeen bestaan. ’n Herverbinding wat dieselfde tabel herskep, is die enigste bewys dat die plaaslike beleid volledig is. As toepassings steeds faal met die tonnel op en al drie toetse geslaag, is die volgende plek om te kyk die gekonnekteer-maar-aflyn klas probleme eerder as sertifikate wat alreeds geverifieer het.