Panāciet, ka IPv4 pārsūtīšana saglabājas pēc VPN vārtejas pārstartēšanas

Ping uz vārteju darbojas, bet piekļuve jebkam aiz tās ne, un tā ir pārsūtīšanas problēmas forma, nevis tuneļa problēmas forma. Vietējā piegāde vārtejai pierāda, ka tunelis ir pacēlies un adrešu piešķiršana ir nostrādājusi; tā neko nepasaka par to, vai kodols nodos paketi no vienas saskarnes uz otru. Pirms aiztikt jebkuru sysctl, pārliecinieties, ka mašīna ir paredzēta šīs plūsmas maršrutēšanai un atrodiet tīkla kontekstu, kurā ir klienta puses saskarne. Pēc tam nolasiet vērtību tur, nevis tur, kur nejauši ieskatījās pēdējā lasītā rokasgrāmata.

Sasniegt vārteju nav tas pats, kas pārsūtīt

Kodola iekšienē notiek divi atsevišķi lēmumi. Piegāde uz vietējo adresi beidz paketes ceļu; pārsūtīšana to atkal izsūta pa citu saskarni, un šo otro lēmumu pārvalda atbilstoši tīkla nosaukumtelpai. Vārteja var būt pilnīgi sasniedzama, kamēr pārsūtīšana ir izslēgta, un no ping uzvednes abas kļūdas izskatās vienādi.

Pierakstiet, pa kuru saskarni klienta pakete ienāk un pa kuru saskarni izejošais ceļš iziet. Abas pieder vienai nosaukumtelpai, un tieši šajā nosaukumtelpā ir svarīgais iestatījums.

Nolasiet vērtību tur, kur paketes patiešām atrodas

Vārtejā, kas maršrutē resursdatora nosaukumtelpā, uz jautājumu atbild viena komanda: sysctl net.ipv4.ip_forward. Ja ienākošais un izejošais ceļš dzīvo nosauktā nosaukumtelpā, jautājiet tai nosaukumtelpai: ip netns exec vpn-gw sysctl net.ipv4.ip_forward. Resursdatora vērtība nav nosaukumtelpas vērtības aizstājējs, un vieninieks uz resursdatora nav ne par ko liecina.

Ne katram maršrutēšanas kontekstam ir uzlīme, ko varat nodot komandai ip netns. Konteineru izpildlaika vides un pakalpojumi veido nosaukumtelpas, kas nekad netiek reģistrētas draudzīgā vārdā, un tām izmantojat izpildlaika pārbaudes rīkus. Aizstājiet vpn-gw ar īsto nosaukumu vai izpildlaika mehānismu, kas sasniedz to pašu kontekstu, un pārtrauciet minēt resursdatora līmenī.

Piešķiriet iestatījumam vienu īpašnieku

Parastā systemd resursdatora vārtejā noturīgā forma ir drop-in fails ar administratora izvēlētu nosaukumu, piemēram, /etc/sysctl.d/60-vpn-forwarding.conf, kurā ir net.ipv4.ip_forward = 1. Ierakstiet failu, pēc tam ielādējiet tieši šo failu, lai mainītos arī dzīvais stāvoklis: sudo sysctl -p /etc/sysctl.d/60-vpn-forwarding.conf, kam seko atkārtota nolasīšana. Faila nosaukums ir piemērs, nevis rezervēts VPN ceļš, un sākuma skaitlis ir svarīgs, jo vēlāk sakārtotie faili uzvar.

Prioritāte ir vieta, kur noturība klusi salūzt. Pārbaudiet gan distribūcijas ielādētāju, gan savu drop-in failu, jo procps sysctl --system beigās nolasa arī /etc/sysctl.conf, bet systemd sysctl.d secība ir pilnīgi cita secība. Vēlāks piešķīrums var nekavējoties atgriezt to pašu atslēgu, atstājot jūsu failu pareizu un faktisko vērtību nepareizu. Nepārrakstiet esošu administratora failu, lai uzvarētu šajā strīdā; atrodiet īpašnieku un mainiet tur.

Nosaukumtelpa, kas izveidota pēc sāknēšanas, nemaz netiek pārvaldīta ar resursdatora drop-in failu. Tās iestatījums pieder tam, kas to izveido, vai tas būtu konteineru izpildlaiks vai nosaukumtelpas nodrošināšanas vienība. Piešķirt konteineram plašas resursdatora privilēģijas, lai izvairītos no jautājuma, ir sliktāks darījums nekā desmit minūtes veltīt pareizā īpašnieka noteikšanai.

Uzziniet, cik slēdzis maksā, pirms to pārslēdzat

ip_forward nav nekaitīgs boolean. Kodola dokumentācija norāda, ka tā maiņa atiestata vairākus citus IPv4 parametrus uz resursdatora vai maršrutētāja noklusējumiem, tāpēc diagnostiska pārslēgšana var izmest citur veiktu regulējumu un pat to neminēt. Uztveriet to kā konfigurācijas izmaiņas ar blakusefektiem, nevis kā pārbaudi, ko var palaist bezrūpīgi.

Tas arī izslēdz to izslēgšanu un ieslēgšanu katru reizi, kad klients nevar sasniegt resursdatoru. Ja vērtība jau ir viens, kļūda ir citur ceļā, un tā paša atslēgas trešā pārrakstīšana to nepārvietos.

Pierādiet noturību, pēc tam pārbaudiet pārējo ceļu

Nolasiet vērtību atpakaļ četros brīžos: tūlīt pēc izmaiņām, pēc tam kad parādās VPN saskarne, pēc atkārtotas savienošanas un pēc plānotas pārstartēšanas. Vērtībai, kas jebkurā no šiem punktiem atgriežas atpakaļ, ir otrs īpašnieks, un vēl viens vienreizējs ieraksts to tikai paslēpj līdz nākamajai pārstartēšanai.

Ieslēgta pārsūtīšana joprojām atstāj trīs lietas, kas jāpārbauda. Klientam vajag maršrutu uz galamērķi, vārtejai vajag tālāku maršrutu plus atļauju to izmantot, un galamērķim vajag atgriešanās ceļu uz klienta tuneļa adresi. Privāts maršrutēts LAN automātiski neprasa NAT, tāpēc nepievienojiet masquerading, pirms nezināt, kura no trim trūkst, un testējiet no paredzētā klienta, nevis no pašas vārtejas, jo pieprasījums, kas radies uz vārtejas, nekad neskar pārsūtīšanas ceļu, kuru tikko ieslēdzāt. IPv6 ir sava pārsūtīšanas un maršrutēšanas politika, tāpēc strādājošs IPv4 tests par to neko nepasaka.

Turiet kopā runbookā drop-in ceļu, nosaukumtelpas īpašnieku un atkārtotās nolasīšanas komandu. Nākamajam, kas to pārņems, jāspēj nolasīt vērtību, redzēt, kam tā pieder, un minūtes laikā izlemt, vai problēma ir noturībā vai ceļa pārējā daļā.