IPTables - SNAT, DNAT, Transzparens proxy (fordítás)

A netfilter/iptables használható NAT-olás elvégzésére az általunk tárgyalt módok bármelyikén. Valójában sok mindent tehetsz az iptablessel ezen a területen és mi megpróbálunk ebben a cikkben a lehető legtöbbet lefedni közülük.

Mielőtt a tárgyra térnénk, nézzük, mire van szükségünk ahhoz, hogy sikeresen végezzünk NAT-olást Linuxon.[/]

Kernel beállítása

Általában minden Linux disztribúció netfiltert támogató kernellel, iptables segédeszközzel ill. Network Address Translation (NAT / Hálózati címfordítás)-hoz szükséges modulokkal érkezik.

Egy nagyon jó, Kwan Lowe által írt HowTo a 2.4 és 2.6-os Linux kernelek forgatásához itt található: http://www.digitalhermit.com/linux/Kernel-Build-HOWTO.html

Új kernel fordításakor, vagy a meglévő kernelt újraforgatva, be kell állítanod a NETFILTER=y kapcsolót annak érdekében, hogy az iptables használható legyen.
A 2.6-os kernelekben ez az opció általában a Device Drivers | Networking support | Networking support (NET [=y]) | Networking options rész alatt található, de ez függ a kernel verziószámától.
Például a 2.6.14-es kernelben ez a lehetőség a Networking | Networking Options alatt van.
Ha make menuconfig vagy make xconfig-ot használsz a kernel újrafordításának konfigurációjához, válaszd a Networking | Networking options | Network packet filtering (replaces ipchains) | IP: Netfilter Configuration almenüt.
Az IP: Netfilter Configuration rész alatt találod a NAT-hoz szükséges lehetőségeket az alábbiak szerint:
IP_NF_CONNTRACK vagy Connection tracking (szükséges a masq/NAT-hoz) nyilvántartja a gép által átengedett IP csomagokat annak érdekében, hogy megfelelően át tudja adni azokat a NAT-olt végpontoknak, amikor az általuk indított kérések megválaszolásra kerültek.
Ez alapvető szükséglete a NAT-nak, ha itt Nem-et választasz, nem leszel képes NAT-olni.

A netfilter nat tábla

A NAT tábla három „láncot” tartalmaz --PREROUTING, POSTROUTING és OUTPUT.
Mindegyik lánc tartalmazhat szabályokat, amik vizsgálata sorjában történik addig, amíg valamely szabály nem illeszkedik a csomagra, azonos módon mint a netfilter tábla esetén is.
Ezen láncok megtekinthetők a következő iptables parancs kiadásával:

iptables -t nat -L

Az OUTPUT lánc nem teljes mértékben támogatott, ezért ennek ismertetésétől most el kell tekintenünk.

A PREROUTING és POSTROUTING láncoknak beszédes nevük van.

A PREROUTING láncot a kernel bármiféle routing döntés meghozatala előtt vizsgálja.
Ezért amit meg kell tennünk a PREROUTING láncban, hogy megváltoztatjuk a cél IP címét és utána átadjuk a routing folyamatnak, hogy megtalálja az általunk imént megváltoztatott célállomást (DNAT).

A POSTROUTING lánc olyan szabályokat tartalmaz, amelyeket a kernel a routing döntést követően vizsgál. Ez azt jelenti, hogy van útvonalunk a célállomáshoz és megváltoztathatjuk a forrás IP címét, ha annak útvonala a hálózatunkon kívül helyezkedik el (SNAT).

snat iptables-sel:
SNAT az iptables egyik legáltalánosabban használt NAT típusa, a használt topológia miatt.

Nézzük – például – a következő forgatókönyvet:

A 192.168.1.0/24 a mi irodánkban lévő hálózat. Van egy Ethernet kapcsolatunk a szolgáltatónktól, aki az 1.2.3.1/30 címet rendelte hozzánk, és az alapértelmezett átjáró 1.2.3.2.
A 192.168.1.0/24 összes számítógépének alapértelmezett átjárója 192.168.1.1.

A Linux routerünknek két Ethernet interfésze van:

• Eth0, IP cím: 192.168.1.1 netmask: 255.255.255.0, egy switchez csatlakozik, ami kapcsolatot létesít a 192.168.1.0/24-es hálózat többi eszközével.
• Eth1, IP cím: 1.2.3.1, netmask: 255.255.255.252, a szolgáltató CPE-jéhez (Customer Premises Equipment) kapcsolódik, ami lehet DSL modem, kábelmodem, média átalakító, stb.

Beállíthatunk SNAT-ot, hogy a 192.168.1.0/24 hálózat összes eszköze elérje az Internetet csupán egyetlen szabály segítségével:

iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -j SNAT --to 1.2.3.1

Ez a parancs azonos hatású a következővel, amit akkor használnánk, ha az Eth1 IP címe dinamikusan hozzárendelt volna, vagy ha dial-up (tárcsázós) modemet használnánk Ethernet kártya helyett:

iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -j MASQUERADE

Tegyük fel, hogy a szolgáltatónk kiszűr minden 1024 feletti portot. Ebben az esetben szükségünk lesz a forrásport megváltoztatására is, nem csupán a forrás-IP változtatására.
Ezt megtehetjük a következőképpen:

iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -j SNAT --to 1.2.3.1:1-1024

A laptop felhasználó, aki az előző ábrán látható, IRC fanatikus és felhív minket, hogy egyetlen IRC hálózatra sem képes csatlakozni.
Ez azt jelenti, hogy az ip_conntrack modulnak szüksége van kis segítségre, amit megadhatunk neki az ip_conntrack_irc modul kernelbe illesztésével (betöltésével). Ezen felül szeretnénk, ha lehetővé válna felhasználók számára sikeres FTP kapcsolatokat nyitni, ezért hozzá szeretnénk adni az ip_conntrack_ftp modult is a rendszerhez.

modprobe ip_conntrack_irc #vagy insmod ip_conntrack_irc
modprobe ip_conntrack_ftp #vagy insmod ip_conntrack_ftp

Néhány héttel később, a laptop felhasználó meggyőzött a 192.168.1.0/24 hálózatban más felhasználókat is arról, hogy milyen csodálatos az IRC világa, így van 20-30 felhasználónk, aki ugyanarra az IRC hálózatra kapcsolódik. Most elkezdtek panaszkodni, milyen nehéz felcsatlakozni az IRC hálózatra, mivel az csak néhány kapcsolatot engedélyez azonos IP-címről.
Kiszámoltuk, hogy 32 IP-cím elég lesz számukra, ezért felhívjuk a szolgáltatót, hogy rendeljen hozzánk egy /27-es publikus alhálózatot. Néhány extra dollárért hozzánk rendelik az 1.2.4.0/27-es hálót.
A kezdeti szabályt ki kell cserélnünk a következőre:

iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -j SNAT --to 1.2.4.0-1.2.4.32

Abbahagyják a panaszkodást, de rájövünk, hogy már nem használjuk a Linux routerünk publikus IP-címét NAT-olásra. Adjuk hozzá azt is; tehát adunk nekik egy extra IP címet:

iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -j SNAT --to 1.2.4.0-1.2.4.32 --to 1.2.3.1

Az egyik felhasználónk szóváltásba kerül IRC-en és floodoláson („elárasztás”) kapják, mialatt az SNAT az IP-címét az 1.2.4.15-höz rendeli. A szolgáltatónk flood-felismerő rendszere automatikusan kiszűri ezt a címet és küld nekünk egy értesítő levelet erről.
Meg kell akadályoznunk, hogy az SNAT a továbbiakban bármilyen belső IP-ét rendeljen ehhez az IP címhez, így a következőt tesszük:

iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -j SNAT --to 1.2.4.0-1.2.4.14 --to 1.2.4.16-1.2.4.32 --to 1.2.3.1

Egy srác a könyvelésről, 192.168.1.19-es IP címmel arról panaszkodik, hogy nem ér el egyetlen számítógépet sem 192.168.1.32-es IP cím felett. Lehetséges, hogy megváltoztatta a netmask-ját 255.255.255.227-re, így az összes IP csomag a számítógépéről azokra a 192.168.1.0/24-ben lévő gépekre, amik 192.168.1.0/27-ben nincsenek bent, a Linux routeren megy keresztül és SNAT-olva lesz.
Ennek megoldására két alternatív lehetőségünk van:

Az első az lenne, hogy nem SNAT-olunk 192.168.1.0/24-re, amikor a célgép is 192.168.1.0/24-ben van:

iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -d ! 192.168.1.0/24 -j SNAT --to 1.2.4.0-1.2.4.32 --to 1.2.3.1

A második választásunk, hogy csak azokat a csomagokat SNAT-oljuk, amik Eth1-en mennek ki:

iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -o eth1 -j SNAT --to 1.2.4.0-1.2.4.32 --to 1.2.3.1

A szolgáltatónk csatlakoztatta cégünk másik telephelyét ugyanazon készülékre, és mivel azonos VLAN-ban vagyunk, nem kell tunnelt felépítenünk a két telephely közötti routereken, hanem csak routolni a hálózatokat a másik helyen lévő Linux routeren keresztül. A másik helyen 192.168.2.0/24 hálózatunk van. Lehetővé kell tennünk a hálózatunkban lévő számítógépek számára, hogy elérjék a 192.168.2.0/24 hálózatban lévő gépeket anélkül, hogy SNAT-olnánk őket:

iptables -t nat -I POSTROUTING -s 192.168.1.0/24 -d 192.168.2.0/24 -j ACCEPT

Ez a parancs beilleszt egy szabályt a NAT szabály elé; így ha bármely csomag 192.168.1.0/24-ből bármely, 192.168.2.0/24 hálózatban lévő IP-re irányul, ez a szabály illeszkedik és a lánc nem lesz tovább elemezve, tehát SNAT-olás nem történik.

Jane, a titkárnőnk híres a jó kávéjáról, de mióta elkapta az IRC-lázat, semmit nem csinál. A főnök mérges emiatt, de nem akarja kirúgni őt, mert rabja Jane híres kávéjának; tehát eljön és megkér minket, hogy tegyünk valamit ez ellen.

Sok mindent tehetünk e probléma ügyében, például a POSTROUTING láncban eldobjuk a Jane-től (192.168.1.31) érkező csomagokat, amikor a 6666-6669 portokat próbálja elérni:

iptables -t nat -I POSTROUTING -s 192.168.1.31 -p tcp --dport 6666:6669 -j DROP

Megkérdezhetjük a főnököt, hogy mi engedélyezett Jane számára. Például, ha a főnök csak Web-hozzáférést szeretne engedélyezni neki, a következőt tehetjük:

iptables -t nat -I POSTROUTING -s 192.168.1.31 -p tcp --dport ! 80 -j DROP

Ez a szabály nem fogja SNAT-olni Jane IP címét, amikor megpróbál a 80-as TCP porttól eltérőhöz hozzáférni, de SNAT-olni fogja az IP-címét bármilyen UDP szolgáltatás elérésekor, mert UDP csomagokra ez a szabály nem illeszkedik; így lehetősége lesz elérni bármilyen DNS szervert a hálózatunkon kívül.

dnat iptables-sel:

Folytatjuk az előző forgatókönyvet DNAT-hoz is. Egy nap a főnök felhív minket mondván, hogy el kell érnie a számítógépét otthonról is. Természetesen ezt nem tudja megtenni az ő privát IP-címe (192.168.1.50) miatt. Elhatározzuk, hogy hozzárendeljük a rendelkezésünkre álló publikus IP-címeink egyikét az irodai számítógépéhez, de ha ehhez csak egy aliast hoznánk létre Eth0-án, nemcsak néhány IP címet veszítenénk, de ő sem lenne azonos hálózatban a többiekkel.
A legjobb megoldás egy publikus IP címet (mondjuk 1.2.4.1) rendelnünk az irodai számítógépének privát IP címéhez (192.168.1.50).
Ez – természetesen – DNAT:

iptables -t nat -A PREROUTING -d 1.2.4.1 -j DNAT --to 192.168.1.50

Így a következő teendőnk felhívni őt és elmondani neki, hogy amikor otthonról csatlakozni szeretne az irodai számítógépéhez, az 1.2.4.1 címhez kell csatlakoznia.

Az intranet szerverünk IP-címe 192.168.1.100. Egy srácnak a pénzügyi osztályról szélessávú hozzáférése van és afelől érdeklődik, el tudná-e érni az intranet szervert otthonról. Megadja nekünk a publikus IP-címét, ami 1.2.5.17. Elmondjuk neki, hogy otthonról az 1.2.4.2 IP címet kell a web böngészőjében próbálnia és végrehajtjuk:

iptables -t nat -A PREROUTING -s 1.2.5.17 -d 1.2.4.2 -p tcp --dport 80 -j DNAT --to 192.168.1.100

Úgy gondoljuk, hogy akár bárhonnan SSH-ázhatnánk az intranet szerverre. Nem volna bölcs elgondolás egy IP-címet hozzárendelni egy ilyen, a cég számára alapvető intranet szerverhez, és ha felbukkan egy SSH bug, nem szeretnénk, ha feltörnék a szervert. Jó ötlet lehet egy magasabb számú portot hozzárendelni az intranet szerver SSH portjához (ez a PAT vagy NAPT). (Port Address Translation/Network Address Port Translation)

iptables -t nat -A PREROUTING -d 1.2.4.2 -p tcp --dport 65521 -j DNAT --to 192.168.1.100:22

Ezáltal, amikor nem vagyunk az irodában és SSH-ázni szeretnénk az intranet szerverre, megnyitunk egy SSH kapcsolatot 1.2.4.2-re a 65521-es porton.

Idővel tegyük fel, hogy feltelepítettünk egy web-szervert a 192.168.1.200-as IP címre. A webszerver neve www.cégem.akármi és a DNS-ben 1.2.4.5-re mutat. Hogy a külső világ számára elérhető legyen, a következőt hajtjuk végre:

iptables -t nat -A PREROUTING -d 1.2.4.5 -p tcp --dport 80 -j DNAT --to 192.168.1.200

Transzparens („átlátszó”) proxy:

A transzparens proxy egy módszer arra, hogy rákényszerítsük a felhasználókat proxy szerver használatára akkor is, ha a böngészőjükben ez nincs beállítva. Valószínűleg ismered a proxy szerver jelentette előnyöket a tárolt oldalak (cache) általi sávszélesség-kímélő hatása, valamint hozzáférés-szabályozó implementációja (pl. veszélyes kiterjesztésű fájlok letöltésének megtagadása) tekintetében.

Végezhetünk transzparens proxy-izást az összes, vagy akár csak néhány felhasználó számára, hogy megelőzzük a proxy-szerver mellőzését, bármikor is akarnák. Ez különösen jó gyermekek számítógépei számára ahhoz, hogy megtagadjuk számukra szexuálisan nyílt helyek hozzáférését például.

A Linux routerünkön telepítettük a Squid proxy szervert a Webtartalmak egy részének gyorstárazására. Ezen felül meg akarjuk akadályozni a felhasználók számára szexoldalak vagy rosszindulatú letöltések hozzáférését. A felhasználók nemigen vannak lenyűgözve a proxy-szerverünk használatától, és általában eltávolítják azt a böngészőjük beállításai közül. Akárhogy is, kényszeríthetjük őket a proxy-szerver használatára.
Ha a proxy-szerver a 3128-as porton figyel, a következőt csináljuk:

iptables -t nat -A PREROUTING -s 192.168.1.0/24 -p tcp --dport 80 -j REDIRECT --to-port 3128

Ha lehetővé szeretnénk tenni a főnök számára (akinek 192.168.1.50 az IP-címe) a proxy-szerver mellőzését, efféleképpen cselekszünk:

iptables -t nat -I PREROUTING -s 192.168.1.50 -p tcp --dport 80 -j ACCEPT

Így ez a szabály illeszkedni fog a PREROUTING láncban, és ezáltal a POSTROUTING láncban ő SNAT-olásra kerül.

______________________________________
Eredeti forrás (nem tudom, mi lett vele)
Itt megtaláltam az eredeti szöveget