Ano ang tunay na hinaharang ng route-nopull ng OpenVPN sa pagtulak ng server

Inilagay mo ang route-nopull sa isang profile ng kliyente para hindi lamunin ng tunnel ang iyong default na ruta, at ngayon hindi maabot ang subnet ng opisina habang sinasabi pa rin ng kliyente na konektado ito. Parehong totoo ang mga obserbasyon, at walang nabigo. Sinasabi ng flag sa kliyente na laktawan ang mga ruta at entry ng DHCP na itinutulak ng server, isang mas makitid na tagubilin kaysa inaasahan ng karamihan kapag idinadagdag ito. Ang natitira ay isang gumaganang tunnel na walang opinyon kung aling mga destinasyon ang dapat gumamit nito.

Ang puwang na iyon ang buong desisyon na tinatalakay ng artikulong ito. Alinman sa server ang naglalarawan ng network, o ang kliyente, at ibinibigay ng flag ang gawaing iyon sa kliyente nang walang ginagawa kahit ano para sa iyo.

Ano ang pinapatay ng flag kapag kumokonekta

Ang kliyenteng OpenVPN na humihila ay karaniwang tumatanggap ng bundle mula sa server pagkatapos ng pagpapatunay: mga ruta, pag-redirect ng default na gateway, mga server ng DNS, at ilang direktiba sa pag-tune. Kapag may bisa ang route-nopull, tinatanggap pa rin ng kliyente ang session, bineberipika pa rin ang mga sertipiko, nakikipagkasundo pa rin sa mga cipher at keepalive, at itinataas pa rin ang interface. Ang inihuhulog nito ay ang paggamit ng mga itinulak na linyang route at mga itinulak na linyang dhcp-option, kasama ang DNS.

Ang kalituhan ay galing sa berdeng indicator sa tabi ng patay na aplikasyon. Umiiral ang tunnel; ang pagmamapa ng mga destinasyon sa tunnel na iyon ay wala. Walang anuman sa panel ng status ng kliyente ang nagtatangi ng «konektado at nagruruta» sa «konektado at walang ginagawa», dahil mula sa pananaw ng tunnel pareho silang estado.

Bakit ang buhay na tunnel ay maaaring wala pa ring maruta

Lumilitaw ang interface kasama ang sarili nitong address at, sa point-to-point na link, kadalasan walang anumang mas tiyak kaysa sa host route patungo sa peer. Nagiging maabot lamang ang pribadong subnet kapag may rutang tumuturo sa interface na iyon na may tamang prefix, at kapag patay ang pagtulak hindi kailanman dumarating ang rutang iyon. Karaniwang hindi rin makakatulong ang na-download na profile, dahil isinulat ito sa pag-aakalang ibibigay ng server ang eksaktong impormasyong ito. Kaya naman mukhang malusog ang interface habang madilim pa rin ang subnet.

Kaya napakakaunting pinapatunayan ng pagbasa ng profile. Basahin sa halip ang tumatakbong estado, sa konektadong makina:

ip addr show tun0
ip route show dev tun0
ip route get 10.20.5.10

Ang address na walang subnet route sa ikalawang utos ay ang pirma ng problemang ito. Sinasagot ng ikatlong utos ang tanong na talagang pinapahalagahan ng mga gumagamit, dahil iniuulat nito ang interface na pipiliin ng kernel para sa isang partikular na destinasyon sa halip na ang listahang inaasahan mong gagamitin. Kung sumasagot ito sa pamamagitan ng iyong pisikal na link, wala talaga ang tunnel sa landas.

Nabibigo ang paglutas ng pangalan dahil sa kaugnay na dahilan, hindi hiwalay. Ang mga itinulak na entry ng dhcp-option DNS ay nilalaktawan ng parehong flag, kaya ang mga query para sa mga panloob na host ay napupunta sa anumang resolver na ibinigay ng lokal na network. Walang zone para sa opisina ang resolver na iyon, kaya nabibigo ang query o nagbabalik ng pampublikong sagot, at ang pagkabigo ay mukhang problema ng server samantalang problema ito ng konfigurasyon ng kliyente. Ang pagsubok ng address bago ang pangalan ang naghihiwalay sa dalawa.

Pagpili sa pagitan ng flag at ng filter ng prefix

Ang dalawang opsyon ay nag-aayos ng magkaibang hugis ng parehong reklamo, at ang maling pagpili ang gumagawa ng estadong konektado-pero-walang-silbi. Pinapalitan ng isa ang itinulak na patakaran nang buo, habang binabago ito ng isa ayon sa prefix. Ibinibigay ng talahanayan ang maikling bersyon, at ang talata pagkatapos nito ay sumasaklaw sa bahaging nakakagulat sa mga tao.

Ang pull-filter ay isang tagatugma ng prefix na may tatlong pandiwa, kaya maaari nitong tanggapin ang isang pamilya ng mga linya, balewalain ang mga ito nang tahimik, o tanggihan nang tuluyan ang koneksyon kapag may lumitaw na prefix. Ang huling pag-uugali ang dapat malaman: ginagawang bigong handshake ng tuntunin ng pagtanggi ang hindi pagkakasundo sa patakaran sa halip na tahimik na paglalaktaw. Inililista ng manwal ng OpenVPN 2.6 ang mga tinatanggap na prefix at ang eksaktong kahulugan ng bawat pandiwa.

Ang karaniwang gitnang landas ay tanggihan lamang ang redirect-gateway at hayaang dumating ang mga ruta ng opisina at DNS ayon sa layunin. Pinapanatili nitong gumagana ang pagtulak para sa mga bahaging mas nauunawaan ng server kaysa sa iyo, habang pinipigilan ang nag-iisang linyang sasakop sa iyong default na ruta.

Pagdaragdag ng mga ruta at resolver nang manwal

Kung pananatilihin mo ang flag, kailangang sabihin ng profile ang sasabihin sana ng server. Ang mga direktibang route sa panig ng kliyente ay inilalapat pagkatapos maitatag ang koneksyon, kaya gumagana sila kasama ng flag sa halip na harangan nito. Ilagay ang mga ito sa profile, hindi sa interaktibong command line, kung hindi ay hindi muling gagawin ng susunod na reconnect ang gumaganang estado.

route-nopull
route 10.20.0.0 255.255.0.0
dhcp-option DNS 10.20.0.53

Ang linyang DNS ay nasa awkward na posisyon: ito ay direktiba sa panig ng kliyente, ngunit ang ilang kliyente ay inilalapat lamang ito sa pamamagitan ng integrasyon ng DNS ng platform, na maaaring mag-overwrite nito kapag nagbago ang link. Sa isang host na systemd, ang pagtatakda ng resolver nang direkta sa interface ng tunnel ay mas mahuhulaan kaysa sa pag-asang mananalo ang kliyente sa paligsahan ng priyoridad:

resolvectl dns tun0 10.20.0.53
resolvectl domain tun0 ~corp.example.com

Ang domain ng pagruruta ay kasinghalaga ng address. Kung wala ito, ang mga query para sa mga pampublikong pangalan ay maaari ring ipadala sa panloob na resolver, at anumang panloob na resolver na tumatanggi sa recursion ay sisirain ang pagba-browse habang patuloy na gumagana ang pribadong zone. Kapag mayroon ito, tanging mga pangalan sa ilalim ng suffix na iyon ang iruruta sa resolver ng tunnel at ang lahat ay sumusunod sa pisikal na link.

Pagsuri sa resulta: address, pangalan at ang panlabas na landas

Tatlong pagsubok ang naghihiwalay sa mga posibleng pagkabigo. Kunin ang pribadong address sa pamamagitan ng IP, pagkatapos ang parehong host sa pamamagitan ng pangalan, pagkatapos ang isang ordinaryong pampublikong site. Ang gumaganang IP na may bigong pangalan ay tumuturo sa resolver; ang bigong IP na may gumaganang pangalan ay tumuturo sa pagruruta; kung pareho ang nabigo, karaniwang wala ang tunnel sa landas.

Pagkatapos ay tumingin palabas sa halip na paloob. Ang sariling ruta ng dulo ng tunnel ay dapat mabuhay sa pagbabago, at anumang nakaharang na pagkabigo ay dapat limitado sa tunnel nang hindi nahuhuli ang dulo. Ang kliyenteng patuloy na nagba-browse pagkatapos bumagsak ang tunnel ay problema ng patakaran, hindi ng pagruruta, at hindi ito lilitaw sa alinman sa tatlong pagsubok sa itaas.

Isulat ang huling listahan sa dokumentasyon ng profile: ang mga ruta, ang resolver, ang mga domain at ang dahilan kung bakit umiiral ang bawat isa. Ang reconnect na muling gumagawa ng parehong talahanayan ay ang tanging ebidensya na kumpleto ang lokal na patakaran. Kung nabibigo pa rin ang mga aplikasyon habang nakataas ang tunnel at pumasa ang lahat ng tatlong pagsubok, ang susunod na titingnan ay ang klase ng problemang konektado-pero-offline at hindi ang mga sertipikong na-verify na.