NAT-olt halo, halozati problema

Linux-haladó

Sziasztok!

Belefutottam a kovetkezo problemaba:

Adott egy tuzfal gep. 4 db internetkapcsolat, 1 db LAN kapcsolat
A LAN interface be van bridzselve a br0-ba (igazabol nem hiszem, hogy ez relevans info, de azert leirom)

A kovetkezo az eset:
Adott egy URL: http://www.bramac.hu/uploads/tx_ricrotation/Tetogaleria_piros.jpg
Ezzel reprodukalhato az en halozatomban a hiba.

Ha az URL-t a tuzfal gepen toltom le, akkor mdnen OK (csatoltam a tcpdump-ot firewall.tcpdump.txt)
Ha egy belos geprol (raadasul az is linux, egyeseru wget) akkor meg 10%-nal alldoan megall...(csatoltam a tcpdump-ot belsogep.tcpdump.txt es ennek az ucso sora ismetlodik, amig le nem allitom a wget-et)

---------------
wget http://www.bramac.hu/uploads/tx_ricrotation/Tetogaleria_piros.jpg
--16:05:18-- http://www.bramac.hu/uploads/tx_ricrotation/Tetogaleria_piros.jpg
=> `Tetogaleria_piros.jpg.11'
Resolving www.bramac.hu... 212.41.251.147
Connecting to www.bramac.hu|212.41.251.147|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 34,682 (34K) [image/jpeg]

10% [=======> ] 3,808
---------------

Van valakinek barmilyen otlete? miert nem toltodik le, miert all meg a kapcsolat? Mindegy milyen otlet szivesen fogadok barmit...meg azt is hogy aldozzak egy fekete kakast es akkor megoldodik. Mi az amit meg kene nezni?
Kerlek benneteket mondjatok valamit, mert en total tanacstalan vagyok. Mert ez csak nehany ilyennel fordul elo...tobbnyire kepeknel. pl. a HTML-eket siman betolti a weboldalakrol, de a kepeket nem akarja letolteni...es nem minden kepet cska nehanyat, ezzel az URL-el pont reprodukalhatoa aproblema.

Udv,
I.

ui.: Plz, HELP!

--->firewall.tcpdump.txt
16:03:14.479400 IP fw.tld.59117 > mail.inode.gugler.at.www: S 2378061223:2378061223(0) win 5808
16:03:14.533706 IP mail.inode.gugler.at.www > fw.tld.59117: S 378823127:378823127(0) ack 2378061224 win 5792
16:03:14.533740 IP fw.tld.59117 > mail.inode.gugler.at.www: . ack 1 win 182
16:03:14.533909 IP fw.tld.59117 > mail.inode.gugler.at.www: P 1:146(145) ack 1 win 182
16:03:14.588621 IP mail.inode.gugler.at.www > fw.tld.59117: . ack 146 win 54
16:03:14.590345 IP mail.inode.gugler.at.www > fw.tld.59117: . 1:1401(1400) ack 146 win 54
16:03:14.590363 IP fw.tld.59117 > mail.inode.gugler.at.www: . ack 1401 win 272
16:03:14.590948 IP mail.inode.gugler.at.www > fw.tld.59117: . 1401:2801(1400) ack 146 win 54
16:03:14.590974 IP fw.tld.59117 > mail.inode.gugler.at.www: . ack 2801 win 362
16:03:14.646462 IP mail.inode.gugler.at.www > fw.tld.59117: . 2801:4201(1400) ack 146 win 54
16:03:14.646481 IP fw.tld.59117 > mail.inode.gugler.at.www: . ack 4201 win 452
16:03:14.647997 IP mail.inode.gugler.at.www > fw.tld.59117: . 4201:5601(1400) ack 146 win 54
16:03:14.648013 IP fw.tld.59117 > mail.inode.gugler.at.www: . ack 5601 win 542
16:03:14.649361 IP mail.inode.gugler.at.www > fw.tld.59117: . 5601:7001(1400) ack 146 win 54
16:03:14.649377 IP fw.tld.59117 > mail.inode.gugler.at.www: . ack 7001 win 632
16:03:14.649684 IP mail.inode.gugler.at.www > fw.tld.59117: P 7001:8401(1400) ack 146 win 54
16:03:14.649698 IP fw.tld.59117 > mail.inode.gugler.at.www: . ack 8401 win 722
16:03:14.705790 IP mail.inode.gugler.at.www > fw.tld.59117: . 8401:9801(1400) ack 146 win 54
16:03:14.705810 IP fw.tld.59117 > mail.inode.gugler.at.www: . ack 9801 win 812
16:03:14.706194 IP mail.inode.gugler.at.www > fw.tld.59117: . 9801:11201(1400) ack 146 win 54
16:03:14.706210 IP fw.tld.59117 > mail.inode.gugler.at.www: . ack 11201 win 902
16:03:14.707102 IP mail.inode.gugler.at.www > fw.tld.59117: . 11201:12601(1400) ack 146 win 54
16:03:14.707117 IP fw.tld.59117 > mail.inode.gugler.at.www: . ack 12601 win 992
16:03:14.707812 IP mail.inode.gugler.at.www > fw.tld.59117: . 12601:14001(1400) ack 146 win 54
16:03:14.707826 IP fw.tld.59117 > mail.inode.gugler.at.www: . ack 14001 win 1082
16:03:14.707947 IP mail.inode.gugler.at.www > fw.tld.59117: . 14001:15401(1400) ack 146 win 54
16:03:14.707962 IP fw.tld.59117 > mail.inode.gugler.at.www: . ack 15401 win 1172
16:03:14.708899 IP mail.inode.gugler.at.www > fw.tld.59117: . 15401:16801(1400) ack 146 win 54
16:03:14.708914 IP fw.tld.59117 > mail.inode.gugler.at.www: . ack 16801 win 1262
16:03:14.762271 IP mail.inode.gugler.at.www > fw.tld.59117: . 16801:18201(1400) ack 146 win 54
16:03:14.762288 IP fw.tld.59117 > mail.inode.gugler.at.www: . ack 18201 win 1352
16:03:14.763514 IP mail.inode.gugler.at.www > fw.tld.59117: . 18201:19601(1400) ack 146 win 54
16:03:14.763530 IP fw.tld.59117 > mail.inode.gugler.at.www: . ack 19601 win 1442
16:03:14.763707 IP mail.inode.gugler.at.www > fw.tld.59117: . 19601:21001(1400) ack 146 win 54
16:03:14.763721 IP fw.tld.59117 > mail.inode.gugler.at.www: . ack 21001 win 1532
16:03:14.764889 IP mail.inode.gugler.at.www > fw.tld.59117: . 21001:22401(1400) ack 146 win 54
16:03:14.764905 IP fw.tld.59117 > mail.inode.gugler.at.www: . ack 22401 win 1622
16:03:14.765710 IP mail.inode.gugler.at.www > fw.tld.59117: . 22401:23801(1400) ack 146 win 54
16:03:14.765725 IP fw.tld.59117 > mail.inode.gugler.at.www: . ack 23801 win 1712
16:03:14.765835 IP mail.inode.gugler.at.www > fw.tld.59117: . 23801:25201(1400) ack 146 win 54
16:03:14.765850 IP fw.tld.59117 > mail.inode.gugler.at.www: . ack 25201 win 1802
16:03:14.766434 IP mail.inode.gugler.at.www > fw.tld.59117: . 25201:26601(1400) ack 146 win 54
16:03:14.766450 IP fw.tld.59117 > mail.inode.gugler.at.www: . ack 26601 win 1892
16:03:14.779392 IP mail.inode.gugler.at.www > fw.tld.59117: . 26601:28001(1400) ack 146 win 54
16:03:14.779410 IP fw.tld.59117 > mail.inode.gugler.at.www: . ack 28001 win 1982
16:03:14.779852 IP mail.inode.gugler.at.www > fw.tld.59117: . 28001:29401(1400) ack 146 win 54
16:03:14.779867 IP fw.tld.59117 > mail.inode.gugler.at.www: . ack 29401 win 2003
16:03:14.781324 IP mail.inode.gugler.at.www > fw.tld.59117: . 29401:30801(1400) ack 146 win 54
16:03:14.781340 IP fw.tld.59117 > mail.inode.gugler.at.www: . ack 30801 win 2003
16:03:14.781449 IP mail.inode.gugler.at.www > fw.tld.59117: . 30801:32201(1400) ack 146 win 54
16:03:14.781464 IP fw.tld.59117 > mail.inode.gugler.at.www: . ack 32201 win 2003
16:03:14.781572 IP mail.inode.gugler.at.www > fw.tld.59117: . 32201:33601(1400) ack 146 win 54
16:03:14.820577 IP fw.tld.59117 > mail.inode.gugler.at.www: . ack 33601 win 2003
16:03:14.821572 IP mail.inode.gugler.at.www > fw.tld.59117: . 33601:35001(1400) ack 146 win 54
16:03:14.822098 IP mail.inode.gugler.at.www > fw.tld.59117: P 35001:35075(74) ack 146 win 54
16:03:14.822114 IP fw.tld.59117 > mail.inode.gugler.at.www: . ack 35075 win 2003
16:03:14.822655 IP fw.tld.59117 > mail.inode.gugler.at.www: F 146:146(0) ack 35075 win 2003
16:03:14.876883 IP mail.inode.gugler.at.www > fw.tld.59117: F 35075:35075(0) ack 147 win 54
16:03:14.876907 IP fw.tld.59117 > mail.inode.gugler.at.www: . ack 35076 win 2003

-->belsogep.tcpdump.txt
16:05:17.992902 IP fw.tld.60114 > mail.inode.gugler.at.www: S 2760099820:2760099820(0) win 5840
16:05:18.047002 IP mail.inode.gugler.at.www > fw.tld.60114: S 518607212:518607212(0) ack 2760099821 win 5792
16:05:18.047192 IP fw.tld.60114 > mail.inode.gugler.at.www: . ack 1 win 46
16:05:18.047217 IP fw.tld.60114 > mail.inode.gugler.at.www: P 1:146(145) ack 1 win 46
16:05:18.102585 IP mail.inode.gugler.at.www > fw.tld.60114: . ack 146 win 54
16:05:18.103706 IP mail.inode.gugler.at.www > fw.tld.60114: . 1:1401(1400) ack 146 win 54
16:05:18.104063 IP fw.tld.60114 > mail.inode.gugler.at.www: . ack 1401 win 69
16:05:18.104445 IP mail.inode.gugler.at.www > fw.tld.60114: . 1401:2801(1400) ack 146 win 54
16:05:18.104811 IP fw.tld.60114 > mail.inode.gugler.at.www: . ack 2801 win 91
16:05:18.107659 IP mail.inode.gugler.at.www > fw.tld.60114: . 2801:4201(1400) ack 146 win 54
16:05:18.108014 IP fw.tld.60114 > mail.inode.gugler.at.www: . ack 4201 win 114
16:05:18.161203 IP mail.inode.gugler.at.www > fw.tld.60114: . 4201:5601(1400) ack 146 win 54
16:05:18.161809 IP mail.inode.gugler.at.www > fw.tld.60114: . 5601:7001(1400) ack 146 win 54
16:05:18.162166 IP fw.tld.60114 > mail.inode.gugler.at.www: . ack 4201 win 114
16:05:18.162211 IP mail.inode.gugler.at.www > fw.tld.60114: . 7001:8401(1400) ack 146 win 54
16:05:18.162568 IP fw.tld.60114 > mail.inode.gugler.at.www: . ack 4201 win 114
16:05:18.162634 IP mail.inode.gugler.at.www > fw.tld.60114: . 8401:9801(1400) ack 146 win 54
16:05:18.162990 IP fw.tld.60114 > mail.inode.gugler.at.www: . ack 4201 win 114
16:05:18.164320 IP mail.inode.gugler.at.www > fw.tld.60114: . 9801:11201(1400) ack 146 win 54
16:05:18.164443 IP mail.inode.gugler.at.www > fw.tld.60114: P 11201:12601(1400) ack 146 win 54
16:05:18.164674 IP fw.tld.60114 > mail.inode.gugler.at.www: . ack 4201 win 114
16:05:18.164798 IP fw.tld.60114 > mail.inode.gugler.at.www: . ack 4201 win 114
16:05:18.218110 IP mail.inode.gugler.at.www > fw.tld.60114: . 12601:14001(1400) ack 146 win 54
16:05:18.218470 IP fw.tld.60114 > mail.inode.gugler.at.www: . ack 4201 win 114
16:05:18.219314 IP mail.inode.gugler.at.www > fw.tld.60114: P 14001:15401(1400) ack 146 win 54
16:05:18.219669 IP fw.tld.60114 > mail.inode.gugler.at.www: . ack 4201 win 114
16:05:18.219926 IP mail.inode.gugler.at.www > fw.tld.60114: . 4201:5601(1400) ack 146 win 54
16:05:18.543978 IP mail.inode.gugler.at.www > fw.tld.60114: . 4201:5601(1400) ack 146 win 54
16:05:19.204541 IP mail.inode.gugler.at.www > fw.tld.60114: . 4201:5601(1400) ack 146 win 54
16:05:20.524668 IP mail.inode.gugler.at.www > fw.tld.60114: . 4201:5601(1400) ack 146 win 54
16:05:23.165270 IP mail.inode.gugler.at.www > fw.tld.60114: . 4201:5601(1400) ack 146 win 54
16:05:28.446744 IP mail.inode.gugler.at.www > fw.tld.60114: . 4201:5601(1400) ack 146 win 54
16:05:29.265357 IP fw.tld.60114 > mail.inode.gugler.at.www: F 146:146(0) ack 4201 win 114
16:05:29.355527 IP mail.inode.gugler.at.www > fw.tld.60114: . ack 147 win 54
16:05:39.009935 IP mail.inode.gugler.at.www > fw.tld.60114: . 4201:5601(1400) ack 147 win 54
16:06:00.137250 IP mail.inode.gugler.at.www > fw.tld.60114: . 4201:5601(1400) ack 147 win 54
16:06:42.387577 IP mail.inode.gugler.at.www > fw.tld.60114: . 4201:5601(1400) ack 147 win 54

  • 1254 megtekintés

( uid_4672 | 2008. 07. 26., szo – 16:50 )

a második tcpdumpból az látszik, hogy a gép próbálja küldeni az ackot 4201-gyel, és csak próbálja, de valahogy az nem ér el a célig.
Nincs valami MTU probléma? Mi lesz, ha kisebbre állítod?

( gabori | 2008. 07. 26., szo – 17:21 )

Még hogy fekete kakas. Ilyen tudománytalan, idejét múlt hozzáállást. Mindenki tudja, hogy ilyenkor a hamvas (de azért golyó értett) szűz lány a megoldás.:)

Komolyra fordítva a szót ez szerintem inkább valami hardver(beleértve a patch kábelt) hiba. Első kanyarban én azzal próbálkoznék, hogy a gép leállít boot from live cd. Nat kézzel belő. Majd teszt br0 nélkül. Majd kábel, switch hálókártya csere.
Ja nem írtad, hogy a kliens micsoda, csak az egyiken van a hiba vagy minden. Stb.

LIVE CD-s bootot kiprobalom valamelyik ejszaka. Van javaslatod, hogy melyikkel teszteljek (LiveCD)?

Tovabba, ha sikeres lenne a teszt, akkor szerinted mi lenne a kovetkezo lepes? mert azt esetleg most is meg tudom csinlni, hogy kinyirom a bridge interface-t es kiprobalom ugy...de azt meg nem csinaltam...

( Bbt | 2008. 07. 26., szo – 17:31 )

MTU problémnak tűnik. Milyen netkapcsolatok?

Van 1 db IW Berelt Mikro (PPPOE felulet) (POINTOPOINT NOARP MTU:1492)
Van 1 db IW ADSL gagyi, hetkoznapi (PPPOE felulet) (POINTOPOINT NOARP MTU:1492)
Van 1 db DATANET Berelt Mikro (Ethernet felulet) (BROADCAST MTU:1500)
Van 1 db UPC Berelt (Ethernet felulet) (BROADCAST MTU:1500)

LAN Interface, ami egy bridge (BROADCAST MTU:1500)

Na mar most olyat is csinltam, hogy fixen valamelyiken kuldtem ki es mindig ezt csinalta.
Az MTU-t szivsen atalltom, gondolom a LAN oldalon kellene elso korben, vagy hol gondoljatok?.
Levegyem mondjuk 1400-ra?

masik kerdesre valaszolva a teljes halozatban produkalja ezt a hibat, telejsen mindegy, hogy windows gep a kliens vagy linux....ezert gondoltam, hogy NAT problema, csak linuxrol egyszerubb nekem tesztelni, mint windowsrol.

Szoval hol allitsak MTU-t?

mas:
A kabel hibat is jo otletnek tartom. Es mar csinaltuk azt, hogy kozvetlen a LAN interface-be bedugtam (ugyan csak egy gagyi 8-as switchet, de a lenyeg, hogy megcsapoltam ott) egy switchet a switrchbe a laptopomat, es a laninterface-t meg a belso LAN-t es a latopomrol is produkalta, ami igy mar csak 2 db kabelen (ujjonan kerul a rendszerbe) es a 8-as switchen csatlakozott a halora. Szoval akkor annak a 2 kabelnek is hibasnak kellene legyen meg a 8-as switchnek is amivel megcsapoltam a LAN labat.

szoval ezt elvetettuk, de ha kell, akkor ilyen hitelesitett 50cm-es patchkabelekkel es egy linksys layer 3-as switchel ismet kiprobalom, de elotte meg inkabb valmai szoftveres dolgora gondolok...

Udv,
I.

A gond a két PPPoE-s kapcsolatnál lehet, ahogy írod is, 1492 byte az MTU, ezért 1452 lesz az MSS.

a) Tűzfal PPPoE-s interfészein vedd le az MSS-t 1452 byte-ra.
b) A LAN oldalon a klienseken vedd le az MTU-t 1492 byte-ra.

Természetesen az a) változat a jobb, ezt az iptables mss moduljával tudod elérni.

Meg valami elkezdtem az otleteitek alapjan a temanak utanaolvasni.
Na ez azt irja, hogy ez ott fordul elo, ahol szurik az ICMP uzeneteket :) de en ennyire nem vagyok hulye :) meg azt sem hiszem, hogy 4 szolgaltatobol, 4 szurni ezeket...de mondjuk semmi sem kizart... :)

-A INPUT -p icmp -m icmp --icmp-type 3/4 -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 11 -j ACCEPT
-A FORWARD -p icmp -m icmp --icmp-type 3/4 -j ACCEPT
-A FORWARD -p icmp -m icmp --icmp-type 11 -j ACCEPT
-A OUTPUT -p icmp -m icmp --icmp-type 3/4 -j ACCEPT
-A OUTPUT -p icmp -m icmp --icmp-type 11 -j ACCEPT

szoval valmai mas otlet? mit tegyek meg? amugy midnenhol egysegen 1492-re alitottam az MTU-t a tuzfalon, es belove hagytam a CLAMPMSS-t 1452-on

( hnsz2002 v | 2008. 07. 26., szo – 22:26 )

Csak ezzel az egy linkkel jön elő a probléma?
A tűzfalon meg van engedve kívűlről a RELATED,ESTABLISHED kapcsolat?
Mivel 4 internet kapcsolatod van, gondolom valamiféle lod balancing van. Nem lehet, hogy azon van elállítva valami? Első körben lehet jobb lenne egy netkapcsolattal próbálni.
--
Discover It - Have a lot of fun!

Szia!

Nem, nem csk aezzel az eggyel. Kepek es nagyobb fajlok letoltesenel teljesen rabszodikusan jon elo. Talaltunk egyet, ami produkalja ez minden geprol.
Igen van loadbalancing, de mar azt is csinltam, hogy csak egyetlen kapcsolaton kuldom ki. Konkretan kirpbaltam, hogy csak egy default gateway van es az az egy mar teszt keppen mind a 4 db internetkapcsolat volt.

>A tűzfalon meg van engedve kívűlről a RELATED,ESTABLISHED kapcsolat?

Persze, sot, hat el is indul es letolt 3000-4000 bytot is csak utana szakad be.

Kezdek nagyon arra hajlani, hogy tenyleg valami fragmentacios problma, tehat MTU de allitgatom itt ossze vissza mindenfele eredmeny nelkul.

ifconfig|grep MTU kimente ez:
UP BROADCAST RUNNING MTU:1500 Metric:1
UP BROADCAST RUNNING MTU:1500 Metric:1
UP BROADCAST RUNNING MTU:1500 Metric:1
UP BROADCAST RUNNING MTU:1500 Metric:1
UP BROADCAST RUNNING MTU:1500 Metric:1
UP BROADCAST RUNNING PROMISC MTU:1500 Metric:1
UP BROADCAST RUNNING MTU:1500 Metric:1
UP BROADCAST RUNNING MTU:1500 Metric:1
UP BROADCAST RUNNING MTU:1500 Metric:1
UP BROADCAST RUNNING MTU:1500 Metric:1
UP LOOPBACK RUNNING MTU:16436 Metric:1
UP POINTOPOINT RUNNING NOARP MTU:1480 Metric:1
UP POINTOPOINT RUNNING NOARP MTU:1492 Metric:1
UP POINTOPOINT RUNNING NOARP MTU:1492 Metric:1
UP BROADCAST RUNNING PROMISC MTU:1500 Metric:1
UP BROADCAST RUNNING PROMISC MTU:1500 Metric:1
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
UP POINTOPOINT RUNNING NOARP MTU:1472 Metric:1
UP POINTOPOINT RUNNING NOARP MTU:1472 Metric:1

Az 1472-es MTU-k azok Site-to-Site VPN interfacek. csak azert itom, ha kerdeznetek. A lenyeg, hogy olvasom ezt az MTU-s dolgokat es talaltam egy kepletet, amit ti bizonyra mar tudtok, mert javasoltatok az 1452-ot. CLAMPMSS={min(MTUs)}-40 => most belottem 1432-re, de igy sem jutottam tul sokra ;( a problema tovabbra is fent all..ja amint latjatok mindig visszallitom 1500-ra , ami azon volt...

Udv,
I.

Teszt linux->
ifconfig|grep MTU
ifconfig |grep MTU
UP BROADCAST RUNNING MULTICAST MTU:1432 Metric:1
UP BROADCAST RUNNING MULTICAST MTU:1432 Metric:1
UP BROADCAST MULTICAST MTU:1432 Metric:1
UP LOOPBACK RUNNING MTU:16436 Metric:1

eredmeny ugyan az
10% lejon es megall...

wget http://www.bramac.hu/uploads/tx_ricrotation/Tetogaleria_piros.jpg
--22:48:37-- http://www.bramac.hu/uploads/tx_ricrotation/Tetogaleria_piros.jpg
=> `Tetogaleria_piros.jpg.3'
Resolving www.bramac.hu... 212.41.251.147
Connecting to www.bramac.hu|212.41.251.147|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 34,682 (34K) [image/jpeg]

10% [=======> ] 3,748

br0 nelkul meg nem probaltam, mert azt be kell jelnetenem, hogy leallas lesz es azt tervezni kell..fogom 2-3 napon belul valmaikor...

Debian Lenny, Linux 2.6.25.10-v1.0 #1 SMP Fri Jul 11 14:06:18 CEST 2008 i686 GNU/Linux

Az iptables az 1 km-es, de amikor kiprobalom br0 nelkul, akkor 3 sor lesz ;) de attol tartok, hogy akkor is ez a szopi lesz...

egyebkent mas otletek? amig a br0 nelkul nem tudom kiprobalni? :) mondom, barmi johet a jelne korulmenyek kozott vevo vagyok mindenre...

Na kinyitottam mindent, es az alabbi script allitotta be a tuzfalat, es ugyan az az eset allt fent, mint eddig. Tovabba lelottem a loadbalancet es csak az egyiken (mar nem is SNAT-al) hanem MASQUAREDE-el NAT-oltam

---script
#!/bin/sh

IPTABLES=/sbin/iptables

#PARAMATEREZESEK
#---------------
echo 0 > /proc/sys/net/ipv4/ip_dynaddr
echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter
echo 0 > /proc/sys/net/ipv4/conf/all/accept_source_route
echo 1 > /proc/sys/net/ipv4/conf/all/accept_redirects
echo 0 > /proc/sys/net/ipv4/conf/all/log_martians
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
echo 0 > /proc/sys/net/ipv4/icmp_echo_ignore_all
echo 0 > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses

#POLICY
$IPTABLES -P INPUT ACCEPT
$IPTABLES -P FORWARD ACCEPT
$IPTABLES -P OUTPUT ACCEPT
$IPTABLES -F -t filter
$IPTABLES -F -t nat
$IPTABLES -F -t mangle

#NAT
$IPTABLES -t nat -A POSTROUTING -o ppp1 -j MASQUERADE

#FILTER
$IPTABLES -A FORWARD -p tcp -m tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1452:65535 -j TCPMSS --set-mss 1432

echo 1 > /proc/sys/net/ipv4/ip_forward ? :)
Amúgy mi ez az utolsó filter, és minek?
[szerk] IPTABLES -t nat -A POSTROUTING -i eth1 -j MASQUERADE
Esetleg próbáld meg így, a kimenő nem is olyan érdekes mint a bejövő kártya.
[szerk2] "Telepitettem egy squid3-at, default konfiggal...ugyan ezt csinlja... ;)"
^ Emiatt lehet ez a gond... nem biztos, de megeshet. Ugyanis ha nem adsz meg neki bemenő interfészt, akkor mindegyikre alkalmazni fogja, ergo a kívűlről jövő kapcsolatokat is masqueradolja :).
--
Discover It - Have a lot of fun!

1)
az ipforward az bent van persze... ;)

2.)
IPTABLES -t nat -A POSTROUTING -i eth1 -j MASQUERADE
postroutingban nem lehet bejovo interface-t hasznlani.... tehat a -i nem megengedett...csak -o
annyiban modositottam, hogy adtam neki forrast (bettem az echo 1 >forwardot is, hogy lassatok ;) )

--->script
#!/bin/sh

IPTABLES=/sbin/iptables

#PARAMATEREZESEK
#---------------
echo 1 > /proc/sys/net/ipv4/ip_forward
echo 0 > /proc/sys/net/ipv4/ip_dynaddr
echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter
echo 0 > /proc/sys/net/ipv4/conf/all/accept_source_route
echo 1 > /proc/sys/net/ipv4/conf/all/accept_redirects
echo 0 > /proc/sys/net/ipv4/conf/all/log_martians
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
echo 0 > /proc/sys/net/ipv4/icmp_echo_ignore_all
echo 0 > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses

#POLICY
$IPTABLES -P INPUT ACCEPT
$IPTABLES -P FORWARD ACCEPT
$IPTABLES -P OUTPUT ACCEPT
$IPTABLES -F -t filter
$IPTABLES -F -t nat
$IPTABLES -F -t mangle

#NAT
$IPTABLES -t nat -A POSTROUTING -o eth4 -s 172.20.0.0/16 -j MASQUERADE

#FILTER
$IPTABLES -A FORWARD -p tcp -m tcp --syn -j TCPMSS --clamp-mss-to-pmtu

szoval semmi valtozas....

Idezem a kernel doksit: (en azert allitottama filterbe, de talaltam a neten olyat, aki a mangleba tette)

CONFIG_NETFILTER_XT_TARGET_TCPMSS: ł
ł ł
ł This option adds a `TCPMSS' target, which allows you to alter the ł
ł MSS value of TCP SYN packets, to control the maximum size for that ł
ł connection (usually limiting it to your outgoing interface's MTU ł
ł minus 40). ł
ł ł
ł This is used to overcome criminally braindead ISPs or servers which ł
ł block ICMP Fragmentation Needed packets. The symptoms of this ł
ł problem are that everything works fine from your Linux ł
ł firewall/router, but machines behind it can never exchange large ł
ł packets: ł
ł 1) Web browsers connect, then hang with no data received. ł
ł 2) Small mail works fine, but large emails hang. ł
ł 3) ssh works fine, but scp hangs after initial handshaking. ł
ł ł
ł Workaround: activate this option and add a rule to your firewall ł
ł configuration like: ł
ł ł
ł iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN \ ł
ł -j TCPMSS --clamp-mss-to-pmtu

Igaz, nem -i hanem -s.... :)
Szerintem így, emellett a script mellett indits a szerveren egy tcpdump-ot. (lehetőleg úgy, hogy fájlba mentsen, és akkor egy wiresharkkal megnyitható, könnyebben átlátható.
Azt még mindig nem tudom, mi ez a FILTER... :) (pontosabban minek?)
--
Discover It - Have a lot of fun!

Az a Filter annyit csinal, amit bekopiztama kernelbol foljebb...darabolja a csomagokat...elmeletileg a pmtu altal felderitett ertekre, de hogy mukodik e vagy sem azt nem tudom, mert nem latom, hogyan kene teszteleni, de ha a leirasbol jol olvastam ki akkor kene latnom, hogy a tuzfalam kuldozget kamu csmagokat az adott cim fele, novekvo merettel es 1-el visszalep, ha fragmentation needed uzenetet kap... mintha en ezt olvastam volna ki...es akkor az adott utvonalra az lesz az MTU, de en ezt nem lattam ;) nem latok forgalmat, ami erre utalna ;) szoval benne van, de szerintem nem mukodik...

Meg egy extra info!

Telepitettem egy squid3-at, default konfiggal...ugyan ezt csinlja... ;) pedig az a tuzfalon fut...ugyan ugy TIMEOUT-olnak a kepek es a fajlok...mondjuk ezt explorerbol teszteltem..be RDP-ztem egy gepre es belottem a proxy-t...Totalisan nem ertem, hogy mi van....

Mar csak bridge kiirtasa van hatra....

szivesen fogadom az otleteket.

( fireking | 2008. 07. 27., v – 13:06 )

Meg ez is van: (TESZT LINUXROL pingelve)

1.) Ez pont belefer az 1 egysegbe (1492)
ping -c 5 -s 1464 google.com
PING google.com (64.233.187.99) 1464(1492) bytes of data.
64 bytes from jc-in-f99.google.com (64.233.187.99): icmp_seq=1 ttl=231 (truncated)
64 bytes from jc-in-f99.google.com (64.233.187.99): icmp_seq=2 ttl=231 (truncated)
64 bytes from jc-in-f99.google.com (64.233.187.99): icmp_seq=3 ttl=231 (truncated)
64 bytes from jc-in-f99.google.com (64.233.187.99): icmp_seq=4 ttl=231 (truncated)
64 bytes from jc-in-f99.google.com (64.233.187.99): icmp_seq=5 ttl=231 (truncated)

--- google.com ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4010ms
rtt min/avg/max/mdev = 134.527/135.681/136.788/0.858 ms

2.) Itt mar fragmentalni kene
ping -c 5 -s 1470 google.com
PING google.com (72.14.207.99) 1470(1498) bytes of data.
From 172.20.0.1 icmp_seq=1 Frag needed and DF set (mtu = 1492)
64 bytes from eh-in-f99.google.com (72.14.207.99): icmp_seq=2 ttl=233 (truncated)
64 bytes from eh-in-f99.google.com (72.14.207.99): icmp_seq=3 ttl=233 (truncated)
64 bytes from eh-in-f99.google.com (72.14.207.99): icmp_seq=4 ttl=233 (truncated)
64 bytes from eh-in-f99.google.com (72.14.207.99): icmp_seq=5 ttl=233 (truncated)

--- google.com ping statistics ---
5 packets transmitted, 4 received, +1 errors, 20% packet loss, time 4011ms
rtt min/avg/max/mdev = 129.964/131.100/132.352/1.137 ms

3.)
1480-as packet merettel el sem indul a ping...

ping -c 5 -s 1480 google.com
PING google.com (64.233.187.99) 1480(1508) bytes of data.

--- google.com ping statistics ---
5 packets transmitted, 0 received, 100% packet loss, time 4000ms

Haladok elore a temaban, van nekem gepem a gerencihalon is.

megpingeltem:

-s 10296 -al hiba nelkul megy
-s 10304 -el el sem jut az echo request a gepemhez...pedig a tuzfal kulso interface-n dumpolok es latom, hogy elhagyja az interface-t a 6 db packet. Szerintetek mit kene tenni?

Udv,
I.

( Kiskübi v | 2008. 07. 27., v – 14:32 )

Nálam is bridge van LAN felé. A csomagméretet szerintem is mangle-ben lenne jó levágni, ezzel tégy egy próbát szerintem. Nálam spec. így van (pppoeconf rakta be): 

iptables -t mangle -o "$PPP_IFACE" --insert FORWARD 1 -p tcp --tcp-flags SYN,RST SYN -m tcpmss --mss
 1400:1536 -j TCPMSS --clamp-mss-to-pmtu

Ezzel megy.

( fireking | 2008. 07. 27., v – 16:05 )

Na radumpoltam a kerdeses URL-re

Belulrol indittam a kapcsolatot.
flags DF az nem azt jelenti, hogy DontFragment? es ezt pedig nagyon is kene, hogy fragmentaljuk...mert nem igazan fer bele egy packetba.

hol kellene beallitani, hogy a DF bit az ne legyen beallitva ha a belso kapcsolatrol jon valami es nagyobb mint a PMTU altal felderitett MTU ha ez egyatalan mukodik? vagy egyatalan ezt lehet allitani?

ja igen a TOS az be van allitva, azt tudom allitani mangleban...

16:01:14.786539 IP (tos 0x10, ttl 63, id 62307, offset 0, flags [DF], proto TCP (6), length 60) fw.tld.33778 > mail.inode.gugler.at.www: S, cksum 0x5150 (correct), 3529160368:3529160368(0) win 5840
16:01:14.840310 IP (tos 0x0, ttl 52, id 0, offset 0, flags [DF], proto TCP (6), length 60) mail.inode.gugler.at.www > fw.tld.33778: S, cksum 0x5dbc (correct), 1304925734:1304925734(0) ack 3529160369 win 5792
16:01:14.840435 IP (tos 0x10, ttl 63, id 62308, offset 0, flags [DF], proto TCP (6), length 52) fw.tld.33778 > mail.inode.gugler.at.www: ., cksum 0xa2bd (correct), ack 1 win 46
16:01:14.840508 IP (tos 0x10, ttl 63, id 62309, offset 0, flags [DF], proto TCP (6), length 197) fw.tld.33778 > mail.inode.gugler.at.www: P 1:146(145) ack 1 win 46
16:01:14.895093 IP (tos 0x0, ttl 52, id 39960, offset 0, flags [DF], proto TCP (6), length 52) mail.inode.gugler.at.www > fw.tld.33778: ., cksum 0xa21e (correct), ack 146 win 54
16:01:14.903617 IP (tos 0x0, ttl 52, id 39961, offset 0, flags [DF], proto TCP (6), length 1452) mail.inode.gugler.at.www > fw.tld.33778: . 1:1401(1400) ack 146 win 54
16:01:14.903955 IP (tos 0x0, ttl 52, id 39962, offset 0, flags [DF], proto TCP (6), length 1452) mail.inode.gugler.at.www > fw.tld.33778: . 1401:2801(1400) ack 146 win 54
16:01:14.904313 IP (tos 0x10, ttl 63, id 62310, offset 0, flags [DF], proto TCP (6), length 64) fw.tld.33778 > mail.inode.gugler.at.www: ., cksum 0x93b9 (correct), ack 1 win 46
16:01:14.959673 IP (tos 0x0, ttl 52, id 39963, offset 0, flags [DF], proto TCP (6), length 1452) mail.inode.gugler.at.www > fw.tld.33778: . 2801:4201(1400) ack 146 win 54
16:01:14.960033 IP (tos 0x10, ttl 63, id 62311, offset 0, flags [DF], proto TCP (6), length 64) fw.tld.33778 > mail.inode.gugler.at.www: ., cksum 0x8e33 (correct), ack 1 win 46
16:01:15.015021 IP (tos 0x0, ttl 52, id 39964, offset 0, flags [DF], proto TCP (6), length 1452) mail.inode.gugler.at.www > fw.tld.33778: . 4201:5601(1400) ack 146 win 54
16:01:15.156589 IP (tos 0x0, ttl 52, id 39965, offset 0, flags [DF], proto TCP (6), length 1452) mail.inode.gugler.at.www > fw.tld.33778: . 1:1401(1400) ack 146 win 54
16:01:15.674899 IP (tos 0x0, ttl 52, id 39966, offset 0, flags [DF], proto TCP (6), length 1452) mail.inode.gugler.at.www > fw.tld.33778: . 1:1401(1400) ack 146 win 54
16:01:15.675262 IP (tos 0x10, ttl 63, id 62312, offset 0, flags [DF], proto TCP (6), length 52) fw.tld.33778 > mail.inode.gugler.at.www: ., cksum 0x9088 (correct), ack 4201 win 69
16:01:15.730957 IP (tos 0x0, ttl 52, id 39967, offset 0, flags [DF], proto TCP (6), length 1452) mail.inode.gugler.at.www > fw.tld.33778: . 4201:5601(1400) ack 146 win 54
16:01:15.731332 IP (tos 0x0, ttl 52, id 39968, offset 0, flags [DF], proto TCP (6), length 1452) mail.inode.gugler.at.www > fw.tld.33778: . 5601:7001(1400) ack 146 win 54
16:01:15.731693 IP (tos 0x10, ttl 63, id 62313, offset 0, flags [DF], proto TCP (6), length 64) fw.tld.33778 > mail.inode.gugler.at.www: ., cksum 0x614d (correct), ack 4201 win 69
16:01:15.786652 IP (tos 0x0, ttl 52, id 39969, offset 0, flags [DF], proto TCP (6), length 1452) mail.inode.gugler.at.www > fw.tld.33778: P 7001:8401(1400) ack 146 win 54
16:01:15.787016 IP (tos 0x10, ttl 63, id 62314, offset 0, flags [DF], proto TCP (6), length 64) fw.tld.33778 > mail.inode.gugler.at.www: ., cksum 0x5bc7 (correct), ack 4201 win 69
16:01:15.842121 IP (tos 0x0, ttl 52, id 39970, offset 0, flags [DF], proto TCP (6), length 1452) mail.inode.gugler.at.www > fw.tld.33778: . 8401:9801(1400) ack 146 win 54
16:01:15.842478 IP (tos 0x10, ttl 63, id 62315, offset 0, flags [DF], proto TCP (6), length 64) fw.tld.33778 > mail.inode.gugler.at.www: ., cksum 0x5641 (correct), ack 4201 win 69
16:01:15.897453 IP (tos 0x0, ttl 52, id 39971, offset 0, flags [DF], proto TCP (6), length 1452) mail.inode.gugler.at.www > fw.tld.33778: . 9801:11201(1400) ack 146 win 54
16:01:15.897812 IP (tos 0x10, ttl 63, id 62316, offset 0, flags [DF], proto TCP (6), length 64) fw.tld.33778 > mail.inode.gugler.at.www: ., cksum 0x50bb (correct), ack 4201 win 69
16:01:15.952888 IP (tos 0x0, ttl 52, id 39972, offset 0, flags [DF], proto TCP (6), length 1452) mail.inode.gugler.at.www > fw.tld.33778: . 11201:12601(1400) ack 146 win 54
16:01:15.953252 IP (tos 0x10, ttl 63, id 62317, offset 0, flags [DF], proto TCP (6), length 64) fw.tld.33778 > mail.inode.gugler.at.www: ., cksum 0x4b36 (correct), ack 4201 win 69
16:01:15.976231 IP (tos 0x0, ttl 52, id 39973, offset 0, flags [DF], proto TCP (6), length 1452) mail.inode.gugler.at.www > fw.tld.33778: . 4201:5601(1400) ack 146 win 54
16:01:16.477322 IP (tos 0x0, ttl 52, id 39974, offset 0, flags [DF], proto TCP (6), length 1452) mail.inode.gugler.at.www > fw.tld.33778: . 4201:5601(1400) ack 146 win 54
16:01:17.476149 IP (tos 0x0, ttl 52, id 39975, offset 0, flags [DF], proto TCP (6), length 1452) mail.inode.gugler.at.www > fw.tld.33778: . 4201:5601(1400) ack 146 win 54
16:01:19.476024 IP (tos 0x0, ttl 52, id 39976, offset 0, flags [DF], proto TCP (6), length 1452) mail.inode.gugler.at.www > fw.tld.33778: . 4201:5601(1400) ack 146 win 54
16:01:19.578986 IP (tos 0x0, ttl 52, id 60135, offset 0, flags [DF], proto TCP (6), length 1452) mail.inode.gugler.at.www > fw.tld.33776: . 1238051397:1238052797(1400) ack 3464995887 win 54
16:01:23.477262 IP (tos 0x0, ttl 52, id 39977, offset 0, flags [DF], proto TCP (6), length 1452) mail.inode.gugler.at.www > fw.tld.33778: . 4201:5601(1400) ack 146 win 54
16:01:31.479706 IP (tos 0x0, ttl 52, id 39978, offset 0, flags [DF], proto TCP (6), length 1452) mail.inode.gugler.at.www > fw.tld.33778: . 4201:5601(1400) ack 146 win 54
16:01:35.609161 IP (tos 0x0, ttl 52, id 63770, offset 0, flags [DF], proto TCP (6), length 52) mail.inode.gugler.at.www > fw.tld.42252: F, cksum 0x1746 (correct), 996844999:996844999(0) ack 3233299437 win 54
16:01:44.613139 IP (tos 0x0, ttl 52, id 27064, offset 0, flags [DF], proto TCP (6), length 1452) mail.inode.gugler.at.www > fw.tld.33777: . 1267836331:1267837731(1400) ack 3494235066 win 54
16:01:47.485421 IP (tos 0x0, ttl 52, id 39979, offset 0, flags [DF], proto TCP (6), length 1452) mail.inode.gugler.at.www > fw.tld.33778: . 4201:5601(1400) ack 146 win 54
16:01:50.083526 IP (tos 0x0, ttl 52, id 18103, offset 0, flags [DF], proto TCP (6), length 52) m

( fireking | 2008. 07. 28., h – 23:52 )

MEGOLDVA

Kezdjen mindenki rohogni!

Hibas halokartya... :( kicsereltem a LANoldali kartyat es lassal csodat minden jo!

:( megyek telesirom a parnamat...