Jūsų senasis numatytasis maršrutas tyčia išlieka po OpenVPN

Prijungiate tunelį, paleidžiate ip route, o pradinis numatytasis šliuzas vis dar ten. Kita mintis — klientas neperėmė maršruto, todėl ištrinate numatytąjį rankiniu būdu ir visiškai netenkate ryšio. Tas įrašas turi likti. Su redirect-gateway def1 OpenVPN įdiegia du tikslesnius maršrutus, kurie lenkia įprastą numatytąjį, o ne jį pakeičia. Senas šliuzas lieka ir nustoja nešti srautą, kurį tikrinote.

Ką def1 iš tikrųjų daro

Vėliavėlė prideda 0.0.0.0/1 ir 128.0.0.0/1, abu nukreiptus į tunelį. 0.0.0.0/1 apima kiekvieną adresą, kurio pirmasis oktetas yra nuo 0 iki 127, o 128.0.0.0/1 apima nuo 128 iki 255, todėl kiekviena IPv4 paskirties vieta turi konkretesnį atitikimą nei senasis numatytasis. Kuris maršrutas laimi, lemia prefikso ilgis, o ne metrika.

Palikti pradinį numatytąjį vietoje yra sąmoninga. Klientui nereikia atsiminti, ką jis pakeitė, ir jis neperrašo maršruto, kuriuo eina jo paties ryšys su VPN serveriu. Atjungus jis pašalina du pusinius maršrutus, ir lentelė grįžta į buvusią būseną.

Kodėl /1, o ne /0

Maršrutizavimas renkasi ilgiausią atitinkantį prefiksą, o ne mažiausią metriką, todėl /1 nugali /0, kad ir ką sakytų numatytojo metrika. Abi pusės egzistuoja todėl, kad vienas /1 dengia tik pusę erdvės; kai yra tik 0.0.0.0/1, viskas nuo 128.0.0.0 ir aukščiau vis dar eina senuoju numatytuoju, o tai sukelia klaidinančią simptomą, kai vieni puslapiai veikia, o kiti ne.

Senojo numatytojo metrikos padidinimas ar sumažinimas nieko nekeičia, o numatytasis su mažesne metrika kitame sąsajos taške taip pat nepavagia srauto. Pirmiausia lemia prefikso ilgis, o metrikos prašoma tik kai prefiksai lygūs.

Perskaitykite tikrą maršrutizavimo lentelę

Prijungtas mazgas gali parodyti visus tris įrašus iš karto, kai tunelis neša puses, o pradinis šliuzas vis dar sąraše. Adresai yra pavyzdžiai, o ne kopijuojama konfigūracija, nes sąsajų pavadinimai, tunelio topologija ir papildomi maršrutai skiriasi priklausomai nuo platformos ir kliento.

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

Svarbiausia yra santykis: dvi konkrečios pusės virš vieno bendro numatytojo. Senojo šliuzo eilutė lieka, nes niekas jos nepakeitė.

Patikrinkite, kurį maršrutą paketas tikrai pasirenka

Konkretesni maršrutai vis tiek gali laimėti: maršrutas privačiam diapazonui, vietiniam potinkliui arba paties VPN serverio adresas yra ilgesnis nei /1. Tuneliui reikia išorinio kelio į savo serverį, o šio ryšio siuntimas atgal į tunelį jį iš karto sulaužytų. Linux sistemoje klauskite branduolio, o ne skaitykite lentelę akimis: ip route get su dominančia paskirties vieta atspausdina pasirinktą maršrutą, sąsają ir šaltinį. Jei sukonfigūruotas politikos pagrindu veikiantis maršrutizavimas, peržiūrėkite ir taisykles, nes taisyklė gali pasirinkti kitą lentelę prieš pasiekiant pagrindinę.

Jei netinkamai elgiasi tik dalis IPv4, patvirtinkite, kad įdiegtos abi pusės, ir tada ieškokite išimties, atitinkančios nepavykstančią paskirties vietą. Senojo numatytojo trynimas nėra sprendimas, ir jis pašalina maršrutą, kurio klientui reikia švariai išardyti tunelį.

Ko def1 neapima

Du IPv4 įrašai nieko nesako apie IPv6: mazgas su IPv6 ryšiu toliau naudoja savo numatytąjį, kol kažkas tą šeimą nukreips atskirai, todėl dvigubo kamino tinkle dalis srauto atrodo apeinanti tunelį. Kiti klientai ir tinklo tvarkyklės viso tunelio maršrutizavimą įgyvendina kitaip, ir jų lentelės nesutaps. Čia aprašytas def1 elgesys priklauso dokumentuotai OpenVPN vėliavėlei, o ne kiekvienam VPN šiame kompiuteryje.

Avarinis jungiklis atsako į kitą klausimą: ką kompiuteris daro, kai tunelis krenta. Maršrutų prioritetas lemia, kur srautas eina, kol tunelis pakeltas; jis nelemia, ką vėliau darys užkarda. Darbo tvarka: perskaitykite lentelę, patvirtinkite, kad abi pusės yra, paleiskite ip route get nepavykstančiai paskirties vietai, patikrinkite politikos taisykles ir tada atskirai pažiūrėkite į IPv6. Palikite senąjį numatytąjį ten, kur jis yra.