Užtikrinkite, kad IPv4 peradresavimas išliktų po VPN tinklų sietuvos perkrovimo

Ping į tinklų sietuvą veikia, o pasiekti ką nors už jos nepavyksta, ir tai yra peradresavimo, o ne tunelio problemos forma. Vietinis pristatymas į tinklų sietuvą įrodo, kad tunelis pakilo ir adresų priskyrimas veikė; jis nieko nesako apie tai, ar branduolys perduos paketą iš vienos sąsajos į kitą. Prieš liesdami bet kurį sysctl, patvirtinkite, kad mašina skirta maršrutizuoti šį srautą ir suraskite tinklo kontekstą, kuriame yra į klientą atsukta sąsaja. Tada skaitykite reikšmę ten, o ne ten, kur paskutinis perskaitytas vadovas atsitiktinai pažvelgė.

Pasiekti tinklų sietuvą nelygu peradresavimui

Branduolio viduje priimami du atskiri sprendimai. Pristatymas į vietinį adresą baigia paketo kelionę; peradresavimas vėl išsiunčia jį per kitą sąsają, ir šis antrasis sprendimas valdomas pagal tinklo vardų erdvę. Tinklų sietuvas gali būti visiškai pasiekiamas, kai peradresavimas išjungtas, ir iš ping eilutės abi gedimai atrodo vienodai.

Užsirašykite, į kurią sąsają ateina kliento paketas ir per kurią sąsają išeina tolesnis kelias. Abi priklauso vienai vardų erdvei, ir būtent toje erdvėje yra svarbus nustatymas.

Skaitykite reikšmę ten, kur paketai iš tikrųjų yra

Tinklų sietuvoje, kuri maršrutizuoja pagrindinio kompiuterio vardų erdvėje, viena komanda atsako į klausimą: sysctl net.ipv4.ip_forward. Kai įeinantis ir tolesnis kelias gyvena pavadintoje vardų erdvėje, klauskite tos erdvės: ip netns exec vpn-gw sysctl net.ipv4.ip_forward. Pagrindinio kompiuterio reikšmė nepakeičia vardų erdvės reikšmės, o vienetas pagrindiniame kompiuteryje nėra nieko įrodymas.

Ne kiekvienas maršrutizavimo kontekstas turi žymą, kurią galite perduoti komandai ip netns. Konteinerių vykdymo aplinkos ir paslaugos kuria vardų erdves, kurios niekada neregistruojamos draugišku vardu, ir joms naudojate vykdymo aplinkos patikros įrankius. Pakeiskite vpn-gw tikruoju vardu arba vykdymo aplinkos mechanizmu, pasiekiančiu tą patį kontekstą, ir nustokite spėlioti pagrindinio kompiuterio lygiu.

Suteikite nustatymui vieną savininką

Įprastoje systemd pagrindinio kompiuterio tinklų sietuvoje patvari forma yra drop-in failas su administratoriaus pasirinktu vardu, pavyzdžiui /etc/sysctl.d/60-vpn-forwarding.conf, kuriame yra net.ipv4.ip_forward = 1. Parašykite failą, tada įkelkite būtent tą failą, kad pasikeistų ir veikianti būsena: sudo sysctl -p /etc/sysctl.d/60-vpn-forwarding.conf, po to perskaitykite atgal. Failo vardas yra pavyzdys, o ne rezervuotas VPN kelias, ir pradinis skaičius svarbus, nes vėliau surikiuoti failai laimi.

Pirmumas yra vieta, kur patvarumas tyliai lūžta. Patikrinkite ir distribucijos įkėlėją, ir savo drop-in failą, nes procps sysctl --system pabaigoje taip pat skaito /etc/sysctl.conf, o systemd sysctl.d tvarka yra visiškai kita seka. Vėlesnis priskyrimas gali tą patį raktą iš karto grąžinti, palikdamas jūsų failą teisingą, o faktinę reikšmę neteisingą. Neperrašykite esamo administratoriaus failo, kad laimėtumėte tą ginčą; raskite savininką ir pakeiskite ten.

Vardų erdvė, sukurta po paleidimo, visiškai nepavaldi pagrindinio kompiuterio drop-in failui. Jos nustatymas priklauso tam, kas ją sukuria – konteinerių vykdymo aplinkai ar vardų erdvės paruošimo vienetui. Suteikti konteineriui plačias pagrindinio kompiuterio teises, kad būtų išvengta klausimo, yra prastesnis sandoris nei dešimt minučių skirti teisingam savininkui nustatyti.

Žinokite, kiek kainuoja jungiklis, prieš jį perjungdami

ip_forward nėra nekenksminga loginė reikšmė. Branduolio dokumentacija pažymi, kad jį pakeitus keli kiti IPv4 parametrai grąžinami į pagrindinio kompiuterio ar maršrutizatoriaus numatytąsias reikšmes, todėl diagnostinis perjungimas gali išmesti kitur atliktą derinimą ir net to nepaminėti. Traktuokite tai kaip konfigūracijos pakeitimą su šalutiniais poveikiais, o ne kaip patikrą, kurią galima atlikti nerūpestingai.

Tai taip pat atmeta jo išjungimą ir įjungimą kiekvieną kartą, kai klientas negali pasiekti pagrindinio kompiuterio. Jei reikšmė jau vienetas, gedimas yra kitur kelyje, ir to paties rakto trečias perrašymas jo nepajudins.

Įrodykite patvarumą, tada išbandykite likusią kelio dalį

Perskaitykite reikšmę atgal keturiais momentais: iškart po pakeitimo, po to kai atsiranda VPN sąsaja, po pakartotinio prisijungimo ir po suplanuoto perkrovimo. Reikšmė, kuri atsuka bet kuriame iš šių taškų, turi antrą savininką, ir dar vienas vienkartinis įrašas tik paslepia tai iki kito perkrovimo.

Įjungtas peradresavimas vis tiek palieka tris dalykus patikrinti. Klientui reikia maršruto iki paskirties, tinklų sietuvai reikia tolesnio maršruto ir leidimo juo naudotis, o paskirčiai reikia grįžimo kelio iki kliento tunelio adreso. Privatus maršrutizuotas LAN automatiškai nereikalauja NAT, todėl nepridėkite masquerading, kol nežinote, kurio iš trijų trūksta, ir bandykite iš numatyto kliento, o ne iš pačios tinklų sietuvos, nes užklausa, prasidėjusi tinklų sietuvoje, niekada neliečia peradresavimo kelio, kurį ką tik įjungėte. IPv6 turi savo peradresavimo ir maršrutizavimo politiką, todėl veikiantis IPv4 testas apie ją nieko nesako.

Laikykite kartu runbook'e drop-in kelią, vardų erdvės savininką ir perskaitymo komandą. Kas tai perims toliau, turėtų galėti perskaityti reikšmę, pamatyti, kam ji priklauso, ir per minutę nuspręsti, ar problema yra patvarumas, ar likusi kelio dalis.