Pse net.ipv4.conf.default.forwarding e lë tun0 të paprekur

Ju vendosët net.ipv4.conf.default.forwarding=1, rinisni VPN-në, dhe tuneli ende hedh poshtë paketat që gateway-i duhet t'i rutojë. Cilësimi duket i saktë në skedar, dhe ndërfaqja ende raporton se përcjellja është e çaktivizuar. Asgjë nuk është prishur: ju ndryshuat vlerën që ndërfaqet e ardhshme trashëgojnë, jo atë që përdor tuneli aktiv.

Kalojeni këtë në hostin që zotëron tunelin, në namespace-in e rrjetit ku tuneli ekziston vërtet. Një kontejner ose një namespace rrjeti mund ta mbajë ndërfaqen ndërsa hosti shfaq numra të tjerë.

Lexoni tre vlerat së bashku

Filloni duke krahasuar çelësin e të gjithë gateway-it, shabllonin për ndërfaqet e reja dhe ndërfaqen që ju intereson. Zëvendësoni tun0 me ndërfaqen reale hyrëse, dhe lexoni edhe ndërfaqen e kthimit, sepse përcjellja vlerësohet në pikën ku mbërrin paketa.

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

Një rezultat i zakonshëm është ip_forward = 0, default.forwarding = 1 dhe tun0.forwarding = 0. Dy të parat nuk pajtohen për rolin e hostit, dhe i treti tregon çfarë bën vërtet ndërfaqja. Ky kombinim përputhet me një host që nuk u konfigurua kurrë si router, por mori vetëm një vlerë shablloni. Tre numrat nuk kundërshtojnë njëri-tjetrin; ata përgjigjen për tre pyetje të ndryshme. Edhe shkrimi i vlerës së shabllonit nuk e vendos rolin e hostit.

Pse lëviz pikërisht çelësi global

net.ipv4.ip_forward është kontrolli i të gjithë gateway-it. Ndryshimi i tij përditëson cilësimet e përcjelljes për secilën ndërfaqe si pjesë e të njëjtit veprim, prandaj një shkrim i vetëm mund ta bëjë një tunel ekzistues të fillojë të përcjellë. default.forwarding mbin vetëm ndërfaqet që inicializohen më pas, kështu që një tunel që ekzistonte tashmë ruan vlerën me të cilën lindi.

Dokumentacioni i kernelit e shënon ip_forward si të veçantë për një arsye të lidhur: ndryshimi i tij rivendos një grup parametrash të tjerë IPv4 në vlerat e paracaktuara të hostit ose routerit. Kjo e bën atë një mjet të pagdhendur. Vendosja e tij një herë si pjesë e krijimit të rolit të gateway-it është në rregull; ndërrimi i tij vazhdimisht si truk korrigjimi mund të rishkruajë në heshtje një konfigurim për të cilin keni harxhuar kohë.

Vlerat për secilën ndërfaqe ekzistojnë gjithashtu për një arsye. Një gateway i administruar me qëllim mund ta mbajë përcjelljen të fikur në një ndërfaqe që nuk duhet të rutojë kurrë, edhe kur hosti përcjell diku tjetër. Prandaj ka rëndësi leximi i ndërfaqes aktive dhe prandaj vlera globale e vetme nuk është përgjigja e plotë. Lexojeni një përjashtim të tillë si një vendim të qëllimshëm, dhe shkruani pse ajo ndërfaqe është ndryshe. Përndryshe inxhinieri tjetër do ta "rregullojë" me dashamirësi.

Bëjeni cilësimin të përhershëm në vendin e duhur

Një sysctl -w i vetëm i suksesshëm dëshmon se kernel-i e pranon vlerën. Ai nuk mbijeton një rindezje, dhe nuk mbijeton një menaxher rrjeti që rizbaton idenë e vet për konfigurimin e ndërfaqes kur rilidhet. Vendoseni rolin e gateway-it në skedarin e konfigurimit sysctl ose në menaxherin e rrjetit që zotëron hostin, pastaj rinisni shërbimin që e zbaton.

Rendi ka rëndësi me tunelet. Nëse menaxheri e krijon ndërfaqen në nisje dhe e zbaton përcjelljen më pas, ndërfaqja mund të trashëgojë parazgjedhjen e vjetër. Rinisja e një shërbimi që e rikrijon tunelin është gjithashtu një ngjarje krijimi, dhe është e lehtë ta anashkalosh kur njësia duket e shëndetshme. Kontrolloni sekuencën, jo vetëm përmbajtjen përfundimtare të skedarit.

Rilexoni të njëjtat tre vlera pasi VPN të rilidhet dhe edhe një herë pas një rindezjeje. Një tunel i sapokrijuar është një ndërfaqe e re, dhe një ndërfaqe e re merr parazgjedhjen në fuqi në momentin e krijimit. Nëse numrat ndryshojnë mes këtyre ngjarjeve, konfigurimin po e zbaton diçka që nuk e keni identifikuar ende.

Mos e rregulloni këtë me mjetin e gabuar

Kur përcjellja dukej e prishur, tundimi është të zbrazni firewall-in ose të shtoni masquerading. Asnjëra nuk merret me çelësin e përcjelljes. Gjendja e përcjelljes, leja për të përcjellë, një rrugë drejt destinacionit dhe një rrugë kthimi janë katër kërkesa të ndara, dhe vetëm e para është sysctl.

Testoni edhe me rrjedhën e duhur. Një kërkesë e bërë në vetë gateway-in nuk e ushtron fare përcjelljen; është trafik i gjeneruar lokalisht. Pyetja është nëse një paketë që vjen nga një klient VPN ose nga një host LAN pranohet dhe rutohet më tej, prandaj testi duhet të nisë pas gateway-it.

Mbajeni rastin IPv6 veçmas

Këtu gjithçka është IPv4. Përcjellja IPv6, njoftimet e routerit dhe sjellja e accept_ra kanë kontrollin e tyre, dhe kopjimi i një rrugë ipv4 në një cilësim ipv6 prodhon një skedar që duket i besueshëm dhe nuk bën asgjë të dobishme. Një gateway me dy stiva ka nevojë që të dyja grupet të konfigurohen me qëllim.

Një kontroll i fundit: pasi vlerat të përputhen, konfirmoni se rruga e tunelit zgjidhet për destinacionin dhe se rruga e përgjigjes ekziston. Përcjellja e aktivizuar në një ndërfaqe pa rrugë mbetet një vrimë e zezë, dhe ai dështim duket njësoj nga ana e klientit.