Zabezpečte, aby presmerovanie IPv4 prežilo reštart VPN brány
Nastavte ip_forward v mennom priestore, ktorý prenáša pakety klientov, dajte nastaveniu jedného vlastníka a dokážte, že prežije reštart, namiesto toho, aby ste len upravovali súbor.
Ping na bránu funguje a dosiahnutie čohokoľvek za ňou nie, a to je podoba problému s presmerovaním, nie problému s tunelom. Miestne doručenie na bránu dokazuje, že tunel vznikol a priradenie adresy fungovalo; nehovorí nič o tom, či jadro prepošle paket z jedného rozhrania na druhé. Skôr než sa dotknete akéhokoľvek sysctl, overte, že stroj má túto prevádzku smerovať a nájdite sieťový kontext, ktorý drží rozhranie obrátené ku klientovi. Potom hodnotu prečítajte tam, nie tam, kam náhodou pozrel posledný prečítaný návod.
Dosiahnutie brány nie je to isté ako presmerovanie
Vo vnútri jadra prebiehajú dve oddelené rozhodnutia. Doručenie na miestnu adresu ukončuje cestu paketu; presmerovanie ho znova pošle von iným rozhraním, a toto druhé rozhodnutie sa riadi pre každý sieťový menný priestor. Brána môže byť dokonale dostupná, zatiaľ čo presmerovanie je vypnuté, a z príkazového riadka ping vyzerajú obe poruchy rovnako.
Zapíšte, na ktorom rozhraní klientsky paket prichádza a ktorým rozhraním ďalšia cesta odchádza. Obe patria jednému mennému priestoru a ten drží nastavenie, na ktorom záleží.
Prečítajte hodnotu tam, kde pakety skutočne sú
Na bráne, ktorá smeruje v mennom priestore hostiteľa, na otázku odpovedá jediný príkaz: sysctl net.ipv4.ip_forward. Keď vstupná a ďalšia cesta žijú v pomenovanom mennom priestore, pýtajte sa jeho: ip netns exec vpn-gw sysctl net.ipv4.ip_forward. Hodnota hostiteľa nie je náhradou za hodnotu menného priestoru a jednotka na hostiteľovi nie je dôkazom ničoho.
Nie každý kontext smerovania má štítok, ktorý môžete odovzdať do ip netns. Runtime kontajnerov a služby vytvárajú menné priestory, ktoré sa nikdy neregistrujú pod priateľským menom, a pre tie používate nástroje na inšpekciu runtime. Nahraďte vpn-gw skutočným menom alebo mechanizmom runtime, ktorý dosiahne rovnaký kontext, a prestaňte hádať na úrovni hostiteľa.
Dajte nastaveniu jedného vlastníka
Na bežnej hostiteľskej bráne so systemd je trvalou podobou drop-in súbor s administrátorom zvoleným názvom, napríklad /etc/sysctl.d/60-vpn-forwarding.conf, ktorý obsahuje net.ipv4.ip_forward = 1. Súbor napíšte a potom načítajte práve tento súbor, aby sa zmenil aj živý stav: sudo sysctl -p /etc/sysctl.d/60-vpn-forwarding.conf, po čom nasleduje spätné čítanie. Názov súboru je príklad, nie rezervovaná cesta VPN, a úvodné číslo je dôležité, pretože súbory zoradené neskôr vyhrávajú.
Priorita je miesto, kde sa trvalosť ticho láme. Skontrolujte zavadzač distribúcie aj svoj drop-in, pretože procps sysctl --system na konci číta aj /etc/sysctl.conf, zatiaľ čo poradie sysctl.d v systemd je úplne iná sekvencia. Neskoršie priradenie môže ten istý kľúč okamžite vrátiť späť, takže váš súbor zostane správny a efektívna hodnota nesprávna. Neprepisujte existujúci administrátorský súbor, aby ste ten spor vyhrali; nájdite vlastníka a zmeňte to tam.
Menný priestor vytvorený po zavedení sa vôbec neriadi hostiteľským drop-in súborom. Jeho nastavenie patrí tomu, čo ho vytvára, či už je to runtime kontajnerov alebo jednotka na zabezpečenie menného priestoru. Dať kontajneru široké hostiteľské oprávnenia, aby sa otázka obišla, je horší obchod než stráviť desať minút hľadaním správneho vlastníka.
Zistite, čo prepínač stojí, skôr než ho prepnete
ip_forward nie je neškodný boolean. Dokumentácia jadra uvádza, že jeho zmena resetuje niekoľko ďalších parametrov IPv4 na predvolené hodnoty hostiteľa alebo smerovača, takže diagnostické prepnutie môže zahodiť ladenie vykonané inde a vôbec sa o tom nezmieniť. Berte to ako zmenu konfigurácie s vedľajšími účinkami, nie ako sondu, ktorú možno spustiť bezstarostne.
To tiež vylučuje vypínanie a zapínanie pri každej príležitosti, keď sa klient nedostane na hostiteľa. Ak je hodnota už jednotka, porucha je inde na ceste a prepísanie toho istého kľúča tretíkrát s ním nepohne.
Dokážte trvalosť a potom otestujte zvyšok cesty
Prečítajte hodnotu späť v štyroch okamihoch: hneď po zmene, po objavení sa rozhrania VPN, po opätovnom pripojení a po plánovanom reštarte. Hodnota, ktorá sa v ktoromkoľvek z týchto bodov vráti, má druhého vlastníka, a ďalší jednorazový zápis to len skryje do ďalšieho reštartu.
Zapnuté presmerovanie stále necháva tri veci na overenie. Klient potrebuje trasu k cieľu, brána potrebuje ďalšiu trasu plus oprávnenie ju použiť a cieľ potrebuje spiatočnú cestu k adrese klientskeho tunela. Súkromná smerovaná LAN automaticky nepotrebuje NAT, takže nepridávajte masquerading, kým nezistíte, ktorá z troch vecí chýba, a testujte zo zamýšľaného klienta, nie z brány samotnej, pretože požiadavka vzniknutá na bráne sa nikdy nedotkne cesty presmerovania, ktorú ste práve zapli. IPv6 má vlastnú politiku presmerovania a smerovania, takže fungujúci test IPv4 o nej nič nehovorí.
Držte spolu v runbooku cestu drop-in súboru, vlastníka menného priestoru a príkaz na spätné čítanie. Kto to prevezme ďalej, má byť schopný hodnotu prečítať, vidieť, kto ju vlastní, a do minúty rozhodnúť, či je problém v trvalosti, alebo vo zvyšku cesty.