Bakit sinisira ng ikalawang VPN tunnel ang una?

Ang pag-install ng ikalawang VPN client para maabot ang isang customer network ay ang karaniwang paraan kung paano ito nagsisimula, at dumidilim ang unang tunnel habang parehong nag-uulat ng tagumpay ang dalawang client. Bawat client ay nag-install ng default na ruta, mas espesipiko ang pangalawa, at sinusunod na ito ng kernel para sa lahat maliban sa sariling panlabas na koneksyon ng unang tunnel. Walang nag-crash at walang maling profile. Isang ruta ang pumalit sa isa pa, at ang solusyon ay magpasya kung aling tunnel ang dapat magmay-ari ng default.

Ang sintomas: tahimik na nananalo ang ikalawang client

OpenVPN: hindi ginagawang muli ng opsyon na redirect-gateway def1 ang 0.0.0.0/0. Nagdaragdag ito ng 0.0.0.0/1 at 128.0.0.0/1: sama-sama nilang sinasaklaw ang bawat IPv4 address, at bawat prefix ay tinatalo ang payak na default sa haba. Nananatili sa table ang orihinal na default at hindi na ginagamit para sa ordinaryong trapiko, at pinipigilan ng host route patungo sa VPN server na mahuli ng tunnel ang sarili nitong panlabas na pakete. Ginagawa ito ng dalawang client, at ang pangalawa ay nag-install lang ng pares nito mamaya.

Kaya mukhang patay ang unang tunnel kaysa nadiskonekta. Nakataas ang interface nito, buhay ang control channel nito, at wala nang trapik ng application na nakakarating dito. Ang kabaligtaran na reklamo ay may parehong kulang na push: ang teleponong kumokonekta pero walang ipinapadala ay karaniwang kausap ang server na hindi kailanman nag-anunsyo ng redirect-gateway, kaya pinapanatili ng device ang sarili nitong default at nakakaabot lamang sa pool.

Kumuha ng snapshot ng ruta bago at pagkatapos kumonekta ang ikalawang client. Ang dalawang kalahating ruta na lumilitaw sa table ang buong pagbabago, at ipinapaliwanag nila ang dalawang reklamo. Wala nang iba sa table ang kailangang gumalaw para lumitaw ang sintomas. Kaya agad na naibabalik ng pagtanggal ng ikalawang client ang una.

Basahin kung aling tunnel ang tunay na nananalo

Huwag hulaan ang nanalo mula sa pagkakasunod-sunod ng pag-start ng mga client o sa icon sa tray. Itanong sa kernel kung aling ruta ang gagamitin nito para sa destinasyong labas ng dalawang pribadong network, at basahin ang interface na ibinabalik.

ip route show
ip route get 198.51.100.24
route print -4
Find-NetRoute -RemoteIPAddress 198.51.100.24

Ang unang dalawa ay sagot ng Linux at ang huling dalawa ay katumbas ng Windows. Patakbuhin ang mga ito habang nakataas ang dalawang tunnel, pagkatapos idiskonekta ang isa at patakbuhin muli. Ang pagkakaiba ng dalawang output ang katotohanang kailangan mo bago pumili ng solusyon, at mas mabilis ito kaysa sa pagbasa ng log ng alinman sa mga client.

Itala ang resulta, kasama ang pangalan ng interface at ang prefix na tumugma. Ang ticket na nagsasabing sinira ng ikalawang VPN ang una ay paglalarawan ng sintomas, hindi pahayag tungkol sa routing na maaaring pagbasehan ng aksyon. Ginagawa itong katotohanan ng paghahanap na maaaring ulitin ng susunod na inhinyero sa isang utos.

Windows: pigilan ang isang profile na magmay-ari ng default

Nag-iimbak ang Windows ng mga naka-save na profile, at pinapayagan ng built-in na client na ang isa ay umasa sa iba para awtomatikong umangat ang una kapag nag-dial ang pangalawa. Ang profile na huling kumonekta ay may tendensiyang magpanatili ng default, kaya ang praktikal na may-ari ay ang huling dial at hindi ang una. Bigyan ang bawat profile ng sarili nitong push routes at i-on ang split tunneling para sa isa na hindi dapat magmay-ari ng default.

Set-VpnConnection -Name "Contoso" -SplitTunneling $true
rasdial Contoso

Binabago ito ng split tunneling: ang mga prefix na itinutulak ng server lang ang pumapasok sa table, na nag-iiwan ng default sa unang tunnel. Nabigo pa rin ang disenyo kung itinutulak ng dalawang server ang isang default na ruta, dahil panalo ang huling koneksyon at wala sa client side ang makakabago nito. Ayusin ang push sa server side o tanggapin ang isang may-ari.

Ang mga profile na na-trigger ng app ay ibang feature at dapat malaman: ang profile ng Windows ay maaaring magsimula kapag tumakbo ang pinangalanang executable, na ang mga filter ng trapiko ang nagpapasya kung ano ang dadalhin. Ito ay setting ng profile at hindi patakaran ng firewall, at nilulutas nito ang ibang problema kaysa sa hidwaan sa default na ruta.

Linux: ilayo ang ikalawang tunnel sa pangunahing table

Ang pagpapatakbo ng dalawang instance ng openvpn --config sa isang makina ay naglalagay sa dalawang client sa parehong table, at tatlong opsyon ang naghihiwalay sa kanila nang tumataas ang paghihiwalay. Ang pinakamagaan ay pigilan ang ikalawang client na mag-edit ng table, gamit ang route-nopull at tahasang ruta, o script na route-up na nag-i-install lang ng nilalayon mo. Pagkatapos ay dinadala ng ikalawang tunnel ang eksaktong prefix na pinangalanan mo at wala nang iba. Pagkatapos ay ikaw ang magpapasya kung saan pupunta ang bawat prefix sa halip na matuklasan ito mamaya.

Ang policy routing ay ang gitnang opsyon. Pumipili ang isang panuntunan ng hiwalay na table para sa isang source address o firewall mark, at dinadala ng table na iyon ang ruta ng ikalawang tunnel. Ang reverse-path filtering ang bitag dito, dahil ang sagot na dumarating sa ibang interface kaysa sa pipiliin ng table ay itinatapon, kaya suriin ang setting na rp_filter bago magpasya na sira ang tunnel.

ip rule add from 10.44.7.0/24 table 100
ip route add default dev tun1 table 100
sysctl net.ipv4.conf.all.rp_filter

Ang mga namespace ng network ang pinakamabigat at pinakamalinis na opsyon. Simulan ang ikalawang client sa loob ng ip netns, bigyan ito ng veth pair, at pumasok sa namespace na iyon para gamitin ito. Nawawala ang interference dahil bawat namespace ay may sariling table sa halip na maghati sa isa, na sulit ang dagdag na setup kapag ang dalawang tunnel ay kailangang manatiling nakataas nang linggo.

Bawat application, at ang pagkakadena bilang hiwalay na problema

Minsan isang programa lang ang dapat gumamit ng ikalawang tunnel. Sa Linux, naaabot ng policy routing ayon sa user, cgroup o port ang resultang iyon, at ang isang destinasyon ay maaaring i-pin sa isang interface nang hindi man lang hinahawakan ang default. Ang application na nagpupin ng socket nito sa isang interface ay hindi kailanman kumukonsulta sa routing table, kaya ang launcher ay patuloy na makakagamit ng pisikal na adapter hanggang sa mapili ang address sa sariling setting nito.

Ang pagkakadena ay ibang operasyon kaysa sa pagpapatakbo ng dalawang tunnel nang magkatabi. Ang pagkadena ng A sa ibabaw ng B ay nangangahulugang ang address ng panloob na server ay dapat maabot mula sa loob ng panlabas na tunnel. Hindi rin dapat ipalagay ng panlabas na client na pagtagas ang naka-encrypt na pakete ng panloob na client. Ang isang client sa loob ng virtual machine ang magaspang ngunit maaasahang bersyon; ang dalawa sa isang host ay nangangailangan ng gawaing routing sa itaas at panlabas na landas patungo sa panloob na server na hindi kailanman pumapasok sa panloob na tunnel.

Isulat ang may-ari ng default, ang listahan ng prefix na dinadala ng bawat tunnel, at ang landas ng DNS. Ang tatlong katotohanang iyon ay ginagawang paghahanap ang susunod na insidente sa halip na imbestigasyon.