Panatilihin ang pagpapasa ng IPv4 pagkatapos ng muling pagsisimula ng gateway ng VPN
Itakda ang ip_forward sa namespace na nagdadala ng mga packet ng kliyente, bigyan ang setting ng isang may-ari, at patunayan na nakakaligtas ito sa muling pagsisimula sa halip na i-edit lamang ang isang file.
Gumagana ang ping sa gateway ngunit hindi ang pag-abot sa anumang nasa likod nito, at ito ang hugis ng problema sa pagpapasa at hindi problema sa tunnel. Ang lokal na paghahatid sa gateway ay nagpapatunay na umangat ang tunnel at gumana ang pagtatalaga ng address; wala itong sinasabi tungkol sa kung ipapasa ng kernel ang isang packet mula sa isang interface patungo sa isa pa. Bago hawakan ang anumang sysctl, tiyakin na ang makina ay inilaan upang i-route ang trapikong ito at hanapin ang konteksto ng network na may hawak ng interface na nakaharap sa kliyente. Pagkatapos ay basahin ang halaga doon, hindi doon kung saan nagkataong tumingin ang huling gabay na binasa mo.
Ang pag-abot sa gateway ay hindi katulad ng pagpapasa
Dalawang magkahiwalay na desisyon ang nangyayari sa loob ng kernel. Ang paghahatid sa isang lokal na address ay nagtatapos sa paglalakbay ng packet; ang pagpapasa ay muling naglalabas nito sa ibang interface, at ang pangalawang desisyong iyon ay pinamamahalaan bawat namespace ng network. Ang gateway ay maaaring ganap na maabot habang patay ang pagpapasa, at mula sa prompt ng ping magkapareho ang hitsura ng dalawang pagkabigo.
Isulat kung aling interface pumapasok ang packet ng kliyente at kung aling interface lumalabas ang susunod na landas. Pareho silang kabilang sa isang namespace, at nasa namespace na iyon ang mahalagang setting.
Basahin ang halaga doon kung saan talaga naroon ang mga packet
Sa gateway na nagro-route sa namespace ng host, isang utos ang sumasagot sa tanong: sysctl net.ipv4.ip_forward. Kapag ang papasok at susunod na landas ay naninirahan sa isang pinangalanang namespace, itanong sa namespace na iyon: ip netns exec vpn-gw sysctl net.ipv4.ip_forward. Ang halaga ng host ay hindi kapalit ng halaga ng namespace, at ang isa sa host ay hindi patunay ng anuman.
Hindi lahat ng konteksto ng pag-route ay may label na maibibigay mo sa ip netns. Ang mga runtime ng container at mga serbisyo ay lumilikha ng mga namespace na hindi kailanman nakarehistro sa ilalim ng magiliw na pangalan, at para sa mga iyon ginagamit mo ang mga kasangkapan sa inspeksyon ng runtime. Palitan ang vpn-gw ng tunay na pangalan, o ng mekanismo ng runtime na umaabot sa parehong konteksto, at huminto sa paghula sa antas ng host.
Bigyan ang setting ng isang may-ari
Sa karaniwang gateway ng host na may systemd, ang matibay na anyo ay isang drop-in na file na may pangalang pinili ng administrador tulad ng /etc/sysctl.d/60-vpn-forwarding.conf na naglalaman ng net.ipv4.ip_forward = 1. Isulat ang file, pagkatapos ay i-load ang partikular na file na iyon upang magbago rin ang live na estado: sudo sysctl -p /etc/sysctl.d/60-vpn-forwarding.conf, na sinusundan ng muling pagbasa. Ang pangalan ng file ay halimbawa at hindi nakalaang landas ng VPN, at mahalaga ang unang numero dahil ang mga file na naayos nang mas huli ay nananalo.
Ang priyoridad ang lugar kung saan tahimik na nasisira ang tibay. Suriin ang loader ng distribusyon at pati na rin ang iyong sariling drop-in, dahil ang procps sysctl --system ay nagbabasa rin ng /etc/sysctl.conf sa dulo, samantalang ang ayos ng sysctl.d ng systemd ay ganap na ibang pagkakasunod-sunod. Ang isang mas huling pagtatalaga ay maaaring agad na ibalik ang parehong susi, na nag-iiwan sa iyong file na tama at ang epektibong halaga ay mali. Huwag i-overwrite ang umiiral na file ng administrador upang manalo sa pagtatalong iyon; hanapin ang may-ari at baguhin doon.
Ang namespace na nilikha pagkatapos ng boot ay hindi pinamamahalaan ng drop-in ng host. Ang setting nito ay pag-aari ng anumang lumikha nito, maging ang runtime ng container o ang provisioning unit para sa namespace. Ang pagbibigay sa container ng malawak na pribilehiyo ng host upang iwasan ang tanong ay mas masamang kalakalan kaysa sa paggugol ng sampung minuto sa pagkilala sa tamang may-ari.
Alamin ang halaga ng switch bago mo ito baliktarin
ip_forward ay hindi isang inosenteng boolean. Tandaan ng dokumentasyon ng kernel na ang pagbabago nito ay nagre-reset ng ilang iba pang parameter ng IPv4 sa default ng host o router, kaya ang diagnostic na pagbaliktad ay maaaring magtapon ng tuning na ginawa sa ibang lugar at hindi kailanman banggitin ito. Ituring ito bilang pagbabago sa configuration na may side effect at hindi bilang pagsubok na maaaring patakbuhin nang walang ingat.
Ito rin ay nag-aalis ng pag-off at pag-on nito tuwing hindi maabot ng kliyente ang isang host. Kung ang halaga ay isa na, ang depekto ay nasa ibang bahagi ng landas, at ang muling pagsulat ng parehong susi sa ikatlong pagkakataon ay hindi ito gagalawin.
Patunayan ang tibay, pagkatapos ay subukan ang natitirang bahagi ng landas
Basahin ang halaga pabalik sa apat na sandali: kaagad pagkatapos ng pagbabago, pagkatapos lumitaw ang interface ng VPN, pagkatapos ng muling pagkonekta, at pagkatapos ng planong muling pagsisimula. Ang halagang bumabalik sa alinman sa mga puntong iyon ay may pangalawang may-ari, at isa pang minsanang pagsulat ay itinatago lamang iyon hanggang sa susunod na reboot.
Ang pinagana na pagpapasa ay nag-iiwan pa rin ng tatlong bagay na dapat i-verify. Kailangan ng kliyente ng ruta patungo sa destinasyon, kailangan ng gateway ng susunod na ruta at pahintulot na gamitin ito, at kailangan ng destinasyon ng pabalik na landas patungo sa address ng tunnel ng kliyente. Ang pribadong naka-route na LAN ay hindi awtomatikong nangangailangan ng NAT, kaya huwag magdagdag ng masquerading bago mo malaman kung alin sa tatlo ang kulang, at subukan mula sa inilaan na kliyente at hindi mula sa gateway mismo, dahil ang kahilingang nagmula sa gateway ay hindi kailanman humahawak sa landas ng pagpapasa na kakabukas mo lang. Ang IPv6 ay may sariling patakaran sa pagpapasa at pag-route, kaya ang gumaganang pagsubok ng IPv4 ay walang sinasabi tungkol dito.
Panatilihing magkasama sa runbook ang landas ng drop-in, ang may-ari ng namespace, at ang utos ng muling pagbasa. Sinumang kukuha nito sa susunod ay dapat makabasa ng halaga, makita kung sino ang may-ari nito, at makapagpasya sa loob ng isang minuto kung ang problema ay tibay o ang natitirang bahagi ng landas.