Két VPN-kliens, két nyilvános cím: igazítsa össze a SNAT-ot

Két VPN-kliens két különböző nyilvános IPv4-címen keresztül léphet ki, és az ezt lehetővé tevő szabály rövidebb, mint a legtöbb ember gondolná. Nem az iptables szintaxisa működteti, hanem a csomag állapota, amikor eléri a kimeneti láncot: az ottani forráscímnek még mindig meg kell tudnia különböztetni a klienseket. Ha egy korábbi masquerade már egyetlen címre vonta össze mindkettőt, egyetlen kliensenkénti szabály sem tudja visszaállítani a megkülönböztetést. Először ezt a kérdést döntse el, aztán írja meg a fordítást.

Melyik identitás éri el az átjárót

A szabály a csomag forráscímére illeszkedik, nem egy VPN-felhasználónévre és nem arra a névre, amelyet egy kliensalkalmazás megjelenít. Minden, ami a csomagot korábban fordítja az úton, meghatározza, hogy a szabálya még mit láthat. Futtassa a nat táblát sorrendben, és keresse meg azt a pontot, ahol a forrás még kliensenként különálló.

iptables -t nat -S POSTROUTING

Olvassa végig a listát felülről. A felső részhez közeli masquerade-szabály minden illeszkedő folyam forrását átírja, és az utána elhelyezett kliensenkénti bejegyzések olyan címre illeszkednek, amely már nem létezik. Amikor két LAN-eszköz egy alagutat oszt meg, és egyetlen belső címként érkezik, a tervezésnek a tűzfal előtt kell megváltoznia: tartsa külön a forrástartományaikat, vagy adjon mindegyiknek saját belső címet.

Kösse a belső cím kiosztását a hitelesített klienshez. A cím átadása egy másik eszköznek a kimeneti szabályzatot is átadja, és a forrásfordítás önmagában nem identitásbizonyíték.

A fordítás nem tud címet kitalálni

Minden nyilvános címet hozzá kell rendelni ehhez a kimeneti ponthoz, vagy ide kell irányítani, és a válaszoknak meg kell találniuk az ide vezető utat. Az a szabály, amely olyan címről küld forgalmat, amelyre senki nem irányít vissza, a távoli végén eldobódik, vagy olyan hosztnak válaszol, amely soha nem kérte. A felhőszolgáltatói példány nyilvános címét általában már a csomag távozása előtt privát interfészcímre fordítják, ezért a SNAT forrásának annak a címnek kell lennie, amelyet a szolgáltató elfogad, nem annak az értéknek, amelyet a konzol mutat. Olvassa el a szolgáltató címmodeljét, és kövesse azt, ahelyett hogy a nyilvános értéket minden csomagba bemásolná.

A gyakorlatban ez azt jelenti, hogy a tűzfal érintése előtt ellenőrizze az irányított előtagot a szolgáltató konzolján, és amikor a leképezés egy az egyhez, használja a privát interfészcímet fordítási forrásként. A lenti példákban használt címek a dokumentációs tartományokból származnak, ezért az első helyettesítendő dolog maga a címszöveg.

Szúrja be az általános masquerade elé

Erősítse meg a kimeneti interfészt és az aktuális láncot, mielőtt bármit hozzáad. Az első eldönti, mely csomagokra illeszkedhet a szabály, a második pedig megmutatja, mi áll már előtte.

ip -4 route show default
iptables -t nat -L POSTROUTING -n -v --line-numbers

Az első parancs megnevezi az interfészt, amelyen egy internetre tartó csomag valóban kilép. A második sorszámokkal nyomtatja ki a láncot. Az általános masquerade-bejegyzés az a sor, amely fölött maradni kell.

iptables -t nat -I POSTROUTING 1 -s 10.88.4.20/32 -o ens3 -j SNAT --to-source 198.51.100.77
iptables -t nat -I POSTROUTING 1 -s 10.88.4.21/32 -o ens3 -j SNAT --to-source 198.51.100.78

A fenti két szabály egy-egy belső címre illeszkedik, az illesztést a kimeneti interfészre korlátozza, és kifejezetten beállítja a forrást. Szúrja be, ne fűzze hozzá: az 1. pozícióban a masquerade-sor előtt értékelődnek ki. A kettő közötti sorrend nem számít, mert a forrásaik eltérnek. Cserélje ki az ens3 értéket arra, amit az útvonalparancs jelentett, és tartsa távol a többi tűzfal-kezelőt ugyanazoktól a horgoktól, mert két eszköz, amely ugyanabba a táblába ír, a szokásos oka annak, hogy egy helyes szabálynak nincs hatása.

Bizonyítsa a forrást új folyammal

Az állapotalapú NAT a folyam kezdetekor hozzárendel egy fordítást, és későbbi csomagokhoz újra felhasználja, ezért a változás előtt megnyitott munkamenet a változás után is megtartja régi forrását. Csak egy újonnan indított kapcsolat bizonyítja a szabályt.

conntrack -L -s 10.88.4.20 -p tcp --dport 443

Olvassa el a bejegyzés válaszirányát: a célja az a cím, amelyet a távoli végpont forrásként lát. Hasonlítsa össze a szándékolt nyilvános címmel, és a régi címet tartalmazó bejegyzést a túl korán indult folyam bizonyítékának tekintse, nem hibás szabálynak. Kérje meg a klienst, hogy nyisson új kapcsolatot, majd ismételje meg a lekérdezést. A teljes követési tábla törlése a teszt kikényszerítéséhez minden más munkamenetet megszakít az átjárón.

A fordítás továbbra sem választ útvonalat, nem engedi át a folyamot a szűrőn, és nem tesz közzé bejövő szolgáltatást. A rossz útvonal és a hiányzó engedélyező szabály egy tökéletes SNAT-szabály után is tovább hibázik. Ellenőrizze az IPv6-ot és minden másodlagos kimeneti útvonalat is, majd jegyezze fel a belső-nyilvános párokat a tűzfal dokumentációjában, hogy a következő változás a leképezésből induljon ki, ne a szabály szövegéből.