iptables NAT

Linux-kezdő

Sziasztok!

Van egy szerverem, melyben két hálókártya van, az egyik megy az internet felé (eth0), a másik a belső hálózat felé (eth1). A kérdésem az, hogy tudnám megoldani, hogy ami a belső hálózati kártyára (eth1) érkezik azt NAT-olja az internet felőli kártyára (eth0)?

köszönöm

  • 3975 megtekintés

( PunishR v | 2012. 05. 06., v – 10:01 )

pl.:
echo 1 > /proc/sys/net/ipv4/ip_forward
/sbin/iptables -t nat -A POSTROUTING -o eth0 -s 192.168.1.0/24 -j MASQUERADE
/sbin/iptables -A FORWARD -i eth0 -o eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT
/sbin/iptables -A FORWARD -i eth1 -o eth0 -j ACCEPT

192.168.1.0/24 a belső hálón használt subneted.
eth0 internet
eth1 lan

"A forward láncot miért is kéne engedni?"
Javaslom, legelőször tekintsd át a csomag netfilterben bejárt útját.

"Nem route-olni fog, hanem natolni..."
Miért, szerinted a natolásnál melyik irányba fog menni a csomag? Ezt mi dönti el? Talán egy illeszkedő route? Tehát van routing?

Természetesen az eredeti kérdés csak a natolásra vonatkozott, de mivel a Linux-kezdőben van ez a topik, PunishR úgy gondolta, erre is felhívja a kérdező figyelmét.

"Mondjuk én inkább a cisco-s nat-ot ismerem..."
Mivel egy előző topikban a Cisco ACL-hez próbáltad hasonlítani, folytassuk ezt a gondolatmenetet. Kell-e engedni az interfészre ip access-group paranccsal feltett ACL-ben azt a forgalmat, amit a natolásra kijelölt forgalmat meghatározó ip nat source, ip nat inside source stb. parancsok ACL-jében megadtál?

A filter tábla (FORWARD lánc) hasonló az ip access-group-hoz, a nat tábla (POSTROUTING) pedig az ip nat parancshoz.

"Kell a forward-ot engedni? Nanemár."
Ugye, hogy két függetlenül megadható dolog ez mindkét rendszerben? És hogy mennyire hasonlítanak egymáshoz?

Ok, értem.
Mondjuk ez az ACL-es hasonlat sántít kicsit...
Míg linuxon mindkét, egymástól teljesen független funkció egyazon 'iptables'-el kezdődik,
addig ez IOS-ben 'ip nat' illetve 'ip access-group'. Az interfészre rakott access-group meg nem
lehet csak input vagy output irányban, forward nincs is értelmezve, hiszen router, az a dolga...

"Mondjuk ez az ACL-es hasonlat sántít kicsit..."
Mivel a CLI szemléletbeli különbségeket képvisel, ezért teljesen azonos nem lehet. Ezért is használtam a "hasonló" ill. "hasonlítanak egymáshoz" kifejezéseket, nem pedig az "azonos" szót.

"Míg linuxon mindkét, egymástól teljesen független funkció egyazon 'iptables'-el kezdődik, addig ez IOS-ben 'ip nat' illetve 'ip access-group'."
Viszont ez is sántít. Ha CLI szempontból Linuxon mindkét funkciót az iptables nyakába varrjuk, és nem a paraméterezett formához társítjuk őket, akkor IOS-ben mindkettő ip-vel kezdődik... Az hasonlóság az iptables -t filter és az ip access-group; valamint az iptables -t nat és az ip nat inside source, ip nat source között áll fent.

"Az interfészre rakott access-group meg nem lehet csak input vagy output irányban, forward nincs is értelmezve"
Az interfész szemszögéből nem jelölt, de értelmezett. A ZBFW-be meg ne menjünk bele, mert ott még szét is van szedve, lásd Self zone.

Kicsit félrevisszük a topikot ezzel a ciscos témával, igazából csak arra próbáltam rámutatni, hogy mindkét rendszerben egymástól független módon kell megadni a natolási- és a tűzfalszabályokat, azaz természetes, hogy az átmenő forgalomra érvényes csomagszűrést képviselő filter tábla FORWARD láncában is át kell engedni, nem elég csak a nat tábla POSTROUTING-ja, és nem kirívó a linuxos megközelítés a Ciscoéhoz viszonyítva sem.

Köszönöm szépen, működik:D

Egy kérédésem lenne:

echo 1 > /proc/sys/net/ipv4/ip_forward
/sbin/iptables -t nat -A POSTROUTING -o eth0 -s 192.168.1.0/24 -j MASQUERADE

Ezt a két sort beállítom, akkor is megy már a NAT, az utolsó két sorra miért is van szükség?

"az utolsó két sorra miért is van szükség?"
Mert azt a forgalmat ki is akarod engedni a tűzfalon - majd utána natolni -, illetve a visszirányt pedig be. Abból indult ki, hogy mivel nem ismerjük az eddigi szabályaidat, inkább jelzi, hogy ezzel is törődni kell. Persze alapállapotban a FORWARD lánc üres, és a default policy ACCEPT, ezért menni fog - csak tűzfalazás nem lesz, kizárólag NAT.