Faru IPv4-plusendadon daŭra post restartiĝo de VPN-enirejo

Pingi la enirejon funkcias, sed atingi ion ajn malantaŭ ĝi ne, kaj tio estas la formo de plusendada problemo, ne de tunela problemo. Loka livero al la enirejo pruvas, ke la tunelo ekfunkciis kaj ke la adresa atribuo sukcesis; ĝi diras nenion pri tio, ĉu la kerno pasigos pakon de unu interfaco al alia. Antaŭ ol tuŝi iun ajn sysctl, konfirmu, ke la maŝino estas destinita por enkursigi ĉi tiun trafikon kaj lokalizu la retan kuntekston, kiu tenas la klient-facajn interfacon. Poste legu la valoron tie, ne tie, kien hazarde rigardis la lasta gvidilo, kiun vi legis.

Atingi la enirejon ne samas al plusendi

Du apartaj decidoj okazas interne de la kerno. Livero al loka adreso finas la vojaĝon de la pako; plusendo sendas ĝin denove eksteren tra alia interfaco, kaj tiu dua decido estas regata laŭ reta nomspaco. Enirejo povas esti perfekte atingebla dum plusendo estas malŝaltita, kaj el ping-prompt la du paneoj aspektas identaj.

Notu, sur kiun interfacon alvenas la klienta pako kaj tra kiu interfaco eliras la plua vojo. Ambaŭ apartenas al unu nomspaco, kaj tiu nomspaco tenas la agordon, kiu gravas.

Legu la valoron tie, kie la pakoj efektive estas

Sur enirejo, kiu enkursigas en la gastiga nomspaco, unu komando respondas la demandon: sysctl net.ipv4.ip_forward. Kiam la enira kaj plua vojo loĝas en nomita nomspaco, demandu tiun nomspacon: ip netns exec vpn-gw sysctl net.ipv4.ip_forward. La gastiga valoro ne estas anstataŭaĵo por la nomspaca valoro, kaj unuo sur la gastiga ne estas pruvo de io ajn.

Ne ĉiu enkursiga kunteksto havas etikedon, kiun vi povas doni al ip netns. Ujo-rultemoj kaj servoj kreas nomspacojn, kiuj neniam estas registritaj sub amika nomo, kaj por tiuj vi uzas la inspektilojn de la rultemo. Anstataŭigu vpn-gw per la reala nomo, aŭ per la rultema mekanismo, kiu atingas la saman kuntekston, kaj ĉesu diveni ĉe la gastiga nivelo.

Donu al la agordo unu solan posedanton

Sur konvencia systemd-gastiga enirejo la daŭra formo estas drop-in-dosiero kun administranto-elektita nomo kiel /etc/sysctl.d/60-vpn-forwarding.conf, enhavanta net.ipv4.ip_forward = 1. Skribu la dosieron, poste ŝargu ĝuste tiun dosieron, por ke ankaŭ la viva stato ŝanĝiĝu: sudo sysctl -p /etc/sysctl.d/60-vpn-forwarding.conf, sekvata de religo. La dosiernomo estas ekzemplo, ne rezervita VPN-vojo, kaj la komenca nombro gravas, ĉar dosieroj ordigitaj pli malfrue venkas.

Prioritato estas la loko, kie daŭreco kviete rompiĝas. Kontrolu kaj la distribuadan ŝargilon kaj vian propran drop-in, ĉar procps sysctl --system ankaŭ legas /etc/sysctl.conf ĉe la fino, dum la sysctl.d-ordo de systemd estas tute alia sinsekvo. Pli malfrua atribuo povas rekte remeti la saman ŝlosilon, lasante vian dosieron ĝusta kaj la efektivan valoron malĝusta. Ne superskribu ekzistantan administrantan dosieron por venki tiun disputon; trovu la posedanton kaj ŝanĝu ĝin tie.

Nomspaco kreita post la lanĉo tute ne estas regata de gastiga drop-in. Ĝia agordo apartenas al tio, kio ĝin kreas, ĉu la uja rultemo ĉu la proviz-unuo por la nomspaco. Doni al ujo larĝajn gastigajn privilegiojn por eviti la demandon estas pli malbona interŝanĝo ol pasigi dek minutojn identigante la ĝustan posedanton.

Sciu, kion la ŝaltilo kostas antaŭ ol ĝin ŝalti

ip_forward ne estas sendanĝera bulea valoro. La kern-dokumentaro notas, ke ŝanĝi ĝin restarigas plurajn aliajn IPv4-parametrojn al iliaj gastigaj aŭ enkursigilaj defaŭltoj, do diagnoza ŝalto povas forĵeti agordojn faritajn aliloke kaj neniam mencii tion. Traktu ĝin kiel konfiguran ŝanĝon kun flankaj efikoj, ne kiel esploron, kiun oni povas senzorge lanĉi.

Tio ankaŭ ekskludas malŝalti kaj ŝalti ĝin ĉiufoje, kiam kliento ne povas atingi gastigan. Se la valoro jam estas unu, la paneo estas aliloke en la vojo, kaj reskribi la saman ŝlosilon trian fojon ne movos ĝin.

Pruvu daŭrecon, poste testu la reston de la vojo

Legu la valoron reen en kvar momentoj: tuj post la ŝanĝo, post kiam la VPN-interfaco aperas, post rekonekto kaj post planita restartigo. Valoro, kiu reiras ĉe iu ajn el tiuj punktoj, havas duan posedanton, kaj plia unufoja skribo nur kaŝas tion ĝis la sekva restartigo.

Ŝaltita plusendo ankoraŭ lasas tri aferojn por kontroli. La kliento bezonas vojon al la celo, la enirejo bezonas pluan vojon plus permeson uzi ĝin, kaj la celo bezonas revenan vojon al la tunela adreso de la kliento. Privata enkursigita LAN ne aŭtomate bezonas NAT, do ne aldonu masquerading antaŭ ol vi scios, kiu el la tri mankas, kaj testu de la intencita kliento anstataŭ de la enirejo mem, ĉar peto origininta sur la enirejo neniam tuŝas la plusendan vojon, kiun vi ĵus ŝaltis. IPv6 portas sian propran plusendan kaj enkursigan politikon, do funkcianta IPv4-testo diras nenion pri ĝi.

Tenu la drop-in-vojon, la nomspacan posedanton kaj la religan komandon kune en la runbook. Kiu prenos ĉi tion sekve devos povi legi la valoron, vidi, kiu posedas ĝin, kaj decidi ene de minuto, ĉu la problemo estas daŭreco aŭ la resto de la vojo.