Ang dati mong default na ruta ay sadyang nananatili sa OpenVPN

Kumokonekta ka sa tunnel, pinapatakbo mo ang ip route, at ang orihinal na default na gateway ay nandoon pa rin. Ang susunod na iniisip mo ay nabigo ang kliyente na kunin ang ruta, kaya manu-mano mong tinatanggal ang default at tuluyang nawawala ang koneksyon. Dapat manatili ang entry na iyon. Sa redirect-gateway def1, naglalagay ang OpenVPN ng dalawang mas espesipikong ruta na lumalampas sa ordinaryong default sa halip na palitan ito. Nananatili ang lumang gateway at tumitigil sa pagdadala ng trapikong sinusubukan mo.

Ano talaga ang ginagawa ng def1

Idinadagdag ng flag ang 0.0.0.0/1 at 128.0.0.0/1, kapwa nakaturo sa tunnel. Kinukuha ng 0.0.0.0/1 ang bawat address na ang unang octet ay 0 hanggang 127, at kinukuha ng 128.0.0.0/1 ang 128 hanggang 255, kaya bawat destinasyong IPv4 ay may tugmang mas espesipiko kaysa sa lumang default. Ang haba ng prefix, hindi ang metric, ang nagtatakda kung aling ruta ang mananalo.

Sadyang iniwan ang orihinal na default sa puwesto. Hindi kailangang tandaan ng kliyente kung ano ang pinalitan nito, at hindi nito muling isinusulat ang rutang nagdadala ng sarili nitong koneksyon sa VPN server. Sa pagdiskonekta, inaalis nito ang dalawang kalahating ruta at bumabalik ang talahanayan sa dati.

Bakit /1 at hindi /0

Pinipili ng routing ang pinakamahabang tugmang prefix, hindi ang pinakamababang metric, kaya nananalo ang /1 sa /0 anuman ang sabihin ng metric ng default. Umiiral ang dalawang kalahati dahil ang isang /1 ay sumasaklaw lamang sa kalahati ng espasyo; kung 0.0.0.0/1 lamang ang naroroon, lahat mula 128.0.0.0 pataas ay sumusunod pa rin sa lumang default, na nagdudulot ng nakalilitong sintomas kung saan gumagana ang ilang site at hindi ang iba.

Walang nababago sa pagtaas o pagbaba ng metric ng lumang default, at ang default na may mas mababang metric sa ibang interface ay hindi rin nagnanakaw ng trapiko. Ang haba ng prefix ang unang nagtatakda, at tanging magkakaparehong prefix lamang ang bumabalik sa metric.

Basahin ang totoong routing table

Ang konektadong host ay maaaring magpakita ng lahat ng tatlong entry nang sabay, habang dinadala ng tunnel ang mga kalahati at nakalista pa rin ang orihinal na gateway. Ang mga address ay halimbawa lamang at hindi configuration na dapat kopyahin, dahil nag-iiba ang mga pangalan ng interface, topolohiya ng tunnel at karagdagang ruta ayon sa platform at kliyente.

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

Ang mahalaga ay ang ugnayan: dalawang partikular na kalahati sa ibabaw ng isang pangkalahatang default. Nananatili ang lumang linya ng gateway dahil walang pumalit dito.

Suriin ang rutang talagang tinatahak ng packet

Maaari pa ring manalo ang mas espesipikong ruta: isang ruta para sa pribadong range, isang lokal na subnet o ang sariling address ng VPN server ay mas mahaba kaysa /1. Kailangan ng tunnel ng panlabas na landas patungo sa server nito, at ang pagpapadala ng koneksyong iyon pabalik sa tunnel ay agad itong sisirain. Sa Linux, tanungin ang kernel sa halip na basahin ang talahanayan sa mata: ip route get kasama ang destinasyong mahalaga sa iyo ay naglilimbag ng napiling ruta, interface at source. Kung may naka-configure na policy routing, siyasatin din ang mga patakaran, dahil ang isang patakaran ay maaaring pumili ng ibang talahanayan bago konsultahin ang pangunahing talahanayan.

Kung bahagi lamang ng IPv4 ang mali ang ugali, tiyakin na na-install ang dalawang kalahati at pagkatapos ay maghanap ng eksepsyon na tumutugma sa pumapalyang destinasyon. Hindi solusyon ang pagtanggal ng lumang default, at inaalis nito ang rutang kailangan ng kliyente upang maayos na buwagin ang tunnel.

Ano ang hindi saklaw ng def1

Walang sinasabi ang dalawang IPv4 entry tungkol sa IPv6: ang host na may konektibidad na IPv6 ay patuloy na gumagamit ng sarili nitong default hanggang may mag-redirect sa pamilyang iyon nang hiwalay, kaya lumilitaw na lumalampas ang ilang trapiko sa tunnel sa isang dual-stack na network. Iba ang pagpapatupad ng ibang kliyente at network manager sa full-tunnel routing, at hindi magtutugma ang kanilang mga talahanayan. Ang pag-uugali ng def1 na inilarawan dito ay pag-aari ng dokumentadong flag ng OpenVPN, hindi ng bawat VPN sa makina.

Iba ang sinasagot ng kill switch: ano ang ginagawa ng makina kapag bumagsak ang tunnel. Ang precedence ng routing ang nagtatakda kung saan pumupunta ang trapiko habang nakaupo ang tunnel; hindi nito itinatakda ang gagawin ng firewall pagkatapos. Pagkakasunod-sunod ng trabaho: basahin ang talahanayan, tiyakin na may dalawang kalahati, patakbuhin ang ip route get para sa pumapalyang destinasyon, suriin ang mga patakaran, pagkatapos ay tingnan ang IPv6 nang hiwalay. Iwanan ang lumang default kung nasaan ito.