Dalawang gateway, isang VPN: bakit pinipili ng OpenVPN ang maling uplink

Dalawang uplink, isang tunnel, at lumalabas ang trapiko sa hindi mo pinili. Naabot ang mga pribadong subnet, iniuulat ng log ang matagumpay na koneksyon, at ang metered na link ang nagdadala nito. Walang binabanggit na gateway sa output ng OpenVPN, dahil kailanman ay walang pinili ang kliyente. Nagbukas ito ng socket patungo sa malayong address at hinayaan ang kernel na magpasya kung paano maaabot ang address na iyon.

Ang address ng tunnel ay hindi ang dulo

May dalawang magkaibang landas sa bawat session. Dinadala ng panlabas na landas ang naka-encrypt na transport patungo sa pampublikong address ng server. Dinadala ng panloob na landas ang lahat ng itinutulak ng server papasok sa tunnel, at ang mga patakaran ng routing ng isa ay walang epekto sa isa.

Pinapangalanan ng remote na entry sa profile ang panlabas na destinasyon, kaya iyon ang address na dapat i-pin. Ito rin ang value na nagbabago kapag naresolba ang hostname nang iba o naglilista ang profile ng maraming remote.

Hanapin ang address na aktwal na tinawagan ng kliyente

Basahin ang buhay na socket sa halip na ang configuration file. Ipinapakita ng socket table ang peer na aktwal na konektado ng proseso, at iyon ang value na dapat tugunan ng exception. Maaaring i-edit ang profile pagkatapos magsimula ang session, at ang socket ang tanging ebidensya kung ano ang tinawagan:

ss -tunp | grep -i openvpn
journalctl -u openvpn-client@work --no-pager | grep -i "Peer Connection Initiated"

Binabanggit ng linya ng log ang address at port ng peer sa oras ng koneksyon. Kung hindi ito tugma sa profile, may nagsusulat muli ng destinasyon sa harap ng kliyente bago magsimula ang koneksyon.

Suriin din ang pamilya ng address. Maaaring kumonekta ang dual-stack na profile sa IPv6 habang ang exception mo ay sumasaklaw lamang sa IPv4, at sumusunod ang trapiko sa ibang patakaran kaysa sa isinulat mo. Ganoon din sa proxy na sumasagot sa ngalan ng dulo. Pareho ang resulta ng dalawang kaso: gumaganang tunnel habang walang ginagawa ang ruta mo.

I-pin ang dulo at basahin ang pagkakasunod-sunod ng patakaran

Ang host route ay mas tiyak kaysa sa anumang default route. Kaya ang /32 para sa address ng peer ay nananalo sa loob ng table na naglalaman nito. Ang karaniwang anyo ay tahasang binabanggit ang gateway at device:

ip route add 203.0.113.40/32 via 192.168.10.1 dev eth0

Tumutulong lang ang rutang iyon kung maaabot ng lookup ang table na iyon. Sinusuri ang mga patakaran ng patakaran ayon sa pagkakasunod-sunod at ang unang tugma ang magpapasya, kaya ang patakarang nagpapadala ng lahat sa ikalawang table ay lumalampas sa host route mo sa main. Basahin ang mga patakaran bago ipagpalagay na ang ruta ay may awtoridad:

ip rule show
ip route get 203.0.113.40

Itanong ang ikalawang utos gamit ang parehong source address o marka na ginagamit ng kliyente kapag nakasalalay ang patakaran sa mga iyon. Iniulat nito ang rutang pipiliin ng kernel, na ebidensya tungkol sa lookup at hindi patunay na ginagamit ng buhay na socket ang landas na iyon.

Kapag gumalaw ang dulo

Ang hostname na nare-resolve sa maraming address ay nagpapawalang-bisa ng permanenteng /32 sa sandaling magbago ang sagot. Ang profile na may maraming remote na linya ay may parehong problema, dahil maaaring mapunta ang kliyente sa alinman sa mga iyon. I-refresh ang ruta mula sa sariling lifecycle hooks ng kliyente sa halip na idagdag ito nang manu-mano. Ang script na up na nagbabasa ng napagkasunduang peer at nag-i-install ng host route ay nagpapanatili ng exception na nakaayon sa realidad, at tinatanggal ito ng katugmang script na down.

Itala ang refresh sa parehong lugar ng natitirang configuration ng routing ng host. Ang rutang umiiral lamang hanggang sa susunod na reboot ay isang pagsubok, hindi isang pagwawasto.

Panatilihing hiwalay ang panloob na patakaran

Ang paglipat ng panlabas na landas ay hindi nagbibigay ng access sa bagong pribadong subnet at hindi binabago kung aling mga destinasyon ang itinutulak ng server papasok sa tunnel. Pinipili ng ruta ng mas mababang layer ang wire; pinipili ng mga itinulak na ruta kung ano ang pumapasok sa tunnel. Ang paghihiwalay ng dalawang desisyong iyon ang gumagawa ng paghahati na mahulaan.

Kung layunin lamang na ilayo ang naka-encrypt na transport mula sa metered na link, iwanan ang default route at idagdag ang nag-iisang host exception. Ang pagpapalit ng default route ng buong makina para ilipat ang isang koneksyon ng VPN ay sisira sa bawat iba pang application sa host.

Kumpirmahin ang resulta sa dalawang independiyenteng obserbasyon: ang lokal na address at device ng socket, at ang rutang nare-resolve ng pribadong destinasyon. Kapag pareho silang tugma sa intensyon mo, totoo ang paghahati. Sinasaklaw ng manwal ng OpenVPN 2.6 ang mga opsyon sa remote at lokal na pagbubuklod na nagtatakda kung aling address ang tinatawagan ng kliyente.