route-gateway is net redirect-gateway: wat der echt feroaret
De opsje jout allinnich in folgjende hop foar rûtes dy’t OpenVPN ynstallearret. It fuortheljen skeakelet in trochdrukte folsleine tunnel net út, en de reparaasje heart by de trochferwizing.
Jo tunnel komt omheech, it privee subnet antwurdet, en gewoan blêdzjen ferdwynt noch hieltyd yn ’e VPN, ek al hat immen de gateway-rigel út it profyl weilitten. Dy kombinaasje is de fingerôfdruk fan de ferkearde rjochtline dy’t bewurke is. Wat fuorthelle waard, joech de klient in folgjende hop foar rûtes dy’t er ynstallearret; wat trochgie mei ferkear te fangen, kaam fan earne oars en waard troch de tsjinner drukt. Dekking en folgjende hop binne aparte taken, en mar ien fan beide beslút oft iepenbiere bestimmingen de tunnel brûke.
De rigel dy’t jo fuorthellen wie in folgjende hop, gjin beliedsskeakel
Elke rûte dy’t de klient ynstallearret hat in gateway-adres nedich om nei te wizen, en de gateway-rjochtline is wêr’t dat adres wei komt as in rûte sels gjin ien neamt. Wiskje it en dy rûtes hawwe neat om oan te heakjen, sadat se of net ynstallearre wurde of op in paad lânje dat nearne hinne liedt. It privee subnet is krekt wat sa’n rûte droech.
Underwilens hat it gedrach dat oerlibbe in oare auteur: in trochferwizingsopsje yn it trochdrukte blok, dy’t gewoan útgeand ferkear neffens syn flaggen de tunnel yn ferpleatst. It fuortheljen fan de gateway skeakelet it net út en ferswakket it net. It resultaat is it slimste fan beide tastannen, mei iepenbier ferkear dat noch hieltyd fongen wurdt en de privee bestimming dy’t de tunnel rjochtfeardige no ûnberikber. Dêrom feroaret de twadde bewurking, yn deselde geast makke, ek neat.
Fjouwer hefbomen, fjouwer ferskillende taken
Fjouwer rjochtlinen wurde yn dizze diskusje trochinoar sitearre, en mar ien fan harren regelet dekking, dat wol sizze hokker bestimmingen oft hielendal troch de tunnel rûte wurde. In twadde set de folgjende hop dy’t rûtes brûke, in tredde ynstallearret ien foarheaksel, en in fjirde smyt alles fuort dat de tsjinner drukt hat, ynklusyf de privee rûtes dy’t de útdraging nedich hat. De tabel sortearret se nei wat in behearder besiket te feroarjen, net nei namme, want de nammen feroarsaakje de betizing. Behannelje se as fjouwer aparte besluten en kies dejinge dy’t jo echt weromdraaie wolle.
Yn ’e praktyk komme alle fjouwer faak yn ien trochdrukt blok, rigel nei rigel, wat se dielen fan ien ynstelling lykje lit. Dat binne se net, en de OpenVPN-referinsje dokumintearret se om dy reden as ferskillende meganismen. Utfine hokker beslút jo weromdraaie is it wurk; de bewurking is ien rigel.
| 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 |
Filterje de trochdrukte rigel, hâld de folgjende hop
As de dekking dêr’t jo beswier tsjin meitsje as in trochdrukte opsje komt, is it inge antwurd dy opsje by namme te negearjen en de rest fan it trochdrukte blok ûnoantaast te litten. Skreaun as filter liket it op de rigel hjirûnder, en it heart yn it profyl fan de troffen klient, net yn de tsjinnerkonfiguraasje.
pull-filter ignore "redirect-gateway"Engte is it punt. Om’t it filter in tekstfoarheaksel ferliket, past in koarter patroan ek op de folgjende-hop-rjochtline, wat krekt de ynformaasje stript dêr’t de privee rûtes fan ôfhinklik binne en de oarspronklike flater yn in nij gewaad werhellet. In filter wurket ek allinnich op trochdrukte opsjes, sadat it nea in lykweardige rigel oanrekket dy’t lokaal skreaun of troch in netwurkbehearder oplein is. Ferbynje jo dêrnei op ’e nij, want in libbene sesje beoardielet net op ’e nij wat de tsjinner drukt hat.
Lês de syktocht, net de tabel
Nei it werladen fan it profyl, freegje de kernel wêr’t twa bestimmingen echt hinne soene: ien binnen it privee foarheaksel en ien op it iepenbiere ynternet. In folsleine dump fan ’e haadtabel is hurder te lêzen en makliker ferkeard te lêzen, want in rûte kin bestean en dochs ferlieze tsjin in spesifyker oerienkomst. By beliedsrûtering hearre de regel, de tabel en it boarne-adres ek by de kontrôle.
ip route get 10.40.7.25
ip route get 203.0.113.77
ip rule showDe def1-fariant fertsjinnet fertroudheid, want it lit de âlde standertynfier sichtber wylst in pear heale standerten de syktocht winne. In 0.0.0.0/0-rigel yn ’e útfier bewiist dus op himsels neat. De syktocht beantwurdet de fraach dy’t de list allinnich liket te beantwurdzjen.
DNS, IPv6 en de privee rûte moatte noch altyd wurkje
Ien IPv4-trochferwizing wegerje seit neat oer de resolver, sadat in trochdrukte DNS-opsje trochgean kin mei fragen de tunnel yn te stjoeren wylst de rûtes korrekt lykje. In IPv6-standert kin itselde dwaan foar in adresfamylje dy’t de IPv4-kontrôle nea oanrekke hat. Beide hawwe in eksplisite beslissing nedich ynstee fan in oanname. Befêstigje dêrnei dat de privee tsjinst noch antwurdet, want in split-tunnel dy’t syn privee rûte ferlern hat is gjin split-tunnel, it is in stikken ien.
Ien breder ark fertsjinnet in warskôging: route-nopull smyt elke trochdrukte rûte en elke trochdrukte DNS-opsje fuort, wat de folsleine tunnel grif stopet en like grif de privee rûtes brekt dêr’t de útdraging fan ôfhinklik is, dus it is in folle gruttere hammer as in nammeffilter rjochte op ien opsje. Kontrolearje de privee bestimming, in iepenbiere bestimming en de resolver nei elke feroaring, en beskôgje in foltôge hânskodding as bewiis fan neat oars as de hânskodding.