Lassú weboldalak

 ( Ligend | 2006. május 5., péntek - 17:24 )

Van egy probléma, amivel napok ota szenvedek, de semmi eredménye, hacsak nem vesszük annak, hogy a hajam már ritkul. ;-)

Adott a céges tűzfal, rajta debian woody és zorp. Az internet kapcsolatot egy 2048/192kbit/sec-es ADSL biztosítja, ezen megy egy VPN is egy másik iroda tűzfalára. A VPN sebessége az elvárható szinten van, a megszokott teljesítményt hozza, azonban bizonyos weboldalak szörnyen lassan töltődnek le (max. 1-2kB, de inkább csak párszáz byte/sec). Ilyenek például:
- freemail.hu
- www.cib.hu
- www.gmail.com

Sok oldallal semmi baj nincs, egy ADSL-hez illő sebességgel jelennek meg, de egyre több olyat találok, amelyre sokat kell várni, már ha egyáltalán bejön. Ezen oldalak azonban máshol (pl. a másik irodában) nem lassúak.
Leállítottam a zorp-ot, az iptables-ben minden policy-t ACCEPT-re tettem, a láncokat kiürítettem, down-ra tettem a belső hálózat interfészét, leállítottam az OpenVPN server-t. Gyakorlatilag egy csupasz woody maradt egy szem ppp kapcsolattal, azonban a helyzet nem változott. Reboot, kernel csere, DSL modem reset volt, eredménytelenül.
Kézközelben volt egy XP-s laptop, amire gyorsan belőttünk egy PPPoE kapcsolatot, és láss csodát, az eddig rendetlenkedő oldalak is jönnek, ahogy kell. A probléma tehát a linux-os tűzfalon van, kérdés hogy hol, és mi alapján válogat?

Kínomban visszaállítottam mindent a kiinduló helyzetbe, és egy kiszemelt weboldal címét megadtam a routing táblában, és átzavartam a VPN-en a másik iroda tűzfalára. Nagyságrendeket javult a letöltési sebesség, persze így nem maradhat.

Eddig jutottam, és kifogytam az ötletekből. Örömmel vennék tanácsokat, javaslatokat, hogy mit kellene megnéznem, illetve mi okozhat ilyen jellegű problémát.

Előre is köszönöm a konstruktív hozzászólásokat.

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ő.

Én is találkoztam ezzel a jelenséggel, amikor a céges tűzfalunkat telepítettem (szintén linux). Úgy figyeltem meg, hogy jellemzően csak a dinamikus weboldalaknál van ilyen viselkedés, viszont azoknál sem mindegyiknél. Valószínűleg valamilyen kiszolgáló szerver oldali szoftver + alkalmazott techológia együttes érzékeny a linux netfilter által végrehajtott címfordításra.
Nálunk végül az lett a megoldás, hogy egy squid proxy is telepítve lett a rendszerbe (a tűzfalra, mert az a közvetlen kijárat), és a kliensek azon keresztül szörfölnek. A problémát ezzel sikerült megszüntetni.

Zavard össze a világot: mosolyogj hétfőn.

Ez sajnos a jelen problémánál nem jelentene megoldást. Maga a tűzfal hozza le lassan az oldalakat, azon egy rá telepített proxy sem segítene. A láncok az iptables-ben teljesen ki lettek ürítve, policy-k ACCEPT-en...

"Ez sajnos a jelen problémánál nem jelentene megoldást. Maga a tűzfal hozza le lassan az oldalakat, azon egy rá telepített proxy sem segítene."

Ha van NAT, akkor te azon keresztül böngészel, a proxy meg nem.

Úgyhogy ha a probléma a NAT-al lenne összefüggésben, akkor egy proxy igenis megoldást jelenthetne.

---
If you have money, use Windows!
However, if you also have a brain, use Linux!

Ezt akkor most valamelyikünk nem érti. A tűzfalon van a ppp kapcsolat, ez az eszköz NAT-ol, szűr, stb. A mögötte lévő gépek egyértelműen NAT-tal mennek kifelé, de maga a tűzfal nem. Ha a tűzfal kezdeményez kifelé http/https kapcsolatot, amivel most zűr van, akkor saját magát nem NAT-olja, pláne, ha előtte ki is szedtem a netfilter szabályokat.

MTU mekkora?
és ha kisebbre veszed?

1452 volt alapesetben, most megpróbáltam levenni 1412-re. Lényegében a helyzet nem változott, egy picit talán gyorsabban jönnek az érintett lapok, de nem nagyságrendi a differencia.

klienseken is lejjebb vetted az mtu-t?

nekem anno otthoni tűzfal+adsl-el volt gyak. ugyanez a helyzet, és az oldotta meg, hogy ha a kliens gépeken is lejjebb vettem az mtu-t

A kliensekhez nem nyúltam, mivel egy idő (leszedtem mindent, ami "zavarhat") után nem voltak kliensek, sem belső hálózati interfész. Volt egy eth2 (eth0 és eth1 down) cím nélkül, arra ment fel a ppp0. Pont. Így is lassú volt.

Lehet, hogy hulyeseget irok, javitsatok ki ha tevedek. Nem lehet, hogy a DNS okozza a problemat? Ugyanis dinamikus weboldal minden elemere teljes nevfeloldast akar csinalni, igy a sok keres miatt lelassul az ossz letoltes, kellene egy DNS cache. Ilyen problemam volt egy lokalis haloban, a webmin iszonyatosan lassan toltodott be, a DNS beallitasa utan mint a villam mukodott.

Udv Zoli

Ha lenne szavazás - a leírtak és a tapasztalataim alapján - én is a dns problémára gyanakodnék!

A tűzfalon fut egy működő bind 8.3, a lekérések sebességével nem tapasztalok problémát. A lassúság ellenben előfordul teljesen statikus oldalaknál is, pl. egy bizonyos szerver public_html-jébe kitett adatállomány letöltése is csiga.

A tűzfalról rendesen jön a web? (pl. links van a Debian-ban, ha más nem, akkor ideiglenesen fölteszed, azzal meg tudod nézni).

Ha rendesen jön, akkor 99%, hogy NAT-probléma van. Ebben az esetben én is az MTU-ra gyanakodnék.

Hasonlítsd össze a tűzfalszabályokat a másik irodáéval (ha teheted).

Egyébként az MTU-problémára nálam ez jelentett megoldást:

iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1400:1536 -j TCPMSS --clamp-mss-to-pmtu

"A tűzfalról rendesen jön a web? (pl. links van a Debian-ban, ha más nem, akkor ideiglenesen fölteszed, azzal meg tudod nézni)."
Nem, a tűzfalon is lassúak az oldalak. Mindent kikapcsoltam, ahogy írtam még a belső hálózat interfészét is lenyomtam, netfilter mindent engedett, úgyhogy nem gyanakszom NAT problémára.

Ellenben az MTU már egy jó ötlet...

A pppd config, illetve a ppp0 interfész:
--------------------------------------------
pty "/usr/sbin/pppoe -I eth2 -T 80 -m 1452"
noipdefault
defaultroute
hide-password
lcp-echo-interval 60
lcp-echo-failure 3
connect /bin/true
noauth
persist
mtu 1452
user "usernev@szolgaltato"
--------------------------------------------
ppp0 Link encap:Point-to-Point Protocol
inet addr:xxx.xxx.xxx.xxx P-t-P:xxx.xxx.xxx.xxx Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1452 Metric:1
RX packets:1980 errors:0 dropped:0 overruns:0 frame:0
TX packets:2136 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:3
RX bytes:270529 (264.1 KiB) TX bytes:593952 (580.0 KiB)
--------------------------------------------

A jelenség akkor is tapasztalható, ha a tűzfal gyakorlatilag egyedül van az ADSL-en, tehát nem kell NAT-olnia sem FORWARD-olnia. Szerintem ekkor hiába teszek be bármit is a FORWARD-ba, nem fog segíteni, de azért kipróbálom.

Rendben, a tuti kizárhatóság kedvvéért nézd meg.

Ha pedig átlépünk a DNS kérdésére:

IP-cím alapján jobban jönnek az oldalak? (Ámbár valószínű a sok HTML-hivatkozás fogja meg, azok pedig lehet, hogy úgyis névre szólnak... de hátha relatívak).

tcpdump nem mutat őrült DNS-forgalmat?

...vagy egyéb gyanús dolgot?

IP cím alapján is ugyanolyan lassú (volt). Mellesleg a névfeloldási probléma ellen szólt az is, hogy ha csak a routing-ot állítottam át (nem a default route-ta ment a lassú oldal felé a kérés, hanem a másik iroda tűzfalára VPN-en keresztül), akkor gyorsabb lett.

Vegülis egy workaround lett eszközölve a problémára (sürgős volt megoldani), így kifogástalanul megy.

Elétettünk egy DSL router-t, a szükséges portokat beforward-olja, így érdekes módon minden remek. Csak találgatni tudok, hogy a woody pppoe kliense lehet valamilyen modon inkompatibilis a szolgaltatoval. Egy nyugodtabb időszakban majd teszek egy próbát, és frissítem az egész rendszert.

Szeretném megköszönni az ötleteket, javaslatokat. Mint írtam, a probléma megoldódott, bár a hiba konkrét okát sajnos nem sikerült felderítenem.