Wat route-nopull fan OpenVPN de tsjinner eins tsjinhâldt om te stjoeren
route-nopull smyt pushte rûtes en DHCP-opsjes fuort, net de handshake. Kies tusken it, pull-filter of neat, en foegje de rûtes dan sels ta.
Jo hawwe route-nopull yn in kliïntprofyl set om te foarkommen dat de tunnel jo standertrûte opslokt, en no is it kantoarsubnet net berikber wylst de kliïnt noch altyd seit dat er ferbûn is. Beide observaasjes binne wier, en der is neat misgien. De flagge fertelt de kliïnt om de rûtes en DHCP-ynfieringen oer te slaan dy't de tsjinner pusht, wat in nauwere opdracht is as de measte minsken ferwachtsje as se it tafoegje. Wat oerbliuwt is in wurkjende tunnel sûnder miening oer hokker bestimmingen him brûke moatte.
Dy kleau is de hiele beslissing dêr't dit artikel oer giet. Of de tsjinner beskriuwt it netwurk, of de kliïnt docht it, en de flagge jout dy taak oan de kliïnt sûnder der eat fan foar jo te dwaan.
Wat de flagge by ferbinen útskeakelet
In OpenVPN-kliïnt dy't lûkt, nimt normaal nei autentikaasje in bondel fan de tsjinner oer: rûtes, in omlieding fan de standertgateway, DNS-tsjinners en in pear ôfstimdirektiven. Mei route-nopull yn krêft akseptearret de kliïnt noch altyd de sesje, ferifiearret noch altyd sertifikaten, ûnderhannelet noch altyd oer syfers en keepalives, en bringt noch altyd de ynterface omheech. Wat er fuortsmyt is it tapassen fan pushte route-rigels en pushte dhcp-option-rigels, DNS ynbegrepen.
De betizing komt fan in griene yndikator njonken in deade applikaasje. De tunnel bestiet; de ôfbylding fan bestimmingen nei dy tunnel net. Neat yn it statuspaniel fan de kliïnt ûnderskiedt «ferbûn en rûtet» fan «ferbûn en ynaktyf», want fanút it eachpunt fan de tunnel binne beide deselde tastân.
Wêrom't in libbene tunnel noch altyd neat rûte kin
De ynterface ferskynt mei syn eigen adres en hat op in punt-nei-punt-ferbining faak neat spesifyker as in hostrûte nei de partner. In privee-subnet wurdt pas berikber as in rûte mei it juste foarheaksel nei dy ynterface wiist, en mei it pushen útskeakele komt dy rûte nea oan. It downloade profyl kin meastentiids ek net helpe, want it is skreaun mei de oanname dat de tsjinner krekt dizze ynformaasje leverje soe. Dêrom kin de ynterface sûn lykje wylst it subnet tsjuster bliuwt.
It profyl lêze bewiist dus hiel lyts bytsje. Lês ynstee de rinnende tastân, op de ferbûne masine:
ip addr show tun0
ip route show dev tun0
ip route get 10.20.5.10In adres sûnder subnetrûte yn it twadde kommando is de hantekening fan dit probleem. It tredde kommando beantwurdet dan de fraach dêr't brûkers echt om jouwe, want it meldt de ynterface dy't de kernel foar in spesifike bestimming kieze soe yn stee fan de list dêr't jo op hope dat er brûke soe. As it antwurdet fia jo fysike keppeling, is de tunnel hielendal net yn it paad.
Nammebeslissing mislearret om in besibbe reden, net om in aparte. Pushte dhcp-option DNS-ynfieringen wurde troch deselde flagge oerslein, sadat fragen oer ynterne hosts nei de resolver gean dy't it lokale netwurk mar levere hat. Dy resolver hat gjin sône foar it kantoar, dus de fraach mislearret of jout in iepenbier antwurd, en de flater liket op in tsjinnerprobleem wylst it in kliïntkonfiguraasjeprobleem is. In adres foar in namme testen is wat de beide skiedt.
Kieze tusken de flagge en in foarheakselfilter
De beide opsjes lossen ferskate foarmen fan deselde klacht op, en in minne kar is wat de tastân ferbûn-mar-nutteloas makket. De iene ferfangt it pushte belied hielendal, wylst de oare it per foarheaksel bewurket. De tabel jout de koarte ferzje, en de paragraaf dêrnei behannelet it part dat minsken ferrast.
| 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 in foarheakselfergeliker mei trije tiidwurden, dus it kin in famylje rigels akseptearje, se stilwei negearje of de ferbining fuortendaliks wegerje as in foarheaksel ferskynt. Dat lêste gedrach is it weten wurdich: in wegeringsregel makket fan in beliedsmenienskip in mislearre handshake yn stee fan in stille weilietting. De OpenVPN 2.6-hantlieding listet de akseptearre foarheaksels en de krekte semantyk fan elk tiidwurd.
In gewoane middenwei is allinne redirect-gateway wegerje en de kantoarrûtes en DNS sa oankomme te litten as bedoeld. Dat hâldt it pushen oan it wurk foar de parten dy't de tsjinner better begrypt as jo, wylst it dy iene rigel foarkomt dy't jo standertrûte oernimme soe.
Rûtes en in resolver mei de hân tafoegje
As jo de flagge hâlde, moat it profyl sizze wat de tsjinner sein hie. Kliïntside-route-direktiven wurde tapast nei't de ferbining ta stân kommen is, dus se wurkje njonken de flagge yn stee fan der troch blokkearre te wurden. Set se yn it profyl, net yn in ynteraktive kommando-rigel, oars sil de folgjende werferbining de wurkjende tastân net werjaan.
route-nopull
route 10.20.0.0 255.255.0.0
dhcp-option DNS 10.20.0.53De DNS-rigel stiet op in ûngemaklike posysje: it is in kliïntside-direktive, mar guon kliïnten tapasse him allinne fia de DNS-ynjouting fan it platfoarm, dy't him oerskriuwe kin as de keppeling feroaret. Op in systemd-host is it foarsisberder om de resolver direkt op ’e tunnelinterface te setten as om te hoopjen dat de kliïnt de prioriteitswedstriid wint:
resolvectl dns tun0 10.20.0.53
resolvectl domain tun0 ~corp.example.comIt rûtedomein telt likefolle as it adres. Sûnder dat kinne fragen oer iepenbiere nammen ek nei de ynterne resolver stjoerd wurde, en elke ynterne resolver dy't rekursje wegert sil it browsen brekke wylst de priveesône wurkjen bliuwt. Dermei wurde allinne nammen ûnder dat efterheaksel nei de tunnelresolver rûte en folget al it oare de fysike keppeling.
It resultaat kontrolearje: adres, namme en it bûtenpaad
Trije tests skiede de mooglike flaters. Helje it privee-adres op mei IP, dan deselde host mei namme, dan in gewoane iepenbiere side. In wurkjend IP mei in mislearjende namme wiist nei de resolver; in mislearjend IP mei in wurkjende namme wiist nei it rûten; beide mislearje betsjut meastentiids dat de tunnel net yn it paad is.
Sjoch dan nei bûten yn stee fan nei binnen. De eigen rûte fan it tunnel-einpunt moat de feroaring oerlibje, en elke blokkearjende flater moat beheind wurde ta de tunnel sûnder it einpunt te fangen. In kliïnt dy't trochgiet mei browsen nei't de tunnel falt is in beliedsprobleem, net in rûteprobleem, en it sil yn gjinien fan de trije tests hjirboppe ferskine.
Skriuw de definitive list yn ’e dokumintaasje fan it profyl: de rûtes, de resolver, de domeinen en de reden wêrom't elk bestiet. In werferbining dy't deselde tabel werjaan is it iennige bewiis dat it lokale belied folslein is. As applikaasjes noch altyd mislearje mei de tunnel omheech en alle trije tests slagge, is it folgjende plak om te sykjen de klasse fan ferbûn-mar-offline-problemen, net sertifikaten dy't al ferifiearre binne.