OpenVPN redirect-gateway: ano ang ginagawa ng bawat flag sa mga ruta

Kumonekta gamit ang redirect-gateway sa profile, at ang default na ruta ng makina mo ay maaaring mawala, mahati sa dalawa, o manatili kung saan mismo ito naroon, depende sa mga flag na walang sinumang nagbabasa nang dalawang beses. Binabago ng opsyon ang estado ng routing at wala nang iba, kaya ang tanging mapagkakatiwalaang ebidensya ng ginawa nito ay ang table na inilagay ng client pagkatapos. Ang sumusunod ay ang table pagkatapos ng koneksyon, ang rutang nagpapanatili ng buhay ng mismong tunnel, at ang trapikong IPv6 na hindi kailanman inaangkin ng direktiba na sakop nito. Bawat hakbang ay utos na maaari mong patakbuhin sa client habang buhay ang tunnel.

Ano ang ginagawa ng bawat flag sa default na ruta

Nang walang anumang flag, tinatanggal ng opsyon ang ordinaryong default na ruta at inilalagay ang tunnel sa puwesto nito, kaya nawawala ang lumang gateway sa table habang aktibo ang koneksyon. Idagdag ang def1 at nananatili sa listahan ang default na iyon, at dalawang mas makitid na ruta ang gumagawa ng trabaho. Idagdag ang bypass-dhcp at nabubuhay din ang rutang DHCP, na mahalaga sa network kung saan kailangan pa ring maabot ng client ang lokal na DHCP server. Ang listahan ng flag sa pahina ng manwal ng OpenVPN 2.6 ay sapat na maikli upang basahin nang isang beses, at binabago ng bawat entry kung aling mga ruta ang mapupunta sa table.

Ang itinulak na opsyon ay ganoon din ang kilos pagdating, kaya maaaring walang laman ang profile ng client habang ganap na nakaredirect ang table. Normal iyon: ipinadala ng server ang mga flag, inilapat ito ng client, at hindi kailanman binanggit ng lokal na file ang direktiba. Kapag ang push ay mukhang walang ginagawa, suriin ang filter sa gilid ng client na tumatanggap o nagtatapon ng mga hinila na opsyon, dahil ang itinapong opsyon ay walang error sa alinmang panig.

Nanalo ang def1 sa pagiging tiyak nang hindi hinahawakan ang default mo

Dalawang kalahating default na ruta ang magkasamang sumasaklaw sa espasyong IPv4, 0.0.0.0/1 at 128.0.0.0/1. Ang bawat isa ay mas tiyak kaysa sa 0.0.0.0/0, kaya pinipili sila ng paghahanap habang nananatili ang tunay na default sa table para sa anumang humihingi ng pinakamababang tiyak na tugma.

Basahin ang table at hindi ang profile, dahil ang table lang ang nagpapakita kung alin sa mga kaso ang kinalalagyan mo. Sapat ang dalawang linya upang makilala sila:

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

Pansinin ang interface at metric sa bawat linya, hindi lang ang destinasyon. Ang default na nakaturo sa tunnel at ang pares ng kalahating default na nakaturo sa tunnel ay naglalarawan ng parehong layunin at nabibigo nang iba kapag bumagsak ang tunnel, dahil may natitirang fallback sa isang kaso. Itala ang dalawang field sa tala ng pagbabago. Ang natitirang fallback ay minsan ang nagpapanatili ng malayong sesyon nang sapat na tagal upang ayusin ang tunnel, at ito rin ang naglalabas ng trapiko kapag ang layunin ay buong tunnel.

Panatilihing maabot ang dulo ng tunnel

Kailangan ng client ng rutang patungo sa malayong dulo ng tunnel na hindi dumadaan sa tunnel mismo. Inilalagay ng OpenVPN ang host route na iyon bago baguhin ang anupaman, at maaaring tanggalin ito ng manu-manong pag-edit ng ruta o ng pangalawang VPN client. Ang sintomas pagkatapos ay koneksyong nagsasabing konektado at pagkatapos ay walang pinapasa.

Tanungin ang kernel kung aling interface ang gagamitin nito para sa address ng endpoint habang buhay ang tunnel. Dapat banggitin ng sagot ang pisikal na interface at ang gateway nito, hindi kailanman tun0:

ip route get 198.51.100.20

Kung ibinabalik ng paghahanap na iyon ang aparato ng tunnel, dinadala ng tunnel ang sarili nitong transport at babagsak ito sa sandaling may packet na kailangang lumabas. Mahalaga pa rin dito ang mga lokal na prefix, pangalawang adapter at routing na batay sa patakaran, kaya ang redirect na gumagana sa malinis na laptop ay maaaring mabigo sa host na may management interface at dalawang default. Karaniwang sinisisi ang profile sa ginawa ng plano ng address.

Ginagamit pa rin ng trapikong IPv6 ang sarili nitong table

Ang pag-redirect ng IPv4 ay hindi gumagalaw sa IPv6, at ang dalawang pamilya ay binabago ng magkaibang flag. Sa host na may dobleng stack at gumaganang v6 default, ang trapikong v4 ay maaaring lubusang nasa loob ng tunnel habang bawat destinasyong may kakayahang v6 ay lumalabas sa pisikal na link. Ang host na mukhang tama sa isang table ay naglalabas sa isa pa.

Suriin ang v6 table pagkatapos kumonekta sa halip na ipalagay na sinakop ito ng tunnel. Dinadala ng direktiba ang mga flag ng pamilya ng address dahil mismo dito, at ang profile na naglalaktaw sa kanila ay nagmamana ng ginagawa ng platform bilang default:

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

Patunayan kung aling interface ang ginagamit ng isang application

Ang konektadong estado ay hindi pagharang, at ang pagbabago ng ruta ay hindi kill switch. Kung kailangang huminto ang direktang trapiko kapag bumagsak ang tunnel, ang patakarang iyon ay nasa firewall at kailangan ng sarili nitong pagsubok.

Subukan ang landas na talagang tinatahak ng isang application sa halip na ang landas na inilalarawan ng profile. Humingi muna ng ruta, pagkatapos iugnay ang isang kahilingan sa bawat interface nang salitan at ihambing ang iniuulat ng malayong panig:

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

Kung parehong address ang ibinabalik ng dalawang kahilingan, hindi ginagamit ng application ang tunnel kahit sinasabi ng routing table na dapat. Kung tanging ang kahilingang nakatali sa tunnel ang nagtagumpay, ang pisikal na landas ay sinasala para sa destinasyong iyon at ginagawa ng tunnel ang hiniling mo. Isulat ang mga flag, ang mga naka-install na ruta, ang paghahanap ng endpoint at ang dalawang resulta ng labasan sa tala ng pagbabago, upang mamanahin ng susunod na tao ang mga katotohanan sa halip na screenshot.