Panatilihin ang mga pribadong ruta at iwanan ang redirection: nahating tunnel ng OpenVPN
Ang tunnel na para lamang sa mga pribadong network ay nangangailangan ng dalawang tuntunin: dumadaan dito ang mga pribadong prefix, pinapanatili ng ordinaryong pag-browse ang lokal na landas nito. Ang pagbura ng default na ruta ay hindi patakaran.
Bumabangon ang tunnel, naglo-load ang application, at pagkatapos ay nagsisimulang kumilos nang kakaiba ang lahat ng iba pa sa laptop. Ito ang karaniwang hugis ng patakarang pribado lamang na ipinatupad sa pamamagitan ng pagbura ng isang linya. Ang pagtanggal ng itinulak na default na ruta ay talagang nagbabago kung saan pumupunta ang trapiko, ngunit hindi nito sinasabi kung saan dapat pumunta ang trapiko sa halip, at hindi nito hinahawakan ang resolusyon ng pangalan. Ang patakaran ay nangangailangan ng dalawang positibong kalahati bago ito masubukan.
Ang pagbura ng redirection ay kalahati lamang ng pagbabago
Ang redirection ng buong tunnel at ang patakarang pribado lamang ay nagkakaiba sa kanilang ipinapahayag tungkol sa mundo. Inaangkin ng redirection ang bawat destinasyon, samantalang inaangkin ng pribadong patakaran ang isang listahan at hinahayaan ang iba. Ang pagbura ng claim nang hindi isinusulat ang listahan ay gumagawa ng client na walang naaabot sa labas ng LAN, na mukhang pagkabigo sa pagruruta kaysa butas sa patakaran. Isulat ang listahan bago tanggalin ang claim, at ang pagkakasunod-sunod ng dalawang hakbang ay hindi na mahalaga.
Ang dalawang kalahati ay mga kinakailangan at hindi default. Kailangang pumasok ng mga pribadong prefix sa tunnel, at kailangang panatilihin ng mga ordinaryong destinasyon ang landas na mayroon sila bago ang koneksyon.
Kung ipinag-uutos ng organisasyon ang buong tunnel, wala sa mga ito ang nalalapat. Ang disenyong pribado lamang ay para sa mga deployment kung saan aprubado ang split routing.
pull-filter ay isang pagtutugma, hindi isang switch
Tinatanggal ng direktibang pull-filter ang mga itinulak na opsyon na tumutugma ang pangalan sa isang prefix, at iyon lang ang ginagawa nito. Ang hindi pagpansin sa redirection ay nag-iiwan sa bawat iba pang itinulak na opsyon sa lugar nito, na karaniwang siyang gusto mo: dumarating pa rin ang mga ruta, mga setting ng DNS at ang halaga ng route gateway. Hindi rin nito matatanggal ang direktibang nakasulat sa lokal na profile, dahil ang pag-filter ay nalalapat sa itinutulak ng server.
Labanan ang tukso na huwag pansinin ang bawat opsyon na nagsisimula sa route. Itinatapon din ng pattern na iyon ang mga pribadong rutang kailangan ng koneksyon, at maaari nitong ilaglag ang impormasyon ng gateway na pinagkakatiwalaan ng tunnel.
Ang route-nopull ay isang mas malawak na desisyon kaysa sa itsura nito. Pinipigilan nito ang client na tanggapin ang mga itinulak na ruta at mga opsyon na parang DHCP bilang isang grupo, na ibang patakaran kaysa sa pag-filter ng isang opsyon.
Isulat ang listahan ng ruta mula sa application palabas
Magsimula sa aktwal na binubuksan ng user, pagkatapos ay idagdag ang mga bahaging sumusuporta. Ang application sa 10.60.20.15 ay nagpapahiwatig ng subnet nito 10.60.0.0/16, at ang pribadong pangalan ay nagpapahiwatig ng resolver na sumasagot dito. Kaya ang user na humiling ng isang application ay nangangailangan ng dalawang destinasyon at isang desisyon sa DNS. Lahat ng lampas sa listahang iyon ay labas ng saklaw ayon sa pagkakabuo, at iyon ang nagpapanatili sa patakarang masusuri.
Sa isang server na nakikipagtulungan, ang mga iyon ay nagiging dalawang itinulak na ruta, at wala sa kanila ang redirection. Panatilihin ang topology ng tunnel at ang mga halaga ng route gateway na ibinibigay ng umiiral na serbisyo.
Kapag ilang user lamang ang nangangailangan ng patakarang ito, ilapat ito sa bawat client o bawat grupo. Ang pagbabago ng rutang tinatahak ng lahat para ayusin ang pangangailangan ng isang koponan ay ang paraan kung paano nagiging pagkaantala ang nahating tunnel.
| Destination | Intended path |
|---|---|
10.60.0.0/16 | Tunnel, for the approved application services |
10.61.0.53/32 | Tunnel, to reach the internal resolver |
corp.example queries | Internal resolver, selected per namespace |
| Everything else | Local path and local resolver |
Hayaang sundan ng DNS ang parehong landas
Ang ruta patungo sa resolver ay hindi patakaran ng resolver. Sa isang client ng systemd-resolved ang semantikong resulta ay isang routing domain para sa pribadong namespace na tumuturo sa panloob na resolver, at iyon ang dahilan kung bakit iyon lamang mga pangalan ang gumagamit nito. Ang client ng Windows ay nangangailangan sa halip ng sarili nitong mekanismo ng patakaran ng namespace. Ang linyang server ng DNS sa profile ay hindi nag-i-install ng alinman sa dalawa nang mag-isa.
Tingnan kung ano ang pinili ng operating system at hindi kung ano ang hiningi ng profile. Sa Linux, ipinapakita ng resolvectl status ang domain at server bawat link; sa Windows, ang talahanayan ng patakaran ng namespace ang katumbas na ebidensya.
Panatilihing maabot ang resolver sa pamamagitan ng tunnel, kung hindi ay tumuturo ang patakaran sa isang address na hindi maitatanong. Ang address ng resolver na hindi naaabot ng tunnel ay ginagawang timeout ang isang gumaganang patakaran.
I-verify ang dalawang kalahati sa muling pagkonekta
Ikonekta muli ang client pagkatapos ng pagbabago at suriin ang epektibong ruta patungo sa pribado at sa pampublikong address. Pagkatapos ay i-resolve ang isang pribadong pangalan at isang pampublikong pangalan at tiyakin na ginamit ng bawat isa ang inilaan na resolver. Ang paglo-load ng pampublikong website ay nagpapatunay lamang sa ikalawang kalahati, at iyon ang kalahating karaniwang gumagana nang nagkataon.
Itala ang natapos na patakaran sa isang pangungusap: ginagamit ng mga prefix at pangalang ito ang koneksyong ito, sinusunod ng lahat ng iba ang lokal na landas. Pagkatapos ay itago ito sa profile sa halip na ayusin ang mga setting ng adapter pagkatapos ng bawat pag-login.