Jo sette net.ipv4.conf.default.forwarding=1, starte de VPN op 'e nij, en de tunnel smyt noch hieltyd pakketten weilitten dy't de gateway routere moatte. De ynstelling liket goed yn it bestân, en de ynterface meldt noch hieltyd dat troerstjoer útskeakele is. Neat is stikken: jo hawwe de wearde feroare dy't takomstige ynterfaces ervje, net dy't de libbene tunnel brûkt.

Wurket dit troch op 'e host dy't de tunnel hat, yn 'e netwurk-namespace dêr't de tunnel echt bestiet. In kontener of in netwurk-namespace kin de ynterface hâlde wylst de host oare sifers lit sjen.

Lês de trije wearden tegearre

Begjin mei it ferlykjen fan 'e gateway-wide skeakel, it sjabloan foar nije ynterfaces en de ynterface dy't jo oangiet. Ferfang tun0 troch de echte ynkommende ynterface, en lês ek de weromynterface, want troerstjoer wurdt beoardiele op it punt dêr't it pakket oankomt.

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

In gewoan resultaat is ip_forward = 0, default.forwarding = 1 en tun0.forwarding = 0. De earste twa binne it net iens oer de rol fan 'e host, en de tredde lit sjen wat de ynterface echt docht. Dy kombinaasje past by in host dy't nea as router konfigurearre waard, mar allinnich in sjabloanwearde krige. De trije sifers sprekke inoar net tsjin; se beäntwurdzje trije ferskillende fragen. It skriuwen fan 'e sjabloanwearde beslist ek net de rol fan 'e host.

Wêrom't de globale skeakel de iene is dy't beweecht

net.ipv4.ip_forward is de gateway-wide kontrôle. It feroarjen derfan bywurket de troerstjoerynstellings per ynterface as diel fan deselde operaasje, dêrom kin ien skriuwerij in besteande tunnel begjinne te troerstjoeren. default.forwarding siedet allinnich ynterfaces dy't dêrnei inisjalisearre wurde, dus in tunnel dy't al bestie hâldt de wearde dêr't er mei berne waard.

De kernel-dokumintaasje markearret ip_forward as bysûnder om in besibbe reden: it feroarjen derfan set in rige oare IPv4-parameters werom nei de standertwearden foar host of router. Dat makket it in stomp helpmiddel. It ien kear ynstelle as diel fan it fêstigjen fan 'e gatewayrol is goed; it hieltyd wer omskeakelje as debugtruc kin stilwei konfiguraasje oerskriuwe dêr't jo tiid oan bestege hawwe om it goed te krijen.

Wearden per ynterface besteane ek om in reden. In bewust beheard gateway kin troerstjoer útlitte op in ynterface dat nea routere moat, sels wylst de host earne oars troerstjoert. Dêrom is it wichtich de libbene ynterface te lêzen en dêrom is de globale wearde allinnich net it hiele antwurd. Lês sa'n útsûndering as in bewuste beslissing, en skriuw op wêrom't dy ynterface oars is. Oars sil de folgjende yngenieur it helpend "reparearje".

Meitsje de ynstelling doerhâldend op 'e goede plak

In suksesfolle ienmalige sysctl -w bewiist dat de kernel de wearde akseptearret. It oerlibbet gjin werstart, en it oerlibbet gjin netwurkbehearder dy't by it opnij ferbinen syn eigen idee fan 'e ynterfacekonfiguraasje wer tapast. Set de gatewayrol yn it sysctl-konfiguraasjebestân of yn 'e netwurkbehearder dy't de host hat, en start dan de tsjinst op 'e nij dy't it tapast.

Oarder is wichtich by tunnels. As de behearder de ynterface by it opstarten makket en troerstjoer dêrnei tapast, kin de ynterface de âlde standert ervje. In tsjinstwerstart dy't de tunnel opnij makket is ek in skeppingsbarren, en dat is maklik te missen as de unit sûn liket. Kontrolearje de folchoarder, net allinnich de definitive ynhâld fan it bestân.

Lês deselde trije wearden op 'e nij nei't de VPN wer ferbûn is en nochris nei in werstart. In nij makke tunnel is in nije ynterface, en in nije ynterface nimt de standert dy't jildt op it stuit fan skepping. As de sifers oer dy barren feroarje, wurdt de konfiguraasje tapast troch eat dat jo noch net identifisearre hawwe.

Reparearje dit net mei it ferkearde helpmiddel

Doe't troerstjoer stikken like, is de ferlieding om de firewall te leegjen of masquerading ta te foegjen. Gjin fan beide rjochtet him op 'e troerstjoerskeakel. Troerstjoerstatus, tastimming om troer te stjoeren, in rûte foar de bestemming en in weromwei binne fjouwer aparte easken, en allinnich de earste is de sysctl.

Test ek mei de goede stream. In fersyk op 'e gateway sels oefenet hielendal gjin troerstjoer; it is lokaal generearre ferkear. De fraach is oft in pakket dat fan in VPN-klant of in LAN-host komt akseptearre en fierder routere wurdt, dus de test moat efter de gateway begjinne.

Hâld it IPv6-gefal apart

Hjir is alles IPv4. IPv6-troerstjoer, routeroanbefellingen en it accept_ra-gedrach hawwe har eigen kontrôles, en it kopiearjen fan in ipv4-paad yn in ipv6-ynstelling makket in bestân dat leauwich liket en neat nuttich docht. In dual-stack-gateway hat beide sets bewust konfigurearre nedich.

In lêste kontrôle: as de wearden oerienkomme, befêstigje dan dat de rûte fan 'e tunnel foar de bestemming keazen wurdt en dat de antwurdwei bestiet. Troerstjoer oan op in ynterface sûnder rûte is noch hieltyd in swart gat, en dy flater liket fan 'e kliïntkant itselde.

Relatearre artikelen