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.
- 1404 megtekintés
Hozzászólások
É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.
- A hozzászóláshoz be kell jelentkezni
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...
- A hozzászóláshoz be kell jelentkezni
"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!
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
MTU mekkora?
és ha kisebbre veszed?
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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 hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
Ha lenne szavazás - a leírtak és a tapasztalataim alapján - én is a dns problémára gyanakodnék!
- A hozzászóláshoz be kell jelentkezni
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 hozzászóláshoz be kell jelentkezni
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 hozzászóláshoz be kell jelentkezni
"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.
- A hozzászóláshoz be kell jelentkezni
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?
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni