Egy VPN-társ más interfészeket pingel, mert azok helyiek

Egy WireGuard kliens csatlakozik, és egy teljesen más interfészen lévő címre pingel, és a válasz megérkezik. A felvételek csak az alagúton mutatják a kérést. Semmi sem romlott el, és a gondosan kikapcsolt továbbítási beállításnak ehhez semmi köze. Ez két olyan útvonal összehasonlítása, amelyek a diagramon hasonlónak tűnnek, a kernelben pedig teljesen különböznek.

Az egyik útvonal más helyett továbbít csomagokat; a másik a gazdagépnek magának kézbesíti őket.

A gazdagépnek címzett csomag a gazdagépben marad

A távoli kliens IP-csomagot küld egy címre, amellyel a gazdagép rendelkezik. Az útválasztás egyetlen kérdést tesz fel erről a csomagról: helyi-e ez a cél? A gazdagép minden címe megjelenik a helyi útválasztási táblában, és ezt a táblát a fő tábla előtt kérdezik le, így a csomag a gazdagép saját vermébe kerül, nem pedig egy másik interfészen megy ki. A válasz helyben keletkezik, és az alagúton keresztül tér vissza, mert a lekérdezés onnan érkezett.

Ez a teljes mechanizmus. Nem történik továbbítás, nem vesz részt interfész-állapotváltozás, és a szóban forgó címnek nem kell máshonnan elérhetőnek lennie.

Miért nem alkalmazható az ip_forward

A továbbítás azokat a csomagokat szabályozza, amelyeknek más interfészen kell kilépniük, mint amelyen érkeztek. A gazdagépnek magának küldött ping soha nem ezt az útvonalat követi: a csomag helyben elhasználódik, és a válasz helyben keletkezik. Ezért a net.ipv4.ip_forward=0 beállítása itt semmit nem változtat, és a továbbítási lánc szabálya soha nem látja ezt a forgalmat. A helyes szabályozás a bemeneti útvonalon van, a bejövő interfész vagy forrás által korlátozva.

Ezért a továbbítás kikapcsolása és annak feltételezése, hogy a gazdagép elszigetelt, hamis biztonságérzetet kelt.

Olvassa el a helyi táblát, amely döntött

ip rule show általában egy nulla prioritású szabályt jelent, amely minden keresést először a helyi táblába küld, a ip route show table local pedig a gazdagép saját címeit listázza helyi hatókörrel. Ez a tábla tartalmazza az adminisztratívan lekapcsolt, de még konfigurált interfészek címeit is. A statikusan kiosztott IPv4-címek általában túlélik a kapcsolat megszakadását, és így egy lekapcsolt hídra küldött ping még mindig sikerülhet, és meglepheti az üzemeltetőt.

Az IPv6 pontosan ebben a pontban tér el. Címei általában visszavonódnak, amikor a kapcsolat megszakad, kivéve, ha a keep_addr_on_down be van állítva. Hasonlítsa össze a családokat ahelyett, hogy feltételezné, egy szabály mindkettőt lefedi.

Mit ér el valójában egy társ

A router saját címéről egy szegmensen érkező válasz semmit nem mond a szegmens mögötti gépekről. A társ ezen az útvonalon nem érheti el a másik interfész mögötti gazdagépet; csak azokat a címeket éri el, amelyekkel maga a router rendelkezik. Egy szolgáltatás tesztelése külön LAN-gazdagépen, nem pedig a router címének pingelése az, ami megállapítja, hogy a továbbítás egyáltalán engedélyezett-e.

A társ korlátozása az alagút címéhez kötött szolgáltatásokra bemeneti házirend kérdése. Engedélyezze a kívánt szolgáltatást az alagút interfészén, és korlátozza azokat a forrásokat, amelyek használhatják, mert a csomag valóban megérkezik oda.

Ellenőrizze azokat a címeket is, amelyeket ki akart vonni. Egy cím eltávolítása egy interfészről megbízhatóbb, mint tűzfal-szabályok halmozása egy elavult címre.