OpenVPN redirect-gateway: kion ĉiu flago faras al la itineroj

Konektiĝu kun redirect-gateway en la profilo, kaj la defaŭlta itinero de via maŝino povas malaperi, duiĝi aŭ resti ĝuste tie, kie ĝi estis, depende de flagoj, kiujn neniu legas dufoje. La opcio ŝanĝas nur la stiran staton kaj nenion alian, do la sola fidinda pruvo pri tio, kion ĝi faris, estas la tabelo, kiun la kliento instalis poste. Tio, kio sekvas, estas la tabelo post konekto, la itinero, kiu tenas la tunelon mem viva, kaj la IPv6-trafiko, kiun la direktivo neniam asertas kovri. Ĉiu paŝo estas komando, kiun vi povas ruli sur la kliento dum la tunelo funkcias.

Kion ĉiu flago faras al la defaŭlta itinero

Sen iu ajn flago, la opcio forigas la ordinaran defaŭltan itineron kaj metas la tunelon en ĝian lokon, do la malnova kluzo malaperas el la tabelo dum la konekto funkcias. Aldonu def1 kaj tiu defaŭlto restas listigita, dum du pli mallarĝaj itineroj faras la laboron. Aldonu bypass-dhcp kaj ankaŭ la DHCP-itinero postvivas, kio gravas en reto, kie la kliento ankoraŭ devas atingi la lokan DHCP-servilon. La flaglisto sur la manuala paĝo de OpenVPN 2.6 estas sufiĉe mallonga por unufoja legado, kaj ĉiu ero ŝanĝas, kiuj itineroj finiĝos en la tabelo.

Puŝita opcio kondutas same, kiam ĝi alvenas, do la klienta profilo povas enteni nenion dum la tabelo aspektas plene alidirektita. Tio estas normala: la servilo sendis la flagojn, la kliento aplikis ilin, kaj la loka dosiero neniam menciis la direktivon. Kiam puŝo ŝajnas fari nenion, kontrolu la klientflankan filtrilon, kiu akceptas aŭ forĵetas eltiritajn opciojn, ĉar forĵetita opcio ne kaŭzas eraron ĉe iu ajn flanko.

def1 venkas per specifeco sen tuŝi vian defaŭlton

Du duonaj defaŭltaj itineroj kune kovras la IPv4-spacon, 0.0.0.0/1 kaj 128.0.0.0/1. Ĉiu estas pli specifa ol 0.0.0.0/0, do serĉo preferas ilin dum la reala defaŭlto restas en la tabelo por ĉio, kio petas la malplej specifan kongruon.

Legu la tabelon anstataŭ la profilon, ĉar nur la tabelo montras, en kiu el tiuj kazoj vi estas. Du linioj sufiĉas por distingi ilin:

ip route show default
ip route show | grep -E '^(0\.0\.0\.0/1|128\.0\.0\.0/1)'

Notu la interfacon kaj la metrikon en ĉiu linio, ne nur la celon. Defaŭlto montranta al la tunelo kaj paro da duonaj defaŭltoj montrantaj al la tunelo priskribas la saman intencon kaj malsukcesas malsame, kiam la tunelo falas, ĉar en unu kazo la rezerva vojo ankoraŭ ekzistas. Skribu ambaŭ kampojn en la ŝanĝnoton. Postvivanta rezervo estas foje tio, kio tenas malproksiman sesion viva sufiĉe longe por ripari la tunelon, kaj ĝi ankaŭ estas tio, kio likas trafikon, kiam la intenco estis plena tunelo.

Tenu la tunel-finpunkton atingebla

La kliento bezonas itineron al la malproksima fino de la tunelo, kiu mem ne iras tra la tunelo. OpenVPN instalas tiun gastigan itineron antaŭ ol ŝanĝi ion ajn alian, kaj mana itinera redakto aŭ dua VPN-kliento povas forpreni ĝin. La simptomo poste estas konekto, kiu raportas sin konektita kaj poste pasas nenion.

Demandu la kernon, kiun interfacon ĝi uzus por la finpunkta adreso dum la tunelo funkcias. La respondo devas nomi la fizikan interfacon kaj ĝian kluzon, neniam tun0:

ip route get 198.51.100.20

Se tiu serĉo redonas la tunelan aparaton, la tunelo portas sian propran transporton kaj kolapsos tuj kiam paketo devos eliri. Lokaj prefiksoj, dua adaptilo kaj politika itinero ankoraŭ gravas ĉi tie, do alidirektado, kiu funkcias sur pura tekkomputilo, povas malsukcesi sur gastiganto kun administra interfaco kaj du defaŭltoj. Kutime oni kulpigas la profilon pri tio, kion faris la adresa plano.

IPv6-trafiko daŭre uzas sian propran tabelon

Alidirekti IPv4 lasas IPv6 trankvila, kaj la du familioj estas ŝanĝataj de malsamaj flagoj. Sur duobla-staka gastiganto kun funkcianta v6-defaŭlto, v4-trafiko povas sidi plene ene de la tunelo dum ĉiu v6-kapabla celo eliras tra la fizika ligo. Gastiganto, kiu aspektas ĝuste en unu tabelo, likas en la alia.

Kontrolu la v6-tabelon post konekto anstataŭ supozi, ke la tunelo kovris ĝin. La direktivo portas adresfamiliajn flagojn ĝuste pro tio, kaj profilo, kiu preterlasas ilin, heredas tion, kion la platformo faras defaŭlte:

ip -6 route show default
ip -6 route get 2001:db8::10

Pruvu, kiun interfacon aplikaĵo uzas

Konektita stato ne estas blokado, kaj itinera ŝanĝo ne estas haltigilo. Se rekta trafiko devas halti, kiam la tunelo malsukcesas, tiu politiko loĝas en la fajroŝirmilo kaj bezonas sian propran teston.

Testu la vojon, kiun aplikaĵo vere prenas, anstataŭ la vojon, kiun la profilo priskribas. Petu unue la itineron, poste ligu peton al ĉiu interfaco laŭvice kaj komparu, kion raportas la malproksima flanko:

ip route get 203.0.113.10
curl -s --interface tun0 https://ifconfig.me
curl -s --interface eth0 https://ifconfig.me

Se ambaŭ petoj redonas la saman adreson, la aplikaĵo ne uzas la tunelon, kvankam la stiranta tabelo diras, ke ĝi devus. Se nur la peto ligita al la tunelo sukcesas, la fizika vojo estas filtrita por tiu celo kaj la tunelo faras tion, kion vi petis. Skribu la flagojn, la instalitajn itinerojn, la finpunktan serĉon kaj ambaŭ elirajn rezultojn en la ŝanĝregistron, por ke la sekva persono heredi faktojn anstataŭ ekrankopion.