Pinatay ng buong tunnel ang sesyon SSH mo: i-pin ang rutang pabalik

Simulan ang kliyenteng OpenVPN sa makina na pinagtatrabahuhan mo sa SSH, at sa gitna ng utos ay nagyeyelo ang sesyon. Sinasabi ng tunnel na konektado ito, naaabot ng host ang internet sa pamamagitan nito, at dumarating pa rin ang iyong mga pagpindot sa teklado habang walang bumabalik. Ang nagbago ay hindi ang tunnel: ito ang daang pabalik para sa mga packet na nakapangalan sa iyo, na ngayon ay tumutugma sa bagong default na ruta at pumapasok sa isang tunnel na hindi gagamitin ng remote gateway para maabot ang iyong mesa.

Ano ba talaga ang inilalagay ng redirect-gateway

Sa anyong def1 nito, nagdaragdag ang redirect-gateway ng 0.0.0.0/1 at 128.0.0.0/1 sa halip na i-overwrite ang default na ruta. Sinasaklawan ng dalawang kalahating ito ang buong espasyo ng address habang nananatiling mas mahabang prefix ang dalawa kaysa sa 0.0.0.0/0, kaya anumang destinasyon na walang mas tiyak na tugma ay pumapasok na ngayon sa tunnel. Iyon ang mekanismong dapat tandaan, dahil bawat pag-aayos sa ibaba ay gumagana sa pamamagitan ng paglalagay ng mas tiyak na tugma.

Ang iyong admin address ay isa sa mga destinasyong iyon.

Ipinapasa ng server ng VPN ang trapiko ng mga kliyente nito patungo sa internet. Wala itong ruta para sa pampublikong address na pinagkokonektahan mo, at walang dahilan para ituring ang mga packet na iyon na anupamang bagay maliban sa trapikong nagmumula sa isang kliyente, kaya itinatapon ito. Samantala, nakarating pa rin ang request na ipinadala mo sa host, kaya mukhang buhay ang sesyon sa isang panig lamang.

ip route show table main | head -n 20
ip route get 198.51.100.23

Hanapin ang iyong source address at ang daan bago ang tunnel

Sa server, ilista ang naitatag na koneksyong SSH at tandaan ang address ng kapartner na pinagmulan nito. Ang address na iyon ang dapat saklawin ng iyong rutang pabalik, at hindi ito laging ang inaakala mo: ang jump host, NAT gateway o tagapagsalin ng carrier ay maaaring magpalit ng ibang pinagmulan.

Pagkatapos hanapin ang pisikal na gateway at interface na nagdala ng trapiko bago nagsimula ang tunnel. Sa kaayusang def1 naroon pa rin ang default na ruta sa ilalim ng mga kalahating default, kaya available ang impormasyon, bagaman ang pagbabasa ng mahabang talahanayan ng ruta sa mata ay nag-aanyaya ng pagkakamali.

Isulat nang sabay ang dalawang halaga at ang pangalan ng interface, dahil kailangan ng rutang idadagdag mo ang tatlo. Kung gumamit ang host ng panuntunan ng policy routing para piliin ang uplink nito, maaaring hindi isaalang-alang ang ordinaryong ruta, at binabago ng posibilidad na iyon ang pag-aayos.

I-pin ang ruta ng host na lumalampas sa mga kalahating default

Ang rutang /32 ay mas mahaba kaysa alinman sa mga kalahating default, kaya kinukuha ito ng mga tugon sa iyong address kaysa sa tunnel. Ang susunod na hop ay ang gateway bago ang tunnel at ang device ay ang pisikal na interface, na nagpapanatili sa packet sa daang ginamit nito bago umiral ang tunnel.

ip route add 198.51.100.23/32 via 203.0.113.1 dev eth0

I-verify sa pamamagitan ng paghahanap, hindi sa pag-inspeksyon ng talahanayan: dapat banggitin ng sagot ang eth0 at ang gateway, hinding-hindi ang tun0.

Nagdaragdag na ang OpenVPN ng rutang host para sa sariling address ng server ng VPN para sa parehong dahilan, kaya pamilyar ang pattern at ang admin address ay isa lamang karagdagang eksepsiyon. Huwag gamitin ang route-nopull para ayusin ito, dahil itinatapon nito ang mga itinulak na rutang kailangan ng tunnel, kasama ang remote network at mga opsyon ng DNS.

Gawin itong tumagal sa muling pagkonekta

Ang rutang idinagdag sa kamay ay nawawala kapag muling kumonekta ang kliyente at nag-install ng sarili nito, na ginagawang paulit-ulit na pagkawala ang isang pag-aayos. Ikabit ang utos sa isang bagay na tumatakbo pagkatapos ma-install ang mga ruta.

Gumagana ang script na route-up o ang pre-up hook ng network manager, at ang maaasahang pagtingin ay muling pagkonekta na sinusundan ng parehong paghahanap.

Sa Windows, ang katumbas ay persistenteng rutang idinagdag gamit ang -p, na tumatagal sa mga reboot ngunit kailangan pa ring tumuro sa tamang gateway pagkatapos ng pagbabago sa network. Anuman ang platform, isulat ang dahilan sa tabi ng ruta: kailangan ng susunod na admin na malaman na mayroon ito para protektahan ang sesyon ng pamamahala, hindi dahil hiniling ito ng disenyo ng network.

Kapag hindi pa rin sapat ang naka-pin na ruta

Maaaring itapon ng reverse-path filtering ang packet na dumarating sa isang interface at lumalabas sa iba, na eksaktong nililikha ng naka-pin na ruta. Suriin ang epektibong halaga ng rp_filter bago i-disable ang anuman nang pangkalahatan, at piliing ayusin ang asimetriya kaysa patayin ang pagsusuri. Ang setting sa bawat interface ang naaangkop, at madalas na itinatala lamang ng loose mode ang asimetriya sa halip na itapon ang packet. Basahin ang dalawa bago magpasyang ang filter ang may kasalanan.

Ang mga host na may policy routing ay nangangailangan ng panuntunan gayundin ng ruta, dahil pinipili ng base ng panuntunan ang talahanayan bago isaalang-alang ang rutang nasa loob nito. Ang ruta sa pangunahing talahanayan ay hindi nakikita ng daloy na tumutugma sa panuntunang tumuturo sa ibang talahanayan. Basahin ang mga panuntunan bago magdagdag ng anuman sa main. Kung saklaw na ng isang panuntunan ang trapiko ng pamamahala, sa talahanayan ng panuntunang iyon dapat naroon ang eksepsiyon.

Panatilihing bukas ang isang console na nasa labas ng banda habang nagsubok ka, at muling suriin mula sa ikalawang pag-login bago idiskonekta ang ginagamit mo. Ang rutang nagpapadala ng sarili mong trapiko ng pamamahala sa tunnel ay pumuputol sa koneksyong inaayos mo. Ang makabalik pagkatapos ay nangangahulugan ng serial console o rescue boot, na masamang kapalit sa paglaktaw ng isang hakbang sa pag-verify.