Bakit hindi ginagalaw ng net.ipv4.conf.default.forwarding ang tun0

Itinakda mo ang net.ipv4.conf.default.forwarding=1, ni-restart ang VPN, at itinatapon pa rin ng tunnel ang mga packet na dapat i-route ng gateway. Mukhang tama ang setting sa file, at nag-uulat pa rin ang interface na patay ang forwarding. Walang sira: binago mo ang value na mamanahin ng mga susunod na interface, hindi ang ginagamit ng buhay na tunnel.

Balikan ito sa host na nagmamay-ari ng tunnel, sa network namespace kung saan talagang umiiral ang tunnel. Maaaring hawakan ng container o network namespace ang interface habang iba ang ipinapakitang numero ng host.

Basahin ang tatlong value nang sabay

Magsimula sa paghahambing ng switch para sa buong gateway, ng template para sa mga bagong interface at ng interface na mahalaga sa iyo. Palitan ang tun0 ng tunay na ingress interface, at basahin din ang return interface, dahil sinusuri ang forwarding sa puntong dumarating ang packet.

sysctl net.ipv4.ip_forward
sysctl net.ipv4.conf.default.forwarding
sysctl net.ipv4.conf.tun0.forwarding

Karaniwang resulta ay ip_forward = 0, default.forwarding = 1 at tun0.forwarding = 0. Hindi nagkakasundo ang unang dalawa tungkol sa papel ng host, at ipinapakita ng pangatlo kung ano talaga ang ginagawa ng interface. Tumutugma ang kombinasyong iyon sa isang host na hindi kailanman na-configure bilang router, kundi binigyan lamang ng template value. Hindi nagkakasalungat ang tatlong numero; sumasagot sila sa tatlong magkaibang tanong. Hindi rin natatakdaan ng pagsulat ng template value ang papel ng host.

Bakit ang global switch ang gumagalaw

net.ipv4.ip_forward ang kontrol para sa buong gateway. Kapag binago ito, nag-a-update ang mga setting ng forwarding bawat interface bilang bahagi ng parehong operasyon, kaya isang sulat lang ang makapagsisimula ng pag-forward ng umiiral nang tunnel. default.forwarding ang nagtatanim lamang ng mga interface na sinisimulan pagkatapos, kaya ang tunnel na umiiral na ay nagpapanatili ng value kung kailan ito isinilang.

Tinutukoy ng dokumentasyon ng kernel ang ip_forward bilang espesyal sa isang kaugnay na dahilan: kapag binago ito, nire-reset ang isang hanay ng iba pang IPv4 parameter sa default ng host o router. Ginagawa nitong blunt instrument ang bagay na ito. Ang itakda ito nang isang beses bilang bahagi ng pagtatatag ng papel ng gateway ay ayos lang; ang paulit-ulit na pag-toggle nito bilang trick sa pag-debug ay maaaring tahimik na mag-overwrite ng configuration na pinaghirapan mong gawing tama.

May dahilan din ang mga value bawat interface. Ang gateway na sadyang pinamamahalaan ay maaaring iwanang patay ang forwarding sa isang interface na hindi dapat kailanman mag-route, kahit nag-forward ang host sa ibang lugar. Kaya mahalaga ang pagbasa ng buhay na interface at kaya ang global value lamang ay hindi ang buong sagot. Basahin ang gayong eksepsiyon bilang sadyang desisyon, at isulat kung bakit iba ang interface na iyon. Kung hindi, ang susunod na engineer ay "aayusin" ito nang may kabaitan.

Gawing permanente ang setting sa tamang lugar

Isang matagumpay na isang-beses na sysctl -w ang nagpapatunay na tinatanggap ng kernel ang value. Hindi ito nakakaligtas sa reboot, at hindi rin nakakaligtas sa network manager na naglalapat muli ng sarili nitong ideya ng configuration ng interface kapag kumonekta muli. Ilagay ang papel ng gateway sa configuration file ng sysctl o sa network manager na nagmamay-ari ng host, pagkatapos ay i-restart ang serbisyong naglalapat nito.

Mahalaga ang pagkakasunod-sunod sa mga tunnel. Kung ang manager ay gumagawa ng interface sa boot at inilalapat ang forwarding pagkatapos, maaaring mamanahin ng interface ang lumang default. Ang pag-restart ng serbisyong gumagawa muli ng tunnel ay isa ring kaganapan ng paglikha, at madaling makaligtaan kapag mukhang malusog ang unit. Suriin ang pagkakasunod-sunod, hindi lamang ang huling nilalaman ng file.

Basahin muli ang parehong tatlong value pagkatapos kumonekta muli ang VPN at muli pagkatapos ng reboot. Ang bagong likhang tunnel ay bagong interface, at ang bagong interface ay kumukuha ng default na umiiral sa sandali ng paglikha. Kung nagbabago ang mga numero sa mga kaganapang iyon, may isang bagay na hindi mo pa natukoy ang naglalapat ng configuration.

Huwag ayusin ito gamit ang maling tool

Nang mukhang sira ang forwarding, ang tukso ay i-flush ang firewall o magdagdag ng masquerading. Wala sa dalawa ang tumutugon sa switch ng forwarding. Ang estado ng forwarding, ang pahintulot na mag-forward, isang ruta patungo sa destinasyon at isang daan pabalik ay apat na hiwalay na pangangailangan, at ang una lamang ang sysctl.

Subukan din gamit ang tamang daloy. Ang kahilingang ginawa sa gateway mismo ay hindi nagsasanay ng forwarding kahit kaunti; ito ay trapikong nabuo sa lokal. Ang tanong ay kung ang packet na dumarating mula sa kliyente ng VPN o host ng LAN ay tinatanggap at ini-route pasulong, kaya ang pagsubok ay dapat magmula sa likod ng gateway.

Ihiwalay ang kaso ng IPv6

Ang lahat dito ay IPv4. Ang forwarding ng IPv6, mga anunsyo ng router at pag-uugali ng accept_ra ay may sariling kontrol, at ang pagkopya ng ruta ipv4 sa setting na ipv6 ay gumagawa ng file na mukhang kapani-paniwala at walang ginagawang kapaki-pakinabang. Ang gateway na may dalawang stack ay kailangang sadyang i-configure ang parehong set.

Isang huling pagsusuri: kapag nagtugma na ang mga value, tiyakin na ang ruta ng tunnel ay pinipili para sa destinasyon at umiiral ang daan ng tugon. Ang forwarding na naka-on sa isang interface na walang ruta ay butas pa rin, at ang kabiguan na iyon ay pareho ang hitsura mula sa panig ng kliyente.