Parehong server IP, dalawang landas: pagmamarka ng panlabas na daloy ng OpenVPN

Ang dating proteksyon sa loop ay rutang host: ipadala ang trapiko sa pampublikong address ng VPN server palabas sa uplink para hindi kailanman pumasok ang naka-encrypt na sesyon sa sarili nitong tunel. Gumagana iyon hanggang sa sandaling gusto mo rin abutin ang serbisyong web sa parehong server sa pamamagitan ng tunel, dahil nakatali ang pagtatangi sa destinasyon at pareho ang destinasyon. Ang labasan ay itigil ang pag-uuri ayon sa destinasyon at simulan ang pag-uuri ayon sa kung aling socket ang nagpadala ng pakete.

Magsimula sa dalawang daloy na gusto mong paghiwalayin

Ang isang daloy ay ang naka-encrypt na OpenVPN transport mismo, na kailangang lumabas sa uplink, kung hindi ay dadalhin ng tunel ang sarili nitong panlabas na koneksyon. Ang isa ay ordinaryong HTTPS request sa parehong pampublikong address, na gusto mong nasa loob ng tunel para marating ang serbisyo mula sa pinagmulang tunel. Parehong destinasyon, sa maraming kaso parehong port number, ibang kinakailangang landas.

Para sa pagtalakay na ito, ipagpalagay ang kliyente sa 10.90.0.10 sa tun1, pampublikong address ng server na 198.51.100.25, at hindi pa nagalaw na pangunahing table na ang default na ruta ay papunta sa ordinaryong uplink. Kailangan din ng panig ng server na tanggapin ang serbisyong web sa panloob na landas at ibalik ang trapiko sa pinagmulan ng tunel; ang pagpapadala ng pakete sa pampublikong address ay hindi nagsasawalang-bisa sa listener o patakaran ng firewall ng server.

Bago baguhin ang anuman, itala ang kasalukuyang mga patakaran ng host at pumili ng mga halagang walang ibang gumagamit: isang marka, isang numero ng table at tatlong prayoridad ng patakaran. Panatilihin ang daan pabalik sa makina na hindi dumadaan sa koneksyong ito, dahil ang pagkakamali dito ay nag-aalis ng sarili mong malayuang access, hindi lamang sinisira ang isang tab ng browser.

Markahan ang socket na nagdadala ng sobre

Ang configuration ng kliyente ay nakakakuha ng marka para sa mga naka-encrypt nitong palabas na pakete at tumitigil sa pag-install ng mga ruta nang mag-isa, kaya ang patakaran sa pagpapalit ang tanging nagpapasya sa mga landas:

mark 42
route-noexec
disable-dco

Ang decimal 42 ay hexadecimal 0x2a, at ang hex form ang itatapat ng mga patakaran sa routing. Ang sanggunian ng link-options ay naglalarawan ng mark bilang isang bagay na nalalapat sa mga naka-encrypt na palabas na pakete sa Linux, na siya mismong socket na kailangan mong kontrolin ang landas. Ang pagpatay sa offload ng data channel ay nagpapanatili sa halimbawang ito sa landas ng userspace, kung saan ang pag-uugali ng marka ang inilarawan.

Pinipigilan ng route-noexec ang awtomatikong pagdaragdag at pagtatanggal ng mga ruta ng OpenVPN. Wala itong iniinstall sa halip, kaya mula ngayon kailangang mapanatili ng may-ari ng ruta ang bawat rutang kailangan ng tunel. Kung mawala ang isang pribadong destinasyon pagkatapos ng pagbabago, iyon ang kulang na patakaran sa pagpapalit, hindi depekto sa marka.

Huwag panatilihin ang rutang host sa pangunahing table para sa 198.51.100.25 habang ginagawa ito. Ang ganitong ruta ay muling nagdadala ng eksaktong pagtatanging sinusubukang paikliin ng disenyo, at mananalo ito para sa daloy ng HTTPS bago tanungin ang alinman sa mga patakaran sa ibaba.

Ipadala ang lahat ng iba pa sa table ng tunel

Kapag umiiral na ang interface ng tunel at hawak ang address nito, ganito ang patakaran:

ip -4 route add default dev tun1 src 10.90.0.10 table 47100
ip -4 rule add priority 20000 lookup main suppress_prefixlength 0
ip -4 rule add priority 20001 not fwmark 0x2a lookup 47100
ip -4 rule add priority 20002 not fwmark 0x2a unreachable

Pinapanatili ng unang patakaran na nakikita ang mga partikular na ruta ng host, kabilang ang anumang aprubadong lokal na network, habang ginagawang di-nakikita ang default na ruta ng pangunahing table para sa paghahanap na ito. Mahalaga ang pagkakaibang iyon: ang pagsugpo sa default ay hindi katulad ng pagwawalang-bahala sa table, at ang mga lokal na pagtatangi na kailangan mo pa ay nananatili dahil doon. Basahin ang mga pagtatanging iyon nang isa-isa sa halip na ipagpalagay na ang resulta ay unibersal na emergency switch.

Ang hindi namarkahang trapiko ay babagsak sa table ng tunel, kukunin ang pinagmulan ng tunel at lalabas sa VPN. Ang namarkahang trapiko ay mabibigo sa fwmark test sa susunod na dalawang patakaran at magpapatuloy sa ordinaryong pangunahing paghahanap sa mas mababang bahagi ng listahan, kung saan naroon pa rin ang default ng uplink. Ang huling unreachable na patakaran ang pumipigil sa isang hindi namarkahang daloy na tahimik na bumalik sa uplink kapag wala ang ruta ng tunel. Ang tagapili ay ang marka mula simula hanggang dulo, at ang address ng destinasyon ay hindi kailanman pumapasok sa desisyon.

Panatilihin ang gabay na iyon sa lugar sa mga pagkakadiskonekta, at i-install ito kasama ng iba pang patakaran sa halip na manu-mano. Ang patakarang nawawala kasama ng interface ay hindi patakaran, ito ay pagkakataon. Ang pagbura ng patakaran kapag bumagsak ang tunel ay nagbabago ng mode ng pagkabigo mula “nakaharang” patungong “tumagas”, at ang lumang rutang tunel na mag-eexpire mamaya ay mas madaling ipaliwanag na problema kaysa trapikong lumabas sa maling interface.

Hayaang makita ng pabalik na landas ang parehong marka

Ang mga palabas na marka ay kalahati lamang ng mekanismo, at ito ang bahaging iniiwan ng karamihan sa mga muling pagbuo. Ang mga tugon sa naka-encrypt na sesyon ay dumarating sa uplink at napapailalim sa validation ng pabalik na landas, na nagtatanong kung ang pinagmulan ay iruruta pabalik sa parehong daan. Kung walang tulong, ipinapataw ng paghahanap na iyon ang iyong hindi namarkahang patakaran sa tunel at naghihinuha na ang pakete ay nasa maling interface.

Ang pagwawasto ay pag-aari ng may-ari ng firewall: i-save ang marka sa palabas na koneksyon, ibalik ito sa mga tugmang papasok na pakete at paganahin ang paghawak ng markang napatunayan ng pinagmulan para sa kaugnay na landas. Ang pagtatakda ng OpenVPN ng marka ng socket ay hindi gumagawa ng alinman sa tatlong iyon, at ang recipe na naglilista lamang ng mga opsyon ng kliyente ay hindi kumpleto. Hilingin ang integrasyong iyon nang nakasulat, dahil iyon ang pinakamaliit na nakikitang bahagi ng disenyo at ang pinakamadaling mawala sa muling pagbuo.

Ang maluwag na pagsusuri ng pabalik na landas ay hindi rin kapalit. Ang maluwag na mode ay nangangailangan pa rin ng rutang umiiral para sa pinagmulan, at ang unreachable na gabay na idinagdag mo ay sadyang nag-aalis ng isa para sa mga hindi namarkahang paghahanap. Tapusin at repasuhin ang integrasyon ng marka ng koneksyon bago ka umasa sa disenyong ito, at ituring ang mga filter ng host bilang hiwalay na tanong: ang marka ay hudyat ng routing, hindi pahintulot. Kung wala ang integrasyon, ang sintomas ay sesyon na nabubuo at pagkatapos ay tahimik sa sandaling magsimulang dumating ang mga tugon.

Patunayan ito sa dalawang paghahanap ng ruta

Ihambing ang pinagpapasyahan ng kernel para sa dalawang konteksto, at basahin ang dev at src na field sa halip na ang exit status:

ip -4 route get 198.51.100.25
ip -4 route get 198.51.100.25 mark 0x2a

Ang unang paghahanap ay dapat lumutas sa tun1 kasama ang pinagmulan ng tunel, at ang pangalawa sa uplink. Ito ay mga sintetikong paghahanap, kaya pinapatunayan nila ang patakaran at hindi ang tumatakbong proseso: kumpirmahin nang hiwalay ang aktwal na landas ng transport ng tumatakbong kliyente, pagkatapos gumawa ng tunay na HTTPS request na buhay pa ang verification ng certificate.

Itala ang hindi saklaw ng disenyo bago itong ideklarang tapos. Ang DNS, IPv6 at lifecycle ng mga patakaran ay nangangailangan ng kani-kanilang desisyon, at ito ay halimbawa ng IPv4 routing, hindi kumpletong configuration ng privacy. Ang halaga nito ay ang tagapili: nakukuha ng sobre ang pagtatangi ng uplink, at ang ordinaryong serbisyo sa parehong address ay hindi kailangang magmana nito.