Meitsje IPv4-trochstjoering duorsum oer in werstart fan ’e VPN-poarte

It pingjen fan ’e poarte wurket en it berikken fan wat efter it leit net, en dat is de foarm fan in trochstjoerprobleem, net fan in tunnelprobleem. Lokale levering oan ’e poarte bewizet dat de tunnel omheech kaam en dat de adresopdracht wurke; it seit neat oer de fraach oft de kernel in pakket fan ’e iene ynterface nei de oare trochjaan sil. Foardat jo wat sysctl oanreitsje, befêstigje dat de masine bedoeld is om dit ferkear te rûtesjen en fyn de netwurk-kontekst dy’t de klant-rjochte ynterface hâldt. Lês dan de wearde dêr, net dêr’t de lêste gids dy’t jo lesen tafallich seach.

De poarte berikke is net itselde as trochstjoere

Binnen de kernel falle twa aparte besluten. Levering oan in lokaal adres einiget de reis fan it pakket; trochstjoering stjoert it wer út troch in oare ynterface, en dy twadde beslissing wurdt regele per netwurk-namme romte. In poarte kin folslein berikber wêze wylst trochstjoering út is, en fan in ping-opdracht ôf lykje de beide flaters identyk.

Skriuw op op hokker ynterface it klantpakket oankomt en troch hokker ynterface it fierdere paad fuortgiet. Beide hearre by ien nammeromte, en dy nammeromte hâldt de ynstelling dy’t fan belang is.

Lês de wearde dêr’t de pakketten wirklik binne

Op in poarte dy’t yn ’e host-namme romte rûteset, beantwurdet ien opdracht de fraach: sysctl net.ipv4.ip_forward. As it yngeande en it fierdere paad yn in neamde nammeromte libje, freegje dan dy nammeromte: ip netns exec vpn-gw sysctl net.ipv4.ip_forward. De host-wearde ferfangt de nammeromte-wearde net, en in ien op ’e host is gjin bewiis foar wat dan ek.

Net elke rûtesjende kontekst hat in label dat jo oan ip netns jaan kinne. Konteiner-runtime-omjouwings en tsjinsten meitsje nammeromten dy’t nea ûnder in freonlike namme registrearre wurde, en foar dy brûke jo de ynspeksje-ark fan ’e runtime. Ferfang vpn-gw troch de echte namme, of troch it runtime-meganisme dat deselde kontekst berikt, en hâld op mei rieden op host-nivo.

Jou de ynstelling ien eigner

Op in konvinsjonele systemd-hostpoarte is de duorsume foarm in drop-in-bestân mei in troch de behearder keazen namme, lykas /etc/sysctl.d/60-vpn-forwarding.conf, dat net.ipv4.ip_forward = 1 befettet. Skriuw it bestân, en laad dan krekt dat bestân sadat de libbene steat ek feroaret: sudo sysctl -p /etc/sysctl.d/60-vpn-forwarding.conf, folge troch in weromlêzing. De bestânsnamme is in foarbyld en gjin reservearre VPN-paad, en it liedende nûmer is fan belang om’t letter sorteare bestannen winne.

Prioriteit is it plak dêr’t duorsumheid stil brekt. Kontrolearje sawol de lader fan ’e distribúsje as jo eigen drop-in, want procps sysctl --system lêst oan ’e ein ek /etc/sysctl.conf, wylst de sysctl.d-oarder fan systemd in hiel oare sekwinsje is. In lettere tawizing kin deselde kaai daliks weromsette, wêrtroch jo bestân korrekt bliuwt en de effektive wearde ferkeard. Net oerskriuwe fan in besteand beheardersbestân om dy diskusje te winnen; fyn de eigner en feroarje it dêr.

In nammeromte dy’t nei de opstart oanmakke is, wurdt hielendal net regele troch in host-drop-in. De ynstelling fan dy romte heart by wat it makket, itsij de konteiner-runtime of de foarsjenning-ienheid foar de nammeromte. In konteiner brede host-befiehjouwingen jaan om de fraach te ûntwiken is in minner ruil as tsien minuten besteegje oan it finen fan ’e juste eigner.

Wit wat de skeakel kostet foardat jo him omsette

ip_forward is gjin ûnskatlik boolean. De kernel-dokumintaasje merkt op dat it feroarjen derfan ferskate oare IPv4-parameters weromset nei har host- of rûtesjende standertwearden, sadat in diagnostyske omset tuning dy’t earne oars dien is fuortsmite kin en dat nea neamt. Behannelje it as in konfiguraasjeferoaring mei bywurkingen, net as in probe dy’t jo los rinne litte kinne.

Dat slút ek út om it eltse kear út en oan te setten as in klant in host net berikke kin. As de wearde al ien is, leit de flater earne oars op it paad, en itselde kaai in tredde kear oerskriuwe sil it net ferpleatse.

Bewize duorsumheid, en test dan de rest fan it paad

Lês de wearde werom op fjouwer mominten: daliks nei de feroaring, neidat de VPN-ynterface ferskynt, nei in werferbining en nei in plande werstart. In wearde dy’t op ien fan dy punten weromspringt hat in twadde eigner, en noch in ienmalige skriuwerij ferstoppet dat allinne oant de folgjende werstart.

Oansette trochstjoering lit noch trije dingen te kontrolearjen. De klant hat in rûte nei de bestimming nedich, de poarte hat in fierder paad plus tastimming om it te brûken nedich, en de bestimming hat in werompaad nei it tunneladres fan ’e klant nedich. In privee rûtesjend LAN hat net automatysk NAT nedich, dus foegje gjin masquerading ta foardat jo witte hokker fan ’e trije mist, en test fan ’e bedoelde klant ôf ynstee fan fan ’e poarte sels, want in fersyk dat op ’e poarte begûn is, rekket nea it trochstjoerpaad dat jo krekt oansetten hawwe. IPv6 draacht syn eigen trochstjoer- en rûtesjend belied, dus in wurkjende IPv4-test seit dêr neat oer.

Hâld it drop-in-paad, de eigner fan ’e nammeromte en de weromlês-opdracht byinoar yn ’e runbook. Wa’t dit folgjende oannimt moat de wearde lêze, sjen kinne wa’t it besit, en binnen in minút beslute kinne oft it probleem duorsumheid is of de rest fan it paad.