Üdv,
Az alábbi problémára keresek megoldást:
Routerboard RB500-on (mipsel) futó debian sarge, transzparens proxy. Gyártói kernel patch, ipt_REDIRECT.c érintetlen. Néhány nap után nem megy a redirect rule, hiába törlöm és írom be újra, csak a reboot után működik megint. Iptables egyébiránt kifogástalanul teszi a dolgát tovább, nat stb. működik.
Valami tipp hogy hol kutakodjak?
- 2354 megtekintés
Hozzászólások
Elsőkörben logold a csomagokat a REDIRECT target előtt (ugyanazon feltételekkel).
- A hozzászóláshoz be kell jelentkezni
azon mar tul vagyok, ott meg megvannak, a redirect-utan mar nem, sem a tdpdump nem mutatja, sem a squid access logban nem jelenik meg... a proxy mindekozben megy, ha a klienseken beallitom, kifogastalanul vegzi a dolgat
- A hozzászóláshoz be kell jelentkezni
megprobalhatod DNAT-tal.
- A hozzászóláshoz be kell jelentkezni
akkor már nem transzparens, nem lehet tudni az eredeti célcímet és portot.
- A hozzászóláshoz be kell jelentkezni
akkor meg TPROXY - ha fordul mipsre.
- A hozzászóláshoz be kell jelentkezni
Fordul, hiszen nem architektúra-specifikus.
Viszont a legújab változata 2.6-os kernelhez van.
- A hozzászóláshoz be kell jelentkezni
a tproxy kernel/iptables-specifikus, a kernel pedig arch.
de, ha fordul csak orulok neki.
- A hozzászóláshoz be kell jelentkezni
A kernel net/ könyvtárában nincsen architektúra-specifikus dolog, ahol a tproxy kódja van, akkor miért ne fordulna?
szerk: nem próbáltam ki mips-en, de jónéhány vason megy
- A hozzászóláshoz be kell jelentkezni
jovo heten nekifutok...
- A hozzászóláshoz be kell jelentkezni
ok. Van több verziója, a régi az, amit a squid szeret, van tproxy4, ami a www.balabit.hu oldalról letölthetsz és van még egy, amely a 4-es "új", módosított változata, az meg http://people.netfilter.org/hidden/tproxy/ könyvtárban van. Az utóbbi kettő közt az az alapvető különbség, hogy a TPROXY target az újban a mangle táblában van és socket match kell hozzá, a "régebbi" meg a tproxy táblát használja és tproxy match kell a filter táblában. Többé-kevésbé mindkettőhöz van man oldal.
Ha valamiért nem menne, akkor szólj, megnézem :)
- A hozzászóláshoz be kell jelentkezni
erdekes modon a dnat-ra is u.a. a jelenseg
- A hozzászóláshoz be kell jelentkezni
Squid verziója? Nem elképzelhető, hogy ott a gond?
It doesn't matter if you like my song as long as you can hear me sing
- A hozzászóláshoz be kell jelentkezni
a squid folyamatosan jol megy, azzal nincs gond....
egyebkent:
Architecture: mipsel
Version: 2.5.9-10sarge2
- A hozzászóláshoz be kell jelentkezni
Pontosan mit jelent az, hogy "nem megy"?
Nincs esetleg tele a conntrack tábla?
- A hozzászóláshoz be kell jelentkezni
az if-en beérkező x ip 80-as portjára irányuló csomagok egyszerűen eltűnnek,
nem jelennek meg a redirect után a 3128-as porton
conntrack tabla:
cgh:~# cat /proc/sys/net/ipv4/ip_conntrack_max
36864
cgh:~# cat /proc/net/ip_conntrack | wc -l
42
- A hozzászóláshoz be kell jelentkezni
IP checksum hiba? Milyen hálókártya van a gépben?
tcpdump-al látod még a bejövő csomagokat?
- A hozzászóláshoz be kell jelentkezni
logokban semmi ip checksum hibára utaló jel, az eth beepitett VIA Rhine, egyebiránt kifogástalan...
tcpdump és a redirect-el megegyező -j LOG rule is látja:
Oct 9 13:21:02 cgh kernel: IN=eth1 OUT= MAC=00:0c:42:04:83:21:00:0b:6a:4e:e0:1f:08:00 SRC=192.168.10.32 DST=217.20.131.2 LEN=48 TOS=0x00 PREC=0x00 TTL=128 ID=50387 DF PROTO=TCP SPT=1421 DPT=80 WINDOW=65535 RES=0x00 SYN URGP=0
13:26:30.702175 IP (tos 0x0, ttl 128, id 52239, offset 0, flags [DF], proto: TCP (6), length: 48) 192.168.10.32.1429 > ldir-loopback.index.hu.www: S, cksum 0x04c6 (correct), 4177025180:4177025180(0) win 65535
13:26:30.702603 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: TCP (6), length: 40) ldir-loopback.index.hu.www > 192.168.10.32.1429: R, cksum 0x3176 (correct), 0:0(0) ack 4177025181 win 0
eközben a squid logban semmi jele a kérésnek...
- A hozzászóláshoz be kell jelentkezni
OK. Miközben próbálkozol, a /proc/net/ip_conntrack-ban mit látsz? Nagyjából a következő kellene:
- a REDIRECT előtti LOG szabály eredménye
- hozzá a /proc/net/ip_conntrack-beli bejegyzés
- A hozzászóláshoz be kell jelentkezni
iptables:
Oct 9 14:16:37 cgh kernel: IN=eth1 OUT= MAC=00:0c:42:04:83:21:00:0b:6a:4e:e0:1f:08:00 SRC=192.168.10.32 DST=217.20.131.2 LEN=48 TOS=0x00 PREC=0x00 TTL=128 ID=63981 DF PROTO=TCP SPT=1478 DPT=80 WINDOW=65535 RES=0x00 SYN URGP=0
conntrack:
tcp 6 7 CLOSE src=192.168.10.32 dst=217.20.131.2 sport=1478 dport=80 src=192.168.10.253 dst=192.168.10.32 sport=3207 dport=1478 use=1 mark=0 bytes=264
- A hozzászóláshoz be kell jelentkezni
Kapcsolat-ütközés: a conntrack táblában az előző kapcsolat(ok) fogják a helyeket. Portot átírni nem lehet, ezért a conntrack az ütközést nem tudja feloldani. Mi a kernel pontos verziója?
- A hozzászóláshoz be kell jelentkezni
2.4.31 vanilla, de alaplapi patch nincs más verzióra, ezzel kell boldogulnom
- A hozzászóláshoz be kell jelentkezni
pár másodperc alatt eltűnik a conntrack bejegyzés,
a fenti állapotot éppen hogy el lehet csípni
- A hozzászóláshoz be kell jelentkezni
10s a CLOSE állapotra a timeout értéke.
Ha ez a kernel verzió és frissíteni nem lehet, akkor sok lehetőséged nincsen: próbáld meg, hogy megfelezed a timeout értékét a /proc alatt (ip_ct_tcp_timeout_close).
- A hozzászóláshoz be kell jelentkezni
még valami felmerült bennem: mivel csak 32M ram van a gépben,
nem lehet hogy összefüggés van relatíve a kevés memória és a
hibajelenség között?
conntrack hashsize modosítása? a conntrack max-ot is alaptalanul
nagyra veszi (36864) a hash mérete jelenleg:
cgh:~# cat /proc/sys/net/ipv4/netfilter/ip_conntrack_buckets
9216
- A hozzászóláshoz be kell jelentkezni
Nem, semekkora RAM nem segítene, mert az ütközés a régi és az új kapcsolat között nem feloldható.
Ha nem lokális proxy lenne, akkor nem lenne ilyen probléma.
- A hozzászóláshoz be kell jelentkezni
ezt nem teljesen értem, légyszi segíts felfognom...
ha a conntrack táblában ütkozés van, akkor miert nem működik azután ha a táblábol törlődik a bejegyzés? és miért működik x ideig a reboot után?
próbáltam a fenti timeoutot visszavenni akaár 1s-re, nem segített
- A hozzászóláshoz be kell jelentkezni
A kapcsolat minden paramétere rögzített:
odafele: kliens IP, source port -> szerver, 80-as port
visszafele: tűzfal, squid port -> kliens, source port
Ha ugyanez a kliens ugyanezzel a forrásporttal ugyanehhez a szerverhez akar kapcsolódni, akkor amíg a conntrack táblában benne van az előző kapcsolat, az nem megy. Akármekkora a tábla, a fönti négyes ütközik.
Ha a táblából törlődik az előző kapcsolat, akkor a kliens eléri a szervert (vagy nem ez a helyzet?? Vagy valóban nincs a táblában ütköző bejegyzés?).
A timeout beállítás csak új kapcsolatokra fog élni.
A 2.4.31 biztosan nem tud vele mit kezdeni, a 2.6-os sorozat kezeli az újranyitott kapcsolatokat (bár ott is van egy bug, de a javítása holnap már kinn lesz).
- A hozzászóláshoz be kell jelentkezni
bocs ha nem volt eddig egyértelmű: nincs ütköző bejegyzés, a webet a reboot után x ideig (jellemzően néhány napig) elérik a transzparens proxy-n keresztül a gépek...
port gond sincs, mindegy egyes kérésnél szépen növekszik a kliens forrásportja, a timeout után pedig eltűnik a conntrack táblából a bejegyzés
- A hozzászóláshoz be kell jelentkezni