Kodėl net.ipv4.conf.default.forwarding palieka tun0 ramybėje

Jūs nustatėte net.ipv4.conf.default.forwarding=1, iš naujo paleidote VPN, o tunelis vis dar meta paketus, kuriuos šliuzas turėtų maršrutizuoti. Nustatymas faile atrodo teisingai, o sąsaja vis dar praneša, kad persiuntimas išjungtas. Niekas nesugedę: pakeitėte reikšmę, kurią paveldės būsimos sąsajos, o ne tą, kurią naudoja veikiantis tunelis.

Peržiūrėkite tai tame hoste, kuriam priklauso tunelis, tame tinklo namespace, kuriame tunelis tikrai egzistuoja. Konteineris ar tinklo namespace gali laikyti sąsają, o hostas rodo kitus skaičius.

Skaitykite tris reikšmes kartu

Pradėkite lygindami viso šliuzo jungiklį, naujų sąsajų šabloną ir jus dominančią sąsają. Pakeiskite tun0 tikrąja įvesties sąsaja ir perskaitykite taip pat grįžtamąją sąsają, nes persiuntimas vertinamas tame taške, kuriame paketas atvyksta.

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

Dažnas rezultatas yra ip_forward = 0, default.forwarding = 1 ir tun0.forwarding = 0. Pirmieji du nesutaria dėl hosto vaidmens, o trečiasis parodo, ką sąsaja iš tikrųjų daro. Šis derinys atitinka hostą, kuris niekada nebuvo sukonfigūruotas kaip maršrutizatorius, o gavo tik šablono reikšmę. Trys skaičiai neprieštarauja vienas kitam; jie atsako į tris skirtingus klausimus. Šablono reikšmės įrašymas taip pat nenusprendžia hosto vaidmens.

Kodėl juda būtent globalus jungiklis

net.ipv4.ip_forward yra viso šliuzo valdymas. Jį pakeitus tos pačios operacijos metu atnaujinami kiekvienos sąsajos persiuntimo nustatymai, todėl vienas įrašas gali priversti esamą tunelį pradėti persiųsti. default.forwarding sėja tik po to inicializuojamas sąsajas, todėl jau egzistavęs tunelis išlaiko reikšmę, su kuria gimė.

Branduolio dokumentacija ip_forward žymi kaip ypatingą dėl susijusios priežasties: jį pakeitus grupė kitų IPv4 parametrų atstatomi į hosto ar maršrutizatoriaus numatytąsias reikšmes. Tai daro jį buką įrankiu. Nustatyti jį vieną kartą kaip šliuzo vaidmens nustatymo dalį yra gerai; perjunginėti jį kartodamas kaip derinimo triuką gali tyliai perrašyti konfigūraciją, kuriai sutvarkyti skyrėte laiko.

Kiekvienos sąsajos reikšmės taip pat egzistuoja dėl priežasties. Sąmoningai valdomas šliuzas gali palikti persiuntimą išjungtą sąsajoje, kuri niekada neturėtų maršrutizuoti, net kai hostas persiunčia kitur. Todėl svarbu skaityti veikiančią sąsają ir todėl vien globalios reikšmės nepakanka. Tokią išimtį skaitykite kaip sąmoningą sprendimą ir užsirašykite, kodėl ta sąsaja kitokia. Priešingu atveju kitas inžinierius ją mielai "sutvarkys".

Padarykite nustatymą nuolatiniu tinkamoje vietoje

Sėkmingas vienkartinis sysctl -w įrodo, kad branduolys priima reikšmę. Jis neišlieka po perkrovimo ir neišlieka po tinklo tvarkyklės, kuri prisijungdama iš naujo vėl taiko savo supratimą apie sąsajos konfigūraciją. Įdėkite šliuzo vaidmenį į sysctl konfigūracijos failą arba į tinklo tvarkyklę, kuriai priklauso hostas, tada iš naujo paleiskite paslaugą, kuri ją taiko.

Tuneliuose tvarka svarbi. Jei tvarkyklė sukuria sąsają įkrovimo metu, o persiuntimą taiko vėliau, sąsaja gali paveldėti seną numatytąją reikšmę. Paslaugos paleidimas iš naujo, kuris iš naujo sukuria tunelį, taip pat yra sukūrimo įvykis, ir jo lengva nepastebėti, kai unit atrodo sveikas. Tikrinkite seką, o ne tik galutinį failo turinį.

Dar kartą perskaitykite tas pačias tris reikšmes po to, kai VPN prisijungia iš naujo, ir dar kartą po perkrovimo. Naujai sukurtas tunelis yra nauja sąsaja, o nauja sąsaja paima perkrovimo momentu galiojančią numatytąją reikšmę. Jei skaičiai kinta tarp šių įvykių, konfigūraciją taiko kažkas, ko dar nenustatėte.

Netaisykite to netinkamu įrankiu

Kai persiuntimas atrodė sugedęs, kyla pagunda išvalyti ugniasienę arba pridėti masquerading. Nė vienas to neišsprendžia persiuntimo jungiklio. Persiuntimo būsena, leidimas persiųsti, maršrutas iki paskirties ir grįžimo kelias yra keturi atskiri reikalavimai, ir tik pirmasis yra sysctl.

Išbandykite ir tinkamu srautu. Užklausa, padaryta pačiame šliuze, visiškai nepratina persiuntimo; tai vietoje sugeneruotas srautas. Klausimas, ar paketas, atėjęs iš VPN kliento ar LAN hosto, priimamas ir nukreipiamas toliau, todėl bandymas turi prasidėti už šliuzo.

Laikykite IPv6 atvejį atskirai

Čia viskas yra IPv4. IPv6 persiuntimas, maršrutizatoriaus skelbimai ir accept_ra elgsena turi savo valdymą, o kopijuojant ipv4 kelią į ipv6 nustatymą gaunamas failas, kuris atrodo įtikinamai ir nedaro nieko naudingo. Dvigubo steko šliuzui reikia, kad abu rinkiniai būtų sąmoningai sukonfigūruoti.

Paskutinė patikra: kai reikšmės sutampa, patvirtinkite, kad tunelio maršrutas parenkamas paskirčiai ir kad grįžimo kelias egzistuoja. Įjungtas persiuntimas sąsajoje be maršruto vis tiek yra juoda skylė, ir ta gedimas iš kliento pusės atrodo vienodai.