Jūsu vecais noklusējuma maršruts apzināti pārdzīvo OpenVPN

Jūs pievienojat tuneli, izpildāt ip route, un sākotnējā noklusējuma vārteja joprojām ir tur. Nākamā doma ir tāda, ka klients nav pārņēmis maršrutu, tāpēc jūs manuāli izdzēšat noklusējuma maršrutu un pilnībā zaudējat savienojumu. Šim ierakstam ir jāpaliek. Ar redirect-gateway def1 OpenVPN instalē divus konkrētākus maršrutus, kas pārspēj parasto noklusējuma maršrutu, tā vietā lai to aizstātu. Vecā vārteja paliek un pārstāj pārvadāt satiksmi, kuru jūs testējāt.

Ko def1 patiešām dara

Karodziņš pievieno 0.0.0.0/1 un 128.0.0.0/1, abi vērsti uz tuneli. 0.0.0.0/1 aptver katru adresi, kuras pirmais oktets ir no 0 līdz 127, un 128.0.0.0/1 aptver no 128 līdz 255, tāpēc katram IPv4 galamērķim ir konkrētāka atbilstība nekā vecajam noklusējumam. Kurš maršruts uzvar, nosaka prefiksa garums, nevis metrika.

Sākotnējā noklusējuma atstāšana vietā ir apzināta. Klientam nav jāatceras, ko tas aizstāja, un tas nepārraksta maršrutu, kas pārvadā tā paša savienojumu ar VPN serveri. Atvienojot tas noņem divus pusmaršrutus, un tabula atgriežas iepriekšējā stāvoklī.

Kāpēc /1, nevis /0

Maršrutēšana izvēlas garāko atbilstošo prefiksu, nevis zemāko metriku, tāpēc /1 pārspēj /0 neatkarīgi no tā, ko saka noklusējuma metrika. Abas puses pastāv tāpēc, ka viens /1 aptver tikai pusi telpas; ja ir tikai 0.0.0.0/1, viss no 128.0.0.0 uz augšu joprojām seko vecajam noklusējumam, kas rada mulsinošu simptomu, kad dažas vietnes strādā, bet citas ne.

Vecā noklusējuma metrikas palielināšana vai samazināšana neko nemaina, un noklusējuma maršruts ar zemāku metriku citā saskarnē arī nezog satiksmi. Vispirms izšķir prefiksa garums, un tikai vienādi prefiksi atgriežas pie metrikas.

Izlasiet īstu maršrutēšanas tabulu

Pievienots resursdators var parādīt visus trīs ierakstus uzreiz, kur tunelis pārvadā puses un sākotnējā vārteja joprojām ir sarakstā. Adreses ir piemēri, nevis konfigurācija, ko kopēt, jo saskarņu nosaukumi, tuneļa topoloģija un papildu maršruti atšķiras atkarībā no platformas un klienta.

default via 192.168.50.1 dev wlan0
0.0.0.0/1 via 10.8.0.1 dev tun0
128.0.0.0/1 via 10.8.0.1 dev tun0

Svarīga ir attiecība: divas konkrētas puses virs viena vispārīga noklusējuma. Vecās vārtejas rinda paliek, jo nekas to nav aizstājis.

Pārbaudiet, kuru maršrutu pakete patiešām izmanto

Konkrētāki maršruti joprojām var uzvarēt: maršruts privātam diapazonam, vietējam apakštīklam vai paša VPN servera adrese ir garāks par /1. Tunelim vajadzīgs ārējs ceļš uz savu serveri, un šī savienojuma sūtīšana atpakaļ tunelī to uzreiz salauztu. Linux sistēmā jautājiet kodolam, nevis lasiet tabulu ar aci: ip route get ar interesējošo galamērķi izdrukā izvēlēto maršrutu, saskarni un avotu. Ja ir konfigurēta politikas balstīta maršrutēšana, pārbaudiet arī noteikumus, jo noteikums var izvēlēties citu tabulu, pirms tiek aplūkota galvenā.

Ja nepareizi uzvedas tikai daļa IPv4, pārliecinieties, ka ir instalētas abas puses, un pēc tam meklējiet izņēmumu, kas atbilst neveiksmīgajam galamērķim. Vecā noklusējuma dzēšana nav risinājums, un tā noņem maršrutu, kas klientam vajadzīgs, lai tīri izjauktu tuneli.

Ko def1 neaptver

Divi IPv4 ieraksti neko nepasaka par IPv6: resursdators ar IPv6 savienojumu turpina izmantot savu noklusējumu, līdz kaut kas šo saimi novirza atsevišķi, tāpēc dubultsteka tīklā daļa satiksmes izskatās, ka apiet tuneli. Citi klienti un tīkla pārvaldnieki pilna tuneļa maršrutēšanu ievieš citādi, un viņu tabulas nesakritīs. Šeit aprakstītā def1 uzvedība pieder OpenVPN dokumentētajam karodziņam, nevis katram VPN šajā mašīnā.

Avārijas slēdzis atbild uz citu jautājumu: ko mašīna dara, kad tunelis krīt. Maršrutu prioritāte nosaka, kur satiksme iet, kamēr tunelis ir augšā; tā nenosaka, ko pēc tam dara ugunsmūris. Darbu secība: izlasiet tabulu, pārliecinieties, ka abas puses pastāv, izpildiet ip route get neveiksmīgajam galamērķim, pārbaudiet politikas noteikumus un pēc tam atsevišķi apskatiet IPv6. Atstājiet veco noklusējumu tur, kur tas ir.