Címlap » Fórum » Linux » SUSE Linux

iptables port átirányítás két kártya között squid proxy-val [megoldva]

 ( szotsaki | 2007. április 14., szombat - 22:48 )

Sziasztok!

Szeretném beállítani, hogy egy routernek szánt gép transzparensen irányítson minden forgalmat a squid proxyra.

Maga a squid teljesen jól működik, ha a böngészőben beállítom a 3128-as portot. De azt szeretném elérni, hogy minden kapcsolat menjen át a proxyn, és hogy tulajdonképpen a csak a 80-as és a 443-as port legyen nyitva (ezt a squid is le tudja kezelni).

Már vagy öt órája a Google-t túrom, hogy hogyan lehetne ezt megoldani.
Amit eddig találtam, azok mind egy-két soros iptables megoldások voltak, és szerintem sem túlságosan hosszabb, csak sehogy sem akar sikerülni.

Az első hálókártya, az eth0 címe 192.168.1.8. Erre van rákötve a netkábel.
A második kártya, az eth2 pedig a 192.168.0.1 címre van beállítva.
(Az eth1 nincs beállítva, csak tétlenül figyel a gépben)
A többi gép rendesen kommunikál a router géppel az eth2-es kártyán keresztül, tehát a net tökéletesen működik.
Bármit állítok be iptables-ben, semmi hatása nincs, a böngészők a proxy megkerülésével közlekednek.

Ahogy láttam fórumokon, azz IPv4 forward szokott gyakran hiba lenni, de azt bekapcsoltam (/proc/sys/net/ip_forward értéke 1)

A mostani iptable-m az alap SUSE által szolgáltatott.

Előre is köszönök minden segítséget!

‹ Suse 10.0 x86_64 hang probléma SUSE-Linux-10.1 - GM-DVD-x86_64 ›
 »
  • A hozzászóláshoz belépés szükséges
  • 3742 olvasás

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.
 ( bastya_elvtars | 2007. április 14., szombat - 23:14 )

squid -v mit mond?
szerk.: amúgy meg nem értem... úgy van, hogy a 192.168.1.x a router, a 192.168.1.x pedig egy natolt interface a nat mögött, amivel tesztelsz, ugye?
--
'Please, just tell people to use Windows.' - Linus Torvalds on KDE and GNOME
Registered M$funboy #006 (vigyázat: memetikai dágvány!!!11)

 ( szotsaki | 2007. április 14., szombat - 23:17 )

squid -v
Squid Cache: Version 2.6.STABLE6
configure options:  '--prefix=/usr' '--sysconfdir=/etc/squid' '--bindir=/usr/sbin' '--sbindir=/usr/sbin'
'--localstatedir=/var' '--libexecdir=/usr/sbin' '--datadir=/usr/share/squid' '--mandir=/usr/share/man' '--with-dl'
'--with-maxfd=4096' '--with-valgrind-debug' '--enable-snmp' '--enable-carp' '--enable-auth=basic digest negotiate ntlm'
'--enable-basic-auth-helpers=LDAP MSNT NCSA PAM SMB YP getpwnam multi-domain-NTLM'
'--enable-ntlm-auth-helpers=SMB fakeauth no_check' '--enable-digest-auth-helpers=ldap password'
'--enable-external-acl-helpers=ip_user ldap_group session unix_group wbinfo_group' '--enable-ntlm-fail-open'
'--enable-arp-acl' '--enable-htcp' '--enable-underscores' '--enable-stacktraces' '--enable-delay-pools' '--enable-useragent-log'
'--enable-referer-log' '--enable-forward-log' '--enable-multicast-miss' '--enable-ssl' '--enable-cache-digests'
'--enable-auth-on-acceleration' '--enable-storeio=aufs,coss,diskd,null,ufs' '--enable-linux-netfilter'
'--enable-removal-policies=heap,lru' '--enable-icmp' '--with-samba-sources=/usr/include/samba' '--enable-large-cache-files'
'--enable-x-accelerator-vary' '--enable-follow-x-forwarded-for'
'CFLAGS=-O2 -march=i586 -mtune=i686 -fmessage-length=0 -Wall -D_FORTIFY_SOURCE=2 -g -fPIE -DLDAP_DEPRECATED -fno-strict-aliasing' 'LDFLAGS=-pie'

Terjedelmes lista :D

Amúgy úgy ellenőrzöm, hogy mikor működik, hogy letilom a squidben az IE-t, és Operában egy lapot IE maszkolásra állítok. Ha "hozzáfárás megtagadva" hiba jelenik meg, akkor megy keresztül a forgalom a proxyn keresztül.

Szerk.: Igen, most nincs élesben a gép, így egy mezei router osztja el a netet, aminek az címe 192.168.1.2. Ez be is van állítva, mint alapértelmezett átjáró; a router - gép között pedig egy kábel fut az eth0 kártyába.

 ( bastya_elvtars | 2007. április 14., szombat - 23:18 )

http://tinyurl.com/33bcb4
Nyilván a célport 80 és 443 is legyen.
--
'Please, just tell people to use Windows.' - Linus Torvalds on KDE and GNOME
Registered M$funboy #006 (vigyázat: memetikai dágvány!!!11)

 ( szotsaki | 2007. április 15., vasárnap - 0:28 )

A blogban felsorolt négy konfigfájl-paranccsal már találkoztam, tényleg mindig hibát írt ki. Most már tudom, hogy az új verzió hozta :D
A transparent szót beállítottam, eddig rendben van.

Az "iptables -A PREROUTING -i eth2 -p tcp –-dport 80 -j REDIRECT –-to-port(s) 3128" parancs nem működik, a "No chain/target/match by that name" hibát adja.

 ( bastya_elvtars | 2007. április 15., vasárnap - 0:34 )

Sajna ebben nem tudok segíteni, nem értek az iptables-höz.
--
'Please, just tell people to use Windows.' - Linus Torvalds on KDE and GNOME
Registered M$funboy #006 (vigyázat: memetikai dágvány!!!11)

 ( mn3monic | 2007. április 15., vasárnap - 1:32 )

Annyira en sem ertek hozza, de nem kellene meg a -t nat is? es --to-port(s) helyett --to-port

 ( kbela | 2007. április 15., vasárnap - 8:27 )

Igen helyesen igy nez ki:

iptables -t nat -A PREROUTING -i eth2 -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 3128

Igy kell mukodjon, a klienseken a bongeszoben nem kell semmit sem allitani. Amugy mit ertesz a "minden forgalom" alatt?

 ( szotsaki | 2007. április 15., vasárnap - 9:11 )

Köszönöm, ezt a sort végre elfogadta.
De nem akar vele menni. Szerintem valahol előbb megy ki a csomag, minthogy elérné ezt a szabályt.

Készítettem egy ilyen szűrőt:
iptables -t nat -A PREROUTING -i eth2 -p tcp -m tcp --dport 80 -j LOG --log-prefix "80-as port: "

Ahogy néztem, SUSE-ban az /etc/firewall fájlba logol, de semmi nyoma ennek a sornak.
A PREROUTING keresésére ezt adja:

iptables-save |grep -i prerouting
:PREROUTING ACCEPT [498:213018]
:PREROUTING ACCEPT [2946:1402868]
:PREROUTING ACCEPT [17:1042]
-A PREROUTING -i eth2 -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 3128
-A PREROUTING -i eth2 -p tcp -m tcp --dport 80 -j LOG --log-prefix "80-as port: "

Minden forgalom alatt egy széles porttartományt értek.

Edit: Feltöltöttem a két fájlt, az iptables-t és az iptables save-et.

 ( kbela | 2007. április 15., vasárnap - 9:17 )

Elobb nem mehet ki mert ez a PREROUTING, ez az elso amit nez. Tehat biztos atiranyitja a portot, ha a keres az eth2-rol jon.

A kerdes az hogy mit jelent hogy nem megy? Kerlek reszletezd egy kicsit. Mit csinaltal, mit probaltal es mi az ami nem mukodik.

 ( szotsaki | 2007. április 15., vasárnap - 9:43 )

Először teljesen kipucoltam az iptablest:

iptables -F
iptables -t nat -F
iptables -t filter -F
iptables -X

Újraindítottam a SuSEfirewall2_setup szolgáltatást, így mindent visszapakolt bele.

Majd utána beírtam (most a logot előre) a két sort:
iptables -t nat -A PREROUTING -i eth2 -p tcp -m tcp --dport 80 -j LOG --log-prefix "80-as port: "
iptables -t nat -A PREROUTING -i eth2 -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 3128
(A mostani állapot van a két linkelt fájlban)

Ellenőriztem még egyszer a hálózati csatolókat ifconfiggal:
eth0: 192.168.1.8 - Internet (jelenleg, átmenetileg egy routerbe csatlakozik)
eth1: No configuration found for eth1 (csak üresen van a gépben)
eth2: 192.168.0.1 - Belső háló (az internet működik egy másik gépről)

Ha megfordítom a PREROUTING sorok beírásának és a tűzfal újraindításának sorrendjét, sajnos az sem segít, a böngészők proxy nélkül mennek a neten.

 ( kbela | 2007. április 15., vasárnap - 9:47 )

En ezt mind ertettem. De hid el hogy a tuzfalad biztos atiranyitja a portot ha a keres az eth2-on jon.

Meg mindig az a keresem hogy reszletezd hogy mi az ami nem megy, milyen hibaba utkozol. Peldaul hogy mi van bealitva a klienseken, mi tortenik ha meg akarsz nezni egy web oldalt, stb.

Ezek nelkul nem igazan tudunk segiteni.

 ( szotsaki | 2007. április 15., vasárnap - 10:16 )

Igen, az a kis részlet érdekelne engem is :D
Az a baj, hogy működik a web, de proxy nélkül. Tehát a böngésző megy rendesen kifele, csak nem használ proxy-t.

Egyébként úgy érzem, kezdek rájönni :D (kopp-kopp)

Az iptablest csak néhány órája ismerem, de gondolom, a következő szabálynak minden TCP portos forgalmat blokkolnia kéne:
iptables -t nat -A PREROUTING -i eth2 -p tcp -m tcp --dport 1:65535 -j DROP

És valóban leáll a forgalom, de csak a csatlakoztatott gépen.
Ez pedig szerintem azért lehet, mert alapértelmezett átjárónak a következők vannak beállítva:
- router gép: 192.168.1.2, azaz az ideiglenes elosztó router
- csatlakoztatott gép: 192.168.0.1, tehát a router gép. Itt minden forgalom áll, ha blokkolva van a TCP porttartomány.

Rögtön megnézem az átirányítást.

 ( kbela | 2007. április 15., vasárnap - 10:28 )

Ha mukodik a web akkor az egy jo hir. Amint mar irtam elobb is a klienseken a bongeszokben nem kel semmit sem megadnod mind proxyt abban az esetben ha a tuzfalbol atiranyitod a 80-as portot. Ezert kerdeztem hogy hogyan vannak a kliensek beallitva, de sajnos suket fulekre talalok.

Utoljara mondom: ha ugy gondolod hogy valami nem mukodik, de nem irod le hogy mit csinaltal es mit tapasztaltal akkor senki sem tud segiteni neked.

 ( szotsaki | 2007. április 15., vasárnap - 10:34 )

Hurrá! SIKER! :D

A csatlakoztatott gépen működik a proxy.

Felteszem, azért nem működik a router PC-n, mert alapértelmezett átjárónak be van állítva a router dobozka (vagy hogy írjam :), és így figyelmen kívül marad a eth2-es csatoló; azon ezekszerint nincs forgalom. Ezért pedig proxy sincs.

Nagyon szépen köszönöm a segítséget mindenkinek!
Rögtön le is írom a legalsó hozzászólásba a megoldást, az archívum kedvéért.

 ( Ajnasz | 2007. április 15., vasárnap - 10:29 )

A nat tábla előtt más táblán is áthaladnak a csomagok, így ha ott van valami szabály, akkor simán elakadhat.

 ( kbela | 2007. április 15., vasárnap - 10:35 )

Igen, de o nem hasznalja sem a raw-ot sem a mangle-t.

 ( kbela | 2007. április 15., vasárnap - 9:28 )

Ugy amugy nem csodalkozom hogy a logban nem jelenik meg, hiszen miutan mar atiranyitottad a 80-as portrol a 3128-ra mar nincs mit logolni. Ha a ket sort kicsereled akkor talan megjelennenek a keresek a 80-as portra a logban es utanna meg szepen atiranyitod.

 ( Panther | 2007. április 15., vasárnap - 9:21 )

iptables -N reject_func
iptables -A reject_func -p tcp -j REJECT --reject-with tcp-reset
iptables -A reject_func -p udp -j REJECT --reject-with icmp-port-unreachable
iptables -A reject_func -j REJECT

iptables -t nat -A PREROUTING -i eth2 -p tcp --dport 80 -j REDIRECT --to-port 3128
iptables -t filter -A FORWARD -i eth2 -p tcp --dport 80 -j reject_func

Nálam ez van és müxik, nem tudom, mi a gond nálad.

 ( szotsaki | 2007. április 15., vasárnap - 10:42 )

A problémát sikerült megoldani!

Az archívum kedvéért leírom összeszedve ide is, hogy a transzparens proxy beállítása a következők szerint kell, hogy történjen:

- squid 2.6 telepítése, majd a http_port 3128 transparent beállítása az /etc/squid/squid.conf fájlban. Transparent nélkül hibát fog dobni a gépeken.
- iptables-höz a követlező két sor hozzáadása:

iptables -t nat -A PREROUTING -i eth1 -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 3128
iptables -t nat -A PREROUTING -i eth1 -p udp -m udp --dport 80 -j REDIRECT --to-ports 3128

Az eth1 legyen a belső hálókártya. Porttartomány meghatározása kettősponttal: 80 helyett mondjuk 1:65535
- a böngészőkben állítani semmit nem kell, alapértelmezettben minden, a router géphez csatlakoztatott gépen már a proxy-n keresztül fog menni a forgalom.

Még egyszer köszönöm a segítséget!