Tegnap óta döcög a net probléma

Sziasztok!

Van egy T-online-os 120 Mb/s-os optikai internet. A modem be van kötve egy ubuntu szerverbe, ezen van egy iptables tűzfal, és ez végzi az internetre a csatlakozást. A tűzfalból két alhálózat indul ki. A hálózatban van egy Windows szerver 2008R2. Ezen van a DNS szerver, ami jelenleg a DNS kéréseket elsődlegesen a google névszervereire, majd a T-Online névszervereire továbbítja.

Tegnapi napont kezdődött, hogy elkezdett döcögni a net. Sokszor nem tölti be az oldalakat, vagy DNS hibát ír, vagy túl hosszú ideig nem válaszolt. Van mikor ráfrissítek és 2-3-szorra beadja, DNS hibánál van, hogy megjeleníti a hibát, majd pár másodperc múlva betölti az oldalt.

A rendszerben és a konfigurációban semmi változás nem történt a hiba megjelenése előtt.

Újratöltöttem az iptables konfigurációt, újracsatlakoztam a netre. Újra indítottam a szervereket, switcheket, modemet. A nem olyan fontos szabályokat töröltem az iptables scriptből (portnyitások, kívülről beengedett portok). Valamelyest javult talán az internetelérés, de még mindíg van, hogy nem tölti be egyből az oldalakat.

Felhívtam a T-Online-t is, mivel olvastam, hogy gond van nálluk a hákózattal, de az ügyfélszolgálatos azt mondta, hogy nem nállunk (Kiskunfélegyháza). Azért központból leelenőrizték, és jött az SMS, hogy nincs gond a vonallal. Ha a modemet közvetlen egy laptopra ktöm és azzal csatlakozok, nem tapasztaltam a hibát.

Szóval a tűzfallal van valami probléma, de nem tudom, hogy mi lehet az. Mindent kipróbáltam ami eszembe jutott, de nem oldotta meg teljesen a problémát. A syslogban nem látok semmi olyat ami hibára utalna.

Mit lehetne még megnézni? Mik okozhatnak ilyen hibát?

Hozzászólások

En inkabb dns hibara tippelnek, hogy az elsokent megadott dns szerver nem ad vagy lassan valaszt es ido mire a masodikkal probalkozik a kliens.
Azt probald meg elso korben tesztelni, hogy rendben van-e.

"Van egy T-online-os 120 Mb/s-os optikai internet."
Ezen, gondolom, nem optikai bérelt vonalat, hanem GPON-t kell érteni PPPoE-val.

"A modem be van kötve egy ubuntu szerverbe"
A PPPoE-t az Ubuntu indítja, és nem a home gateway?

"de még mindíg van, hogy nem tölti be egyből az oldalakat"
MTU/MSS?

"Szóval a tűzfallal van valami probléma, de nem tudom, hogy mi lehet az."
A LAN felé engedve van az ICMP Unreachable? A tűzfalban van TCP MSS igazítás? Ha igen, akkor jó az MSS értéke?

"ami jelenleg a DNS kéréseket elsődlegesen a google névszervereire, majd a T-Online névszervereire továbbítja."
Ha mégsem PMTUD hiba, akkor próbáltad már más DNS szerverrel? Itt nem böngészőt, hanem nslookup/host/dig stb. eszközökkel végzett tesztre gondolok.

Igen ez egy PPPoE kapcsolat.

Igen a PPPoE kapcsolatot az ubuntu szerver indítja.

MTU/MSS-re most nem tudok mit mondani. Majd megnézem, de nem hiszem hogy azzal lenne gond.

Az ICMP engedélyezve van a tűzfalon. MSS igazítás nincs.


$IPT -A FORWARD -p icmp --icmp-type echo-request -j ACCEPT

nslookup-al lekértem pár oldal ip-ét és nem volt gond.

Windows alól is megnéztem, először lekéri, hogy a helyi tartományból való-e a cím. Majd továbbítja a t-online dns szerveréhez, és meg is kapja az ip-t.

Amúgy a rendszer 2 évig gond nélkül működött.

"Az ICMP engedélyezve van a tűzfalon. $IPT -A FORWARD -p icmp --icmp-type echo-request -j ACCEPT"
A kérdés így szólt: "A LAN felé engedve van az ICMP Unreachable?"
Nem a pingelésre kérdeztem rá. A válasz a fenti sorból az, hogy nincs. De miért nincs? Miért nincs átengedve az ICMP Type 3?

"MSS igazítás nincs."
Az ICMP Unreachable tiltása, és ezzel egyidőben a TCP MSS magára hagyása csökkentett PMTU mellett azt jelenti, hogy nem működhet a PMTUD, és a kerülőmegoldás sincs aktiválva.

Engedd át az ICMP Unreachabe-t, és tegyél bele MSS állítást is (lásd: man iptables-extensions, TCPMSS, --set-mss, --clamp-mss-to-pmtu).

"nslookup-al lekértem pár oldal ip-ét és nem volt gond."
"Windows alól is megnéztem, először lekéri, hogy a helyi tartományból való-e a cím. Majd továbbítja a t-online dns szerveréhez, és meg is kapja az ip-t.
Helyes. Tehát nem DNS gond van. A DNS alapesetben UDP-n megy, és a legtöbb esetben a PMTU-nál kisebb a válaszcsomag mérete.

Egyelőre az a javaslat, hogy engedd működni a TCP-t, PMTUD-vel és/vagy MSS igazítással.

Dual-stack ?

Lassan, de biztosan terjed azért az ipv6...szval pillants rá arra, hogy ha kapsz egy /64-et, akkor ott minden rendben van-e -routing, ect - illetve a vannek-e v6 resolverjeid, és persze ipv6-on elérhetőek-e.

Jelenleg próbaképpen mindent beengedek a szerverre, és ki is engedek mindent. Kifelé eddig se voltak korlátozva a csomagok, csak az invalid icmp-k voltak eldobva.

A FORWARD láncba maradtak csak szabályok, mert azok kellenek internettiltás és átirányítások miatt.

MSS állítás még nincs konfigurálva.

Aránylag jól megy a net, mostmár nincs időtullépéses hiba. Viszont most DNS probléma van. Van amelyik oldalakat gyorsan megnyitja, gondolom ezeket a windows szerver cash-ből küldi. Viszont Ha kliens gépen Windows 10 nslookup-al rákérdezek olyan webcímekre, amik a gépemen nem voltak megnyitva, van amit egyből fordít IP-re, van aminél "DNS request timed out. timeout was 2 seconds hibaüzenetet dob. Ezután van hogy sikerül neki átfordítania a címet, van hogy nem.

Jelenleg itt tartok. Nem tudom, hogy ezt is okozhatja-e a tűzfal, vagy a Windows DNS szerverrel is lehet valami gond?

"Ha kliens gépen Windows 10 nslookup-al"
"vagy a Windows DNS szerverrel is lehet valami gond?"
A kliensről a DNS tesztet ugye nem (csak) a helyi Windows DNS szerverre nézted meg, hanem a Google, Telekom stb. névszerverekhez is? (nslookup, server 84.2.44.1; illetve server 84.2.46.1).
Ha a közvetlen DNS kérések jók, de a Windows DNS szerverét kérdezve nem, akkor esetleg lehet gyanús a Windows DNS szerver.

Továbbá nézd meg a gyebi által javasolt IPv6 beállítást is.

Ha a kliens gépen nslookup-al lekérek egy címet, akkor legelőször a windows szerverhez fordul, és az továbbítja egy külső DNS szerverhez.

Kipróbáltam, hogy a kliensgépnek beállítottam a google névszerverét, hogy közvetlen onnan kérje le a címet kihagyva a helyi Windows DNS szervert, ugyan úgy voltak timeout hibák. Sőtt már az nslookup elindításánál is egyből írt egy timeout-ot.

Most egyenlőre átállítottam a rendszert úgy, hogy a modem végezze a csatlakozást az internet felé.

IPTables-ben jelenleg befelé és kifelé mindent engedek.

Most itthonról TeamViewer-el tesztelem a benti gépemen a netet, és nem tapasztalok hibát, minden oldalt gyorsan betölt, egyszer sem írt még DNS hibát. Nslookup is azonnal dobja az ip-ket hiba nélkül. Azonban lehet hogy ha nagyobb terhelést kap akkor lesz probléma, de ez majd csak hétfőn fog kiderülni.

Nos miután hétvégén átállítottam a rendszert, hogy a modem végezze a kapcsolódást, hétvégén egyszer sem dobott DNS hibát se a böngésző, se az nslookup.

Ma megkezdődött a következő iskolai hét, terhelést kapott a rendszer, mindenki netezik, és az nslookup újra timeout hibát dob mielőtt le tudná kérni az ip-címet.

Lehet a switch a szűk keresztmetszet? Egy régi Cisco switchen megy keresztül az egész forgalom.

"mindenki netezik, és az nslookup újra timeout hibát dob mielőtt le tudná kérni az ip-címet"
A probléma jelentkezésekor mekkora az uplink terheltsége mind feltöltés, mind letöltés irányban? Legalább feltöltésirányban van valamilyen QoS beállítva?
Milyen GPON díjcsomag? Ha jól látom, van olyan csomagja a Telekomnak (ConnectNet F120), ahol a kínált sebesség 120/50 Mbps, a garantált pedig 50/25. Ha ez van nálatok, akkor ezekhez az értékekhez viszonyítva milyen a terheltség?

"Lehet a switch a szűk keresztmetszet? Egy régi Cisco switchen megy keresztül az egész forgalom."
Látsz-e a switchportokon magas input queue drops illetve total output drops értékeket, illetve úgy általában input és output errort?
Az Ubuntu és a HGW között is ez a switch van, vagy az említett két eszköz közvetlenül kapcsolódik egymásra?

"átállítottam a rendszert úgy, hogy a modem végezze a csatlakozást az internet felé."
A NAT-ot is a home gateway végzi, vagy a NAT maradt az Ubuntun? Eddig ugye az Ubuntu ppp0-ján a forráscímtől függetlenül volt MASQUERADE, ez maradt így, csak eth1(?)-re állítva?

Az IPv6 vonalra nem érkezett válasz, azt kizártuk?

Megnéztem a terhelést bmon-al, de a terheltségel nincs gond, eddig se volt, és nem használják többen a hálózatot. Az eth1 hálózati kártya terheltsége, melyen a modemmel van összekötve az alábbi képen látható:
https://goo.gl/photos/s3gJ9wd6Gxwt34baA
QoS nincs beállítva, de 4-5 éve megy a rendszer és nem volt rá szükség, mióta optikai netünk van.

Azok a switchek amiken keresztül megy minden forgalom, Cisco switchek, webes kezelőfelületük nincs. Nem vagyok túl jártas a Cisco eszközökben, anno én állítottam be őket, utána olvasgatással, de kicseréltem egy másik újabb Cisco switchre, és az sem oldotta meg a problémát. A modem és a tűzfal között nincs switch, közvetlenül kapcsolódnak egymásra. A switchek a tűzfal után vannak.

Jelenleg a NAT-olást az Ubuntu végzi. Az Ubuntun jelenleg a következő tűzfal script fut le:

#eth0 172.16.255.254 (Diák alháló)
#eth1 192.168.1.101 (Internet, Modemtől kap DHCP-n címet)
#eth2 172.17.255.254 (Tanári alháló)

IPSET create tiltas bitmap:ip range 172.16.0.0-172.16.255.255

IPTABLES -P INPUT ACCEPT
IPTABLES -A FORWARD -i eth0 -m set --match-set tiltas src -j DROP
IPTABLES -P OUTPUT ACCEPT
IPTABLES -t nat -A POSTROUTING -o eth1 -j MASQUERADE

IPv6 igazándiból ezzel kevésbé foglalkoztam. Lefuttatam otthon T-Home ADSL-neten egy IP6 tesztet, és itt a suliba az optikai neten is. Mind a kettő ugyan azt az eredményt hozta, hogy nem lesz probléma IPv6-os oldalak megjelenítésében, a DNS kiszolgáló rendelkezik IPv6 kapcsolattal, azonban a kizárólag IPv6-on elérhető oldalak nem fognak menni. Otthon semmi gond nincs a nettel, itt a suliban meg van.

Volt kint a T-online szerelő. Kicserélte a modem adapterét 1A-ről 2A-re, mert ez azt mondta okozhat problémát, már több helyen le kellett cserélniük. Ezután csak a laptopját rákötve a modemre, és a laptoppal PPPoE kapcsolaton keresztül futtatott pár sebességtesztet, amivel nem volt gond, és azt mondta, ő csak ennyit tud tenni.

Na most sebesség tesznél ha rá van kötve az egész iskolai hálózat, és működik a speedtest.net oldal, akkor nincs semmi gond. A feltöltési sebességet nem mindig tudja lemérni, mert gondolom a net miatt megszakad a kapcsolata a szerverrel. Jelenlegi mérés alapján Budapeti T szerverre: Ping 9ms Feltöltés: 79.77 Mbps (használja más is a netet, jelenleg ezért nem 100 fölötti az érték) Letöltés: (43.68 Mbps)

Sajnos a modemet nem cserélték ki, nem is hozott magával a szerelő. Pedig kíváncsi lettem volna egy másik modemmel a teljes hálózatot ráengedve továbbra is fennállt volna-e a hiba. ADSL-nél már volt rá példa, hogy szakadozott az internet, de a T nem volt hajlandó új modemet adni. Vettem egyet és utána semmi gond nem volt.

Ma reggel figyeltem IPTraf-al, hogyan alakul a hálózati kártyákon a sebesség. eth1 megy a net felé. eth0 a diák háló, eth2 a tanári háló.

Az eth0 és eth1 2500 kbytes/sec-ig ment fel, egyszer a teszt után felugrott 3500 kbytes/sec-re. Az eth1 2500 kbytes/sec-ig ment, és már megjelentek a túl hosszú ideig nem válaszolt üzenetek a böngészőben.

A hálózat 100 Mb/sec-es, a net 120/50 Gb-es. Szóval nem az a gond, hogy túl nagy terhelés van a hálózati kártyán.

A hálózati kártyák MTU értékét beállítottam 1492 bytes-ra, 1500-on volt amúgy.

IPV6-al csak akkor lehet gond, ha olyan oldalt nyitnék meg, ami csak azt támogatja.

QoS nincs beállítva, utána néztem, de egyenlőre még nem igazán értem hogy kell beállítani, de a jelenlegi rendszer 3-4 éve megy nélküle hiba nélkül.

Nem tudom mi lehet a probléma.

"IPV6-al csak akkor lehet gond, ha olyan oldalt nyitnék meg, ami csak azt támogatja."
Hááát, van mikor akár DNS akár böngésző hibája miatt az IPv6-ot eröltetné IPv4-es hálózaton és azért nem müxik egy oldal (van IPv4 és v6 elérhetősége is).
Pl mikor IPFire proxy a mikrotik DNS gyorsítótárát használta, futottam bele ilyen hibaüzenetbe, viszont ha az IPFire közvetlenül a gugli DNS szerverét használta, nem volt gond. De mintha egyes Firefox változatoknál is lett volna ilyen gond.

modem vagy router? T-s routerekkel rengeteget szivunk sok kliensnel mi is, nem birja a cpu-ja a sok connectiont (otthoni felhasznalasra mereteztek). At kell rakatni bridge modba, akkor csak modemkent viselkedik de nem nyul bele a csomagokba, igy stabil.

maisk erdekes problema amibe tegnap futottam bele, linux tuzfal, uj ace telekomos 40/40 kapcsolat, ftp-vel neztem jo a sebesseg, de a speedtest 1.5-3mbit/s fole nem megy, es iszonyu lassan indul neki. kiderult, hogy dns problema, meg az elozo szolgaltato dns-e volt beallitva a gepen, de hogy ez a speedtestet miert befolyasolja?

Szia!

Igen T-s Huawei optikai router, modem.
http://www.telekom.hu/static-la/sw/file/digitalis_eloszto_hg8245h_haszn…

Kb 2 éve van nállunk. Én is arra gondolok, hogy az lehet a probléma forrása. T-nél háromszor jelentettem be a hibát. Elsőre az előzetes teszt során nem találtak hibát. Másodjára konfigurációs hibát találtak, melyet javítottak. Harmadjára kijött a T-s emberke, az 1A-es adaptert kicserélte 2A-re, mondván ez okozhat problémát, sok helyen le kellett cserélni. Lehúzta a hálózatunkat a modemről, rákötötte a saját laptopját, csinált pár sebességtesztet és megállapította, hogy nincs gond.

Azt mondta, hogy Ő csak ennyit tud tenni.

Esetleg tudsz ajánlani egy jó fajta optikai modemet, amit meg lehetne venni? Kerestem neten, de nem találtam.

Amúgy speedtest-el nincs gond. A sebesség megvan. Persze ha az egész iskola netezik, alacsonyabb sebességet mér, és ha akadozik a net, csak a letöltést tudja lemérni sokszor.

Meg kellene próbálni elhatárolni az eddig kipróbált eseteket.

arpi_esp azt írta fent, hogy "At kell rakatni bridge modba, akkor csak modemkent viselkedik de nem nyul bele a csomagokba, igy stabil.". Nálad ez eleve így volt, ebben az állapotban született a topic: "Igen a PPPoE kapcsolatot az ubuntu szerver indítja.". Ezután állítottad át: "miután hétvégén átállítottam a rendszert, hogy a modem végezze a kapcsolódást, hétvégén egyszer sem dobott DNS hibát se a böngésző, se az nslookup. Ma megkezdődött a következő iskolai hét, terhelést kapott a rendszer, mindenki netezik, és az nslookup újra timeout hibát dob mielőtt le tudná kérni az ip-címet."
Tehát akkor úgy sem volt jó, hogy bridge-re állítottad a hgw-t, és úgy sem, ha route-olt. Biztos, hogy a hgw jelenti a problémát?

Szerintem hardver probléma, legalábbis én erre tudok már gondolni. A konfiguráció évek óta ment probléma nélkül, módosítás nem történt.

- újra lett indítva minden
- Tűzfalon IPTABLES szabályok törölve lettek
- Hálózati kábeleket kicseréltem
- A switchet amin keresztül megy a teljes forgalom kicseréltem
- Tűzfal gépet is kicseréltem megnézni, másik géppel is előfordul-e a hiba
- Tűzfal 3 hálózati kártyájának a terhelése nem nagy. 6-7 Mb/s ha jól mér az iptraf
- Cisco switchet, melyen keresztül megy minden HP-ra cseréltem, melynek van grafikus felülete, egyik portra sem ír hibát, a terhelés egyik porton se nagy. Egy port volt amin volt 100%-os terhelés, de átlagban 60%-os.
-A Windows 2008R2-őn melyen a DNS szerver, az Active Directory, és file szerver fut nem láttam hálózati problémát, és a fájlok elérésével sincs gond a hálózaton. Hálózati terhelést sem láttam a szerveren.
-A DNS szerveren továbbítónak eredetileg a google DNS szerverei voltak beállítva, azután hozzávettem a T DNS szervereit, jelenleg csak az OpenDNS két névszervere van beállítva. Ha a hálózat egy gépnén fix DNS-t állítok be, akkor is van probléma.

Tegnap végre a T kicserélte a modemet. Egyenlőre úgy néz ki, hogy ez megoldotta a problémát.