Kāpēc net.ipv4.conf.default.forwarding atstāj tun0 mierā

Jūs iestatījāt net.ipv4.conf.default.forwarding=1, pārstartējāt VPN, un tunelis joprojām izmet paketes, kuras vārtejai vajadzētu maršrutēt. Iestatījums failā izskatās pareizs, un saskarne joprojām ziņo, ka pārsūtīšana ir izslēgta. Nekas nav salūzis: jūs nomainījāt vērtību, ko mantos nākamās saskarnes, nevis to, ko izmanto aktīvais tunelis.

Izstaigājiet to uz resursdatora, kuram pieder tunelis, tajā tīkla namespace, kur tunelis patiešām pastāv. Konteiners vai tīkla namespace var turēt saskarni, kamēr resursdators rāda citus skaitļus.

Lasiet trīs vērtības kopā

Sāciet ar vārtejas mēroga slēdža, jauno saskarņu veidnes un jūs interesējošās saskarnes salīdzināšanu. Aizstājiet tun0 ar reālo ienākošo saskarni un izlasiet arī atgriešanās saskarni, jo pārsūtīšana tiek novērtēta tajā punktā, kur pakete ierodas.

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

Bieži sastopams rezultāts ir ip_forward = 0, default.forwarding = 1 un tun0.forwarding = 0. Pirmās divas nesaskan par resursdatora lomu, un trešā parāda, ko saskarne patiešām dara. Šī kombinācija atbilst resursdatoram, kas nekad nav konfigurēts kā maršrutētājs, bet ir saņēmis tikai veidnes vērtību. Trīs skaitļi nav pretrunā viens ar otru; tie atbild uz trim dažādiem jautājumiem. Arī veidnes vērtības ierakstīšana neizlemj resursdatora lomu.

Kāpēc kustas tieši globālais slēdzis

net.ipv4.ip_forward ir vārtejas mēroga vadība. Tā maiņa atjaunina pārsūtīšanas iestatījumus katrai saskarnei kā daļu no tās pašas operācijas, tāpēc viens ieraksts var likt esošam tunelim sākt pārsūtīt. default.forwarding iesēj tikai tās saskarnes, kas tiek inicializētas pēc tam, tāpēc tunelis, kas jau pastāvēja, saglabā vērtību, ar kuru tas piedzima.

Kodola dokumentācija atzīmē ip_forward kā īpašu saistīta iemesla dēļ: tā maiņa atiestata virkni citu IPv4 parametru uz resursdatora vai maršrutētāja noklusējumiem. Tas to padara par rupju instrumentu. Iestatīt to vienreiz vārtejas lomas izveides ietvaros ir labi; pārslēgt to atkārtoti kā atkļūdošanas triku var klusi pārrakstīt konfigurāciju, kurai veltījāt laiku.

Arī katras saskarnes vērtības pastāv iemesla dēļ. Apzināti pārvaldīta vārteja var turēt pārsūtīšanu izslēgtu saskarnē, kurai nekad nevajadzētu maršrutēt, pat ja resursdators pārsūta citur. Tāpēc ir svarīgi lasīt aktīvo saskarni un tāpēc vien ar globālo vērtību nepietiek. Lasiet šādu izņēmumu kā apzinātu lēmumu un pierakstiet, kāpēc šī saskarne atšķiras. Citādi nākamais inženieris to labvēlīgi "salabos".

Padariet iestatījumu pastāvīgu pareizajā vietā

Veiksmīgs vienreizējs sysctl -w pierāda, ka kodols pieņem vērtību. Tas neiztur atkārtotu palaišanu un neiztur arī tīkla pārvaldnieku, kas atkārtotas savienošanas laikā atkal piemēro savu priekšstatu par saskarnes konfigurāciju. Ievietojiet vārtejas lomu sysctl konfigurācijas failā vai tīkla pārvaldniekā, kuram pieder resursdators, pēc tam pārstartējiet pakalpojumu, kas to piemēro.

Tuneļos svarīga ir secība. Ja pārvaldnieks izveido saskarni palaišanas laikā un pārsūtīšanu piemēro vēlāk, saskarne var mantot veco noklusējumu. Pakalpojuma pārstartēšana, kas no jauna izveido tuneli, arī ir izveides notikums, un to ir viegli palaist garām, kad unit izskatās vesels. Pārbaudiet secību, ne tikai faila galīgo saturu.

Izlasiet tās pašas trīs vērtības vēlreiz pēc tam, kad VPN atkārtoti pieslēdzas, un vēlreiz pēc atkārtotas palaišanas. No jauna izveidots tunelis ir jauna saskarne, un jauna saskarne ņem izveides brīdī spēkā esošo noklusējumu. Ja skaitļi mainās starp šiem notikumiem, konfigurāciju piemēro kaut kas, ko vēl neesat identificējis.

Nelabojiet to ar nepareizo instrumentu

Kad pārsūtīšana izskatījās salūzusi, kārdinājums ir iztīrīt ugunsmūri vai pievienot masquerading. Neviens no tiem nepievēršas pārsūtīšanas slēdzim. Pārsūtīšanas stāvoklis, atļauja pārsūtīt, maršruts uz galamērķi un atgriešanās ceļš ir četras atsevišķas prasības, un tikai pirmā ir sysctl.

Pārbaudiet arī ar pareizu plūsmu. Pieprasījums, kas veikts pašā vārtejā, pārsūtīšanu nemaz neizmanto; tas ir lokāli ģenerēts trafiks. Jautājums ir, vai pakete, kas nāk no VPN klienta vai LAN resursdatora, tiek pieņemta un maršrutēta tālāk, tāpēc testam jāsākas aiz vārtejas.

Turiet IPv6 gadījumu atsevišķi

Šeit viss ir IPv4. IPv6 pārsūtīšanai, maršrutētāja paziņojumiem un accept_ra uzvedībai ir sava vadība, un ipv4 ceļa kopēšana uz ipv6 iestatījumu rada failu, kas izskatās ticami un nedara neko noderīgu. Divu steku vārtejai abi kopumi jākonfigurē apzināti.

Vēl viena pārbaude: kad vērtības sakrīt, apstipriniet, ka tuneļa maršruts tiek izvēlēts galamērķim un ka atbildes ceļš pastāv. Ieslēgta pārsūtīšana saskarnē bez maršruta joprojām ir melna bedre, un šī kļūme no klienta puses izskatās vienādi.