route-gateway ay hindi redirect-gateway: ano talaga ang nagbabago

Bumangon ang iyong tunnel, sumasagot ang pribadong subnet, at nawawala pa rin ang ordinaryong pagba-browse sa VPN kahit may nagbura ng gateway na linya mula sa profile. Ang kombinasyong iyon ang bakas ng daliri ng maling direktiba na na-edit. Ang inalis ay nagbibigay sa kliyente ng susunod na hop para sa mga rutang ini-install nito; ang patuloy na humuhuli ng trapiko ay galing sa ibang lugar at itinulak ng server. Magkaibang gawain ang saklaw at susunod na hop, at isa lamang sa kanila ang nagpapasya kung ginagamit ng mga pampublikong destinasyon ang tunnel.

Ang linyang inalis mo ay susunod na hop, hindi switch ng patakaran

Bawat rutang ini-install ng kliyente ay nangangailangan ng gateway address na tututukan, at ang direktiba ng gateway ang pinagmumulan ng address na iyon kapag ang ruta mismo ay walang pinangalanan. Burahin iyon at wala nang kakapitan ang mga rutang iyon, kaya alinman sa hindi sila naka-install o napupunta sa landas na walang patutunguhan. Ang pribadong subnet ang eksaktong dala ng gayong ruta.

Samantala ang gawi na natira ay may ibang may-akda: isang opsyon sa redirection sa itinulak na bloke, na naglilipat ng ordinaryong papalabas na trapiko papasok sa tunnel ayon sa mga flag nito. Ang pag-alis ng gateway ay hindi ito pinapatay o pinahihina. Ang resulta ang pinakamasama sa dalawang estado, nahuhuli pa rin ang pampublikong trapiko at ang pribadong destinasyong nagbigay-katwiran sa tunnel ay hindi na maabot ngayon. Kaya nga ang pangalawang edit, na ginawa sa parehong diwa, ay wala ring binabago.

Apat na lever, apat na magkaibang gawain

Sa diskusyong ito apat na direktiba ang binabanggit nang palitan, at isa lamang sa kanila ang namamahala sa saklaw, ibig sabihin, kung aling mga destinasyon ang dumadaan sa tunnel. Ang pangalawa ay nagtatakda ng susunod na hop na ginagamit ng mga ruta, ang pangatlo ay nag-i-install ng isang prefix, at ang pang-apat ay itinatapon ang lahat ng itinulak ng server, kasama ang mga pribadong rutang kailangan ng deployment. Ang talahanayan ay nag-aayos sa kanila ayon sa sinusubukang baguhin ng administrator at hindi ayon sa pangalan, dahil ang mga pangalan ang nagdudulot ng kalituhan. Ituring ang mga ito na apat na hiwalay na desisyon at piliin ang talagang gusto mong ibalik.

Sa praktika madalas na dumating ang apat sa isang itinulak na bloke, linya pagkatapos ng linya, kaya mukha silang bahagi ng isang setting. Hindi sila, at ang sanggunian ng OpenVPN ay idinodokumento sila bilang magkaibang mekanismo dahil doon. Ang pag-alam kung aling desisyon ang ibinabalik mo ang gawain; ang edit ay isang linya.

I-filter ang itinulak na linya, panatilihin ang susunod na hop

Kung ang saklaw na tinututulan mo ay dumating bilang itinulak na opsyon, ang makitid na sagot ay hindi pansinin ang opsyong iyon sa pangalan at iwan ang natitirang bahagi ng itinulak na bloke na hindi ginalaw. Kapag isinulat bilang filter, mukha itong linya sa ibaba, at kabilang ito sa profile ng apektadong kliyente, hindi sa configuration ng server.

pull-filter ignore "redirect-gateway"

Ang pagkamakitid ang punto. Dahil inihahambing ng filter ang isang text prefix, tumutugma rin ang mas maikling pattern sa direktiba ng susunod na hop, na nag-aalis ng eksaktong impormasyong umaasa ang mga pribadong ruta at inuulit ang orihinal na pagkakamali sa bagong kasuotan. Gumagana rin ang filter sa mga itinulak na opsyon lamang, kaya hindi nito kailanman nahahawakan ang katumbas na linyang nakasulat nang lokal o ipinilit ng manager ng network. Kumonekta muli pagkatapos, dahil hindi muling sinusuri ng buhay na session ang itinulak ng server.

Basahin ang paghahanap, hindi ang talahanayan

Pagkatapos i-reload ang profile, tanungin ang kernel kung saan talaga pupunta ang dalawang destinasyon: isa sa loob ng pribadong prefix at isa sa pampublikong internet. Ang buong dump ng pangunahing talahanayan ay mas mahirap basahin at mas madaling mabasa nang mali, dahil maaaring umiiral ang isang ruta at matalo pa rin sa isang mas partikular na tugma. Sa routing na batay sa patakaran, bahagi rin ng pagsusuri ang panuntunan, talahanayan at source address.

ip route get 10.40.7.25
ip route get 203.0.113.77
ip rule show

Ang varianteng def1 ay dapat malaman, dahil iniiwan nitong nakikita ang lumang default na entry habang nananalo ang isang pares ng kalahating-default sa paghahanap. Kaya ang isang linya ng 0.0.0.0/0 sa output ay walang pinapatunayan nang mag-isa. Sinasagot ng paghahanap ang tanong na tila sinasagot lamang ng listahan.

DNS, IPv6 at ang pribadong ruta ay kailangan pa ring gumana

Ang pagtanggi sa isang redirection ng IPv4 ay walang sinasabi tungkol sa resolver, kaya ang itinulak na opsyon ng DNS ay maaaring magpatuloy sa pagpapadala ng mga query sa tunnel habang mukhang tama ang mga ruta. Ang default na IPv6 ay maaaring gumawa ng pareho para sa isang pamilya ng address na hindi kailanman nahawakan ng pagsusuri ng IPv4. Kailangan ng dalawa ang malinaw na desisyon sa halip na palagay. Pagkatapos ay kumpirmahin na sumasagot pa rin ang pribadong serbisyo, dahil ang nahating tunnel na nawalan ng pribadong ruta ay hindi nahating tunnel, ito ay sira.

Ang isang mas malawak na kasangkapan ay karapat-dapat sa babala: route-nopull itinatapon ang bawat itinulak na ruta at bawat itinulak na opsyon ng DNS, na tiyak na humihinto sa buong tunnel at kasing tiyak na sumisira sa mga pribadong rutang umaasa ang deployment, kaya mas malaking martilyo ito kaysa sa filter ng pangalan na nakatutok sa isang opsyon. Suriin ang pribadong destinasyon, pampublikong destinasyon at resolver pagkatapos ng anumang pagbabago, at ituring ang natapos na handshake na patunay ng walang iba kundi ang handshake.