Kial net.ipv4.conf.default.forwarding lasas tun0 netuŝita

Vi agordis net.ipv4.conf.default.forwarding=1, restartigis la VPN, kaj la tunelo ankoraŭ faligas pakaĵojn, kiujn la kluzo devus enkursigi. La agordo aspektas ĝusta en la dosiero, kaj la interfaco ankoraŭ raportas, ke plusendado estas malŝaltita. Nenio rompiĝis: vi ŝanĝis la valoron, kiun heredas estontaj interfacoj, ne tiun, kiun uzas la viva tunelo.

Trairu ĉi tion sur la gastiganto, kiu posedas la tunelon, en la reta namespace, kie la tunelo efektive ekzistas. Ujo aŭ reta namespace povas teni la interfacon dum la gastiganto montras aliajn nombrojn.

Legu la tri valorojn kune

Komencu komparante la ŝaltilon por la tuta kluzo, la ŝablonon por novaj interfacoj kaj la interfacon, kiu gravas al vi. Anstataŭigu tun0 per la reala enira interfaco, kaj legu ankaŭ la revenan interfacon, ĉar plusendado estas taksata en la punkto, kie la pakaĵo alvenas.

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

Ofte rezultas ip_forward = 0, default.forwarding = 1 kaj tun0.forwarding = 0. La unuaj du malkonsentas pri la rolo de la gastiganto, kaj la tria montras, kion la interfaco efektive faras. Tiu kombinaĵo kongruas kun gastiganto, kiu neniam estis agordita kiel enkursigilo, sed nur ricevis ŝablonan valoron. La tri nombroj ne kontraŭdiras unu la alian; ili respondas al tri malsamaj demandoj. Ankaŭ skribi la ŝablonan valoron ne decidas la rolon de la gastiganto.

Kial moviĝas ĝuste la tutmonda ŝaltilo

net.ipv4.ip_forward estas la regado por la tuta kluzo. Ŝanĝi ĝin ĝisdatigas la plusendajn agordojn por ĉiu interfaco kiel parton de la sama operacio, tial unu skribo povas igi ekzistantan tunelon komenci plusendi. default.forwarding semas nur interfacojn, kiuj estas pravalorizitaj poste, do tunelo, kiu jam ekzistis, konservas la valoron, kun kiu ĝi naskiĝis.

La dokumentaro de la kerno markas ip_forward kiel specialan pro rilata kialo: ŝanĝi ĝin restarigas aron da aliaj IPv4-parametroj al la aprioraĵoj por gastiganto aŭ enkursigilo. Tio faras ĝin maldelikata ilo. Agordi ĝin unufoje kadre de starigo de la kluzorolo estas en ordo; ŝalti ĝin ripete kiel sencimigan artifikon povas silente reĉiri agordon, kiun vi pasigis tempon akordigi.

Valoroj por ĉiu interfaco ankaŭ ekzistas pro kialo. Intence administrata kluzo povas teni plusendadon malŝalta sur interfaco, kiu neniam rajtas enkursigi, eĉ dum la gastiganto plusendas aliloke. Tial gravas legi la vivan interfacon kaj tial la tutmonda valoro sola ne estas la tuta respondo. Legu tian escepton kiel konscian decidon, kaj notu, kial tiu interfaco diferencas. Alie la sekva inĝeniero helpeme "ripari" ĝin.

Faru la agordon daŭra en la ĝusta loko

Sukcesa unufoja sysctl -w pruvas, ke la kerno akceptas la valoron. Ĝi ne postvivas restartigon, kaj ĝi ne postvivas retadministrilon, kiu dum rekonekto reaplikas sian propran ideon pri la interfaca agordo. Metu la kluzorolon en la sysctl-agordan dosieron aŭ en la retadministrilon, kiu posedas la gastiganton, poste restartigu la servon, kiu aplikas ĝin.

La ordo gravas ĉe tuneloj. Se la administrilo kreas la interfacon ĉe lanĉo kaj aplikas plusendadon poste, la interfaco povas heredi la malnovan aprioraĵon. Restartigo de servo, kiu rekreas la tunelon, ankaŭ estas krea evento, kaj facile preteratentebla kiam la unuo aspektas sana. Kontrolu la sinsekvon, ne nur la finan dosieran enhavon.

Legu la samajn tri valorojn denove post kiam la VPN rekonektiĝas kaj ankoraŭfoje post restartigo. Ĵus kreita tunelo estas nova interfaco, kaj nova interfaco prenas la aprioraĵon validan en la krea momento. Se la nombroj ŝanĝiĝas tra tiuj eventoj, la agordon aplikas io, kion vi ankoraŭ ne identigis.

Ne riparu ĉi tion per la malĝusta ilo

Kiam plusendado aspektis rompita, la tento estas malplenigi la fajroŝirmilon aŭ aldoni masquerading. Neniu el la du traktas la plusendan ŝaltilon. Plusenda stato, permeso plusendi, itinero al la celo kaj revena vojo estas kvar apartaj postuloj, kaj nur la unua estas la sysctl.

Testu ankaŭ per la ĝusta fluo. Peticio farita sur la kluzo mem tute ne ekzercas plusendadon; ĝi estas loke generita trafiko. La demando estas, ĉu pakaĵo alvenanta de VPN-kliento aŭ de LAN-gastiganto estas akceptata kaj plusendata, do la testo devas origini malantaŭ la kluzo.

Tenu la IPv6-kazon aparte

Ĉio ĉi estas IPv4. IPv6-plusendado, enkursigilaj anoncoj kaj la konduto de accept_ra havas proprajn regilojn, kaj kopii itineron por ipv4 en ipv6 agordon produktas dosieron, kiu aspektas kredinda kaj faras nenion utilan. Kluzo kun du stakoj bezonas ambaŭ arojn konscie agorditaj.

Lasta kontrolo: post kiam la valoroj kongruas, konfirmu, ke la itinero de la tunelo estas elektita por la celo kaj ke la responda vojo ekzistas. Plusendado ŝaltita sur interfaco sen itinero restas nigra truo, kaj tiu fiasko aspektas same de la klienta flanko.