Waarom net.ipv4.conf.default.forwarding tun0 onaangeraak laat

Jy stel net.ipv4.conf.default.forwarding=1, herbegin die VPN, en die tonnel laat steeds pakkette val wat die poort moet routeer. Die instelling lyk reg in die lêer, en die koppelvlak rapporteer steeds dat forwardering afgeskakel is. Niks is stukkend nie: jy het die waarde verander wat toekomstige koppelvlakke erf, nie die een wat die lewende tonnel gebruik nie.

Werk dit deur op die gasheer wat die tonnel besit, in die netwerknaamruimte waar die tonnel werklik bestaan. 'n Houer of 'n netwerknaamruimte kan die koppelvlak hou terwyl die gasheer ander syfers wys.

Lees die drie waardes saam

Begin deur die poortwye skakelaar, die sjabloon vir nuwe koppelvlakke en die koppelvlak wat jou aangaan te vergelyk. Vervang tun0 met die werklike inkomende koppelvlak, en lees ook die terugkeerkoppelvlak, want forwardering word geëvalueer by die punt waar die pakket aankom.

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

'n Algemene uitslag is ip_forward = 0, default.forwarding = 1, en tun0.forwarding = 0. Die eerste twee stem nie saam oor die gasheer se rol nie, en die derde wys wat die koppelvlak werklik doen. Daardie kombinasie pas by 'n gasheer wat nooit as 'n routeerder opgestel is nie, net 'n sjabloonwaarde gekry het. Die drie syfers weerspreek mekaar nie; hulle beantwoord drie verskillende vrae. Om die sjabloonwaarde te skryf besluit ook nie die gasheer se rol nie.

Waarom die globale skakelaar die een is wat beweeg

net.ipv4.ip_forward is die poortwye beheer. Om dit te verander werk die per-koppelvlak-forwarderingsinstellings as deel van dieselfde bewerking by, en daarom kan 'n enkele skryf 'n bestaande tonnel laat forwardeer. default.forwarding saai net koppelvlakke wat daarna geïnisialiseer word, so 'n tonnel wat al bestaan het, hou die waarde waarmee dit gebore is.

Die kern se dokumentasie merk ip_forward as spesiaal om 'n verwante rede: om dit te verander stel 'n stel ander IPv4-parameters terug na gasheer- of routeerderverstekke. Dit maak dit 'n stomp instrument. Om dit een keer te stel as deel van die vestiging van die poortrol is goed; om dit herhaaldelik as 'n ontfouttruuk te wissel, kan stilweg konfigurasie herskryf wat jy tyd bestee het om reg te kry.

Per-koppelvlak-waardes bestaan ook om 'n rede. 'n Doelbewus bestuurde poort kan forwardering af hou op 'n koppelvlak wat nooit moet routeer nie, selfs terwyl die gasheer elders forwardeer. Daarom maak dit saak om die lewende koppelvlak te lees, en daarom is die globale waarde alleen nie die hele antwoord nie. Lees so 'n uitsondering as 'n doelbewuste besluit, en skryf neer waarom daardie koppelvlak anders is. Anders sal die volgende ingenieur dit hulpvaardig "regmaak".

Maak die instelling blywend op die regte plek

'n Suksesvolle eenmalige sysctl -w bewys die kern aanvaar die waarde. Dit oorleef nie 'n herbegin nie, en dit oorleef nie 'n netwerkbestuurder wat by herverbinding weer sy eie idee van die koppelvlakkonfigurasie toepas nie. Sit die poortrol in die sysctl-konfigurasielêer of in die netwerkbestuurder wat die gasheer besit, en herbegin dan die diens wat dit toepas.

Volgorde maak saak by tonnels. As die bestuurder die koppelvlak by selflaai skep en forwardering daarna toepas, kan die koppelvlak die ou verstek erf. 'n Diensherbegin wat die tonnel herskep, is ook 'n skeppingsgebeurtenis, en dit is maklik om mis te kyk wanneer die eenheid gesond lyk. Kyk na die volgorde, nie net na die finale lêerinhoud nie.

Lees dieselfde drie waardes weer nadat die VPN herverbind het en weer ná 'n herbegin. 'n Nuutgeskepte tonnel is 'n nuwe koppelvlak, en 'n nuwe koppelvlak neem die verstek wat op skeppingstyd geld. As die syfers oor daardie gebeure verander, word die konfigurasie toegepas deur iets wat jy nog nie geïdentifiseer het nie.

Moenie dit met die verkeerde gereedskap regmaak nie

Toe forwardering stukkend gelyk het, is die versoeking om die firewall te spoel of masquerading by te voeg. Nie een van die twee spreek die forwarderingskakelaar aan nie. Forwarderingstoestand, toestemming om te forwardeer, 'n roete vir die bestemming en 'n terugpad is vier aparte vereistes, en net die eerste een is die sysctl.

Toets ook met die regte vloei. 'n Versoek wat op die poort self gemaak word, oefen glad nie forwardering nie; dit is plaaslik gegenereerde verkeer. Die vraag is of 'n pakket wat van 'n VPN-kliënt of 'n LAN-gasheer kom, aanvaar en verder gerouteer word, so die toets moet agter die poort ontstaan.

Hou die IPv6-geval apart

Alles hier is IPv4. IPv6-forwardering, routeraankondigings en die accept_ra-gedrag het hulle eie beheer, en om 'n ipv4-pad in 'n ipv6-instelling te kopieer, lewer 'n lêer wat geloofwaardig lyk en niks nuttigs doen nie. 'n Dubbelstapel-poort moet albei stelle doelbewus opgestel hê.

Een laaste kontrole: nadat die waardes ooreenstem, bevestig dat die tonnel se roete vir die bestemming gekies word en dat die antwoordpad bestaan. Forwardering wat op 'n koppelvlak sonder roete aangeskakel is, is steeds 'n swart gat, en daardie fout lyk van die kliënt se kant identies.