Egyirányú forgalom a Tailscale alhálózati SNAT kikapcsolása után

Kapcsolja ki a forrás-NAT-ot egy Tailscale alhálózati routeren, és az alagút tovább működik, miközben a rajta átmenő kapcsolatok leállnak. A kérések a távoli kliens saját overlay-címével érkeznek a célhoz, ami éppen a változtatás lényege, és a válaszoknak most olyan útra van szükségük, amelyet a LAN-nak soha nem kellett ismernie. Ezen útvonal nélkül a csomagok megérkeznek, a válaszok a szokásos átjárón távoznak, és a hiba olyan tűzfalproblémaként jelenik meg, amelyet egyetlen tűzfalszabály sem magyaráz. Az alagút egészséges; a visszaág hiányzik.

Mit rejtett az SNAT

Bekapcsolt SNAT esetén a router a továbbítás előtt az alhálózat felé átírja a forrás-címet a saját LAN-címére, így a cél olyan hosztnak válaszol, amelyet már tud elérni, és semmi mást nem kell beállítani. Kikapcsolása megőrzi az eredeti forrást, és a cél ekkor az overlay tartományba eső címet lát, nem pedig szomszédot a saját vezetékén. Ez a cím valódi és a tailneten át irányítható, a LAN-ból azonban az alapértelmezett átjárón keresztül nem érhető el. A dokumentált kapcsoló a --snat-subnet-routes=false, amelyet magára a Linux alhálózati routerre alkalmaznak.

Ez állandó beállítás, nem csomagonkénti kapcsoló, ezért a visszafelé vezető útnak minden olyan célhálózathoz léteznie kell, amelyet ez a router kiszolgál. Ez teszi a változtatást telepítési döntéssé, nem pedig jelölőnégyzetté. Minden, amit ez a router kiszolgál, ugyanabban a pillanatban örökli a követelményt.

Hol lehet a visszafelé vezető út

Három elhelyezés gyakori, és terjedelemben különböznek, nem helyességben. A célhoszton lévő statikus útvonal a legközvetlenebb és a legkevésbé skálázható, mivel minden eszköznek saját példányra van szüksége. A VPC-ben vagy a telephelyi routeren lévő útvonaltábla egyszerre egy egész hálózatot lefed, az osztály nélküli statikus útvonalakat szállító DHCP-beállítás pedig automatikusan eléri a klienseket, de csendben meghiúsul azokon az eszközökön, amelyek figyelmen kívül hagyják.

ip route add 100.64.0.0/10 via 192.168.1.10
ip route get 100.64.0.5

Bármelyik elhelyezést választja, a következő ugrás a router LAN-címe, és soha nem a tailnet-címe. Egy LAN-hoszt csak akkor éri el az overlayt, ha rendelkezik ezzel az útvonallal, ezért az overlayen belüli következő ugrás körkörös, és nem küldi sehova a csomagot. Ez az egyetlen hiba magyarázza a legtöbb konfigurációt, amely helyesnek látszik és mégis meghiúsul, és túléli minden olyan ellenőrzést, amely csak a router saját tábláját olvassa. Jegyezze fel, melyik elhelyezést használta, mert különben a következő ember a rosszat fogja tesztelni.

A hiba olvasása egyirányú forgalomként

A tünet könnyebben felismerhető, mint az ok: a szolgáltatás magán a routeren válaszol, és távoli kliens felől hallgat. A célon készített rögzítés érkező kéréseket és távozó válaszokat mutat, ami sikernek látszik, amíg észre nem veszi, hová tartanak ezek a válaszok. Az alapértelmezett átjáró felé mennek, ami azt jelenti, hogy a bejövő ág működött, a visszaág pedig nem.

Rögzítsen inkább a routeren, mert az egy csere mindkét irányát látja, és megmutatja, hogy egyáltalán megérkezett-e válasz. Ha a válasz megjelenik a célon, de soha a routeren, akkor az útvonal hiányzik vagy hibás a cél oldalán. Ha a routeren jelenik meg, és ott megáll, a probléma messzebb van, és másik vizsgálathoz tartozik.

sudo tcpdump -ni any host 100.64.0.5
ip route get 100.64.0.5

Megér-e egy útvonalat a valódi cím

Az SNAT megtartása marad az egyszerűbb válasz, amikor a célhálózat nem konfigurálható át, és az ára az, hogy minden kliens úgy néz ki, mint a router a cél naplóiban és szabályzatában. Kikapcsolása akkor indokolt, ha egy alkalmazásnak a valódi forrás-címre van szüksége, vagy ha a hálózati szabályzatnak meg kell különböztetnie az egy routert megosztó klienseket. Mindkettő jogos indok, és egyik sem ingyenes. Az előnynek meg kell érnie, hogy minden célhálózaton útvonalat tartson fenn, plusz az alább leírt tűzfal-felülvizsgálatot.

Egy kis LAN esetében a csere általában kifizetődik, míg a statikus útvonalat fogadni nem tudó készülékek sokasága esetében általában nem. Jegyezze fel a döntést és az okot a router konfigurációja mellé, hogy a következő rendszergazda tudja, melyik viselkedés szándékos. Egy alapértelmezés, amelyet senki nem írt le, nem különböztethető meg egy mulasztástól.

Tűzfal, naplózás és a kettős szerep

Minden szabály, amely a router LAN-címére illeszkedett, most más forrásra illeszkedik, és ez magában foglalja az engedélyező szabályokat és minden olyan naplómezőt, amely a routert kliensként rögzítette. Olvassa el ezeket a szabályokat az első teszt előtt, ne az első hiba után, mert a csak a router címét engedélyező szabály teljesen blokkolja az új forrást. Szűkítse a cserét azokra a kliensekre és portokra, amelyeknek szükségük van rá, majd erősítse meg, hogy nem engedi be csendben az egész tailnetet.

sudo nft list ruleset | grep -n '100\.64'
sudo iptables-save | grep -n '100\.64'

Egy csomópont, amely egyszerre kilépési csomópont és alhálózati router, dokumentált kombináció, amely az alhálózati SNAT kikapcsolása után eldobhatja a felfelé irányuló forgalmat. E szerepek külön csomópontokra osztása megszünteti ezt a fenntartást, és minden útvonalnak és tűzfalszabálynak egyetlen tulajdonost ad. Ha a szerepeknek együtt kell maradniuk, számítson erre a viselkedésre, és tesztelje, mielőtt egy klienst hibáztat. Tartsa az útvonalat, a kapcsoló beállítását és a szerepkiosztást egyetlen feljegyzésben, mert ezeket együtt olvassák, amikor a következő kapcsolat meghiúsul.