Miért hagyja érintetlenül a net.ipv4.conf.default.forwarding a tun0-t

A default.forwarding csak az új interfészeket veti el, egy élő alagutat nem. Hasonlítsa össze az ip_forwardot, a sablont és az interfészt az őt birtokló namespace-ben.

Beállította a net.ipv4.conf.default.forwarding=1 értéket, újraindította a VPN-t, és az alagút továbbra is eldobja azokat a csomagokat, amelyeket az átjárónak továbbítania kellene. A beállítás jónak látszik a fájlban, és az interfész továbbra is azt jelzi, hogy a továbbítás ki van kapcsolva. Semmi sem romlott el: azt az értéket változtatta meg, amelyet a jövőbeli interfészek örökölnek, nem azt, amelyet az élő alagút használ.

Ezt az alagutat birtokló gazdagépen menjen végig, abban a hálózati namespace-ben, ahol az alagút valóban létezik. Egy konténer vagy hálózati namespace tarthatja az interfészt, miközben a gazdagép más számokat mutat.

Olvassa a három értéket együtt

Kezdje az átjáró szintű kapcsoló, az új interfészek sablonja és az Önt érdeklő interfész összehasonlításával. Cserélje ki a tun0 elemet a valódi bemeneti interfészre, és olvassa el a visszatérő interfészt is, mert a továbbítást ott értékelik, ahol a csomag megérkezik.

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

Gyakori eredmény, hogy ip_forward = 0, default.forwarding = 1 és tun0.forwarding = 0. Az első kettő nem ért egyet a gazdagép szerepéről, a harmadik pedig megmutatja, mit tesz valójában az interfész. Ez a kombináció olyan gazdagéphez illik, amelyet soha nem állítottak be routerként, csak egy sablonértéket kapott. A három szám nem mond ellent egymásnak; három különböző kérdésre válaszolnak. A sablonérték beírása sem dönti el a gazdagép szerepét.

Miért a globális kapcsoló az, amely mozdul

net.ipv4.ip_forward az átjáró szintű vezérlés. Módosítása ugyanazon művelet részeként frissíti az interfészenkénti továbbítási beállításokat, ezért egyetlen írás is elindíthatja egy meglévő alagút továbbítását. default.forwarding csak az utána inicializált interfészeket veti el, így a már létező alagút megtartja azt az értéket, amellyel született.

A kernel dokumentációja ip_forward különlegesként jelöli meg egy kapcsolódó okból: módosítása több más IPv4-paramétert állít vissza a gazdagép vagy a router alapértékeire. Ez tompa eszközzé teszi. Egyszer beállítani az átjárószerep kialakításának részeként rendben van; hibakeresési trükként ismételten átkapcsolni viszont csendben átírhat olyan konfigurációt, amelyre időt szánt.

Az interfészenkénti értékek is okkal léteznek. Egy szándékosan kezelt átjáró kikapcsolva tarthatja a továbbítást egy olyan interfészen, amelynek soha nem szabadna forgalmat továbbítania, miközben a gazdagép máshol továbbít. Ezért fontos az élő interfész olvasása, és ezért nem a globális érték az egyetlen válasz. Az ilyen kivételt szándékos döntésként olvassa, és írja le, miért más az az interfész. Különben a következő mérnök segítőkészen "megjavítja".

Tegye tartóssá a beállítást a megfelelő helyen

Egy sikeres egyszeri sysctl -w bizonyítja, hogy a kernel elfogadja az értéket. Nem éli túl az újraindítást, és nem éli túl azt a hálózatkezelőt sem, amely újracsatlakozáskor újra alkalmazza a saját elképzelését az interfész konfigurációjáról. Tegye az átjárószerepet a sysctl konfigurációs fájlba vagy a gazdagépet birtokló hálózatkezelőbe, majd indítsa újra a szolgáltatást, amely alkalmazza.

Az alagutaknál számít a sorrend. Ha a kezelő indításkor létrehozza az interfészt, és a továbbítást csak utána alkalmazza, az interfész örökölheti a régi alapértéket. Egy szolgáltatás-újraindítás, amely újra létrehozza az alagutat, szintén létrehozási esemény, és könnyű kihagyni, amikor az unit egészségesnek látszik. Ellenőrizze a sorrendet, ne csak a fájl végső tartalmát.

Olvassa újra ugyanazt a három értéket, miután a VPN újracsatlakozott, és még egyszer újraindítás után. Az újonnan létrehozott alagút új interfész, és az új interfész a létrehozás pillanatában érvényes alapértéket veszi fel. Ha a számok ezek között az események között változnak, a konfigurációt valami olyan alkalmazza, amelyet még nem azonosított.

Ne javítsa ezt rossz eszközzel

Amikor a továbbítás töröttnek látszott, a kísértés a tűzfal ürítése vagy masquerading hozzáadása. Egyik sem kezeli a továbbítási kapcsolót. A továbbítási állapot, a továbbítási engedély, a cél felé vezető útvonal és a visszaút négy külön követelmény, és csak az első a sysctl.

A megfelelő folyammal is teszteljen. Az átjárón magán indított kérés egyáltalán nem gyakorolja a továbbítást; az helyben keletkezett forgalom. A kérdés az, hogy egy VPN-kliensről vagy LAN-gazdagépről érkező csomag elfogadásra és továbbításra kerül-e, ezért a tesztnek az átjáró mögül kell indulnia.

Tartsa külön az IPv6 esetét

Itt minden IPv4. Az IPv6 továbbításnak, a router-hirdetéseknek és az accept_ra viselkedésnek saját vezérlése van, és egy ipv4 útvonal ipv6 beállításba másolása olyan fájlt hoz létre, amely hihetőnek látszik, és semmi hasznosat nem tesz. A kettős stackű átjárónak mindkét készletet szándékosan kell beállítania.

Egy utolsó ellenőrzés: miután az értékek megegyeznek, erősítse meg, hogy az alagút útvonala kiválasztódik a célhoz, és hogy a válaszút létezik. Útvonal nélküli interfészen bekapcsolt továbbítás továbbra is fekete lyuk, és ez a hiba az ügyfél oldaláról ugyanúgy látszik.

Kapcsolódó cikkek