Kan na herinstallatie van Linux GoT niet meer bereiken

[BSeB]

Ik heb afgelopen weekend mijn server en client opnieuw geinstalleerd, nadat ik wat nieuwe hardware had toegevoegd. Installatie is eigenlijk niet nodig, maar toch wil je wel weer is wat prutsen. Opnieuw geinstalleerd en dan kom het configgen.

Normaal deed ik via adsl-config enzo de ppp verbinding configureren, aangezien ik SUSE gebruik wilde ik het nu via Yast doen. Allemaal zo gefixt, en ja hoor ik had internet weer op de server. Hierna de masq ingesteld en wat andere dingen:

# Masquerade from eth0 to ppp0
iptables --table nat -A POSTROUTING -o $EXT_DEV1 -j MASQUERADE

iptables --table filter -A FORWARD -i $EXT_DEV2 \
-o $EXT_DEV1 -s 172.20.32.108 -d ! 172.20.32.108 -j ACCEPT

Probleem is nu alleen dat ik niet op bepaalde pagina's op de client kan komen. Ik kan dus wel op www.hallo.nl maar niet op www.tweakers.net

Ik heb geen idee waar ik dit probleem moet gaan zoeken, aangezien de internet op de server gewoon goed werkt en de interne netwerk ook zonder problemen werkt. Alleen van intern via de server naar buiten dus niet.

Probleem kort, via adsl start werkt het wel en via de dsl device van yast niet. Rara hoe kan dit en hoe kan ik dit netjes oplossen. Zou het nu graag is via yast aan de praat krijgen.

Misschien een fout in mijn masq?

[CyBeR]

masq ziet er goed uit. meestal zijn deze selectieve problemen het gevolg van een foute netmask. controleer die eens.

[BSeB]

Subnetmask, moet hier in het interne netwerk 255.255.252.0 zijn

Device Name: eth-id-
Started automatically at boot
IP address: 172.20.32.108, subnet mask 255.255.252.0

Device Name: eth-id-
Started automatically at boot
IP address: 172.20.32.105, subnet mask 255.255.252.0

Device Name: eth-id-
Started automatically at boot
IP address: 172.20.32.106, subnet mask 255.255.252.0

Lijkt me dus ook niet het probleem! Zelfs een ping of tranceroute gaat niet naar de GoT site!

[TrailBlazer]

en een dns lookup naat got gaat wel goed

[BSeB]

Geen probleem lijkt me zo!

client001@Hash-001:~> host tweakers.net
tweakers.net has address 213.239.154.35
tweakers.net mail is handled by 10 mail.tweakers.net.
client001@Hash-001:~> host gathering.tweakers.net
gathering.tweakers.net has address 213.239.154.36
client001@Hash-001:~>

[Nitroglycerine]

Als je een traceroute uitvoert, waar stopt die dan?

[BSeB]

Dit is de traceroute van de client! Blijkbaar werkte idd dns lookup en traceroute gewoon, alleen de data word niet vanaf de server doorgepompt naar de client. Voor sommige pagina's echter wel zoals hallo.nl

Hash-001:/home/client001 # traceroute tweakers.net
traceroute to tweakers.net (213.239.154.35), 30 hops max, 40 byte packets
1 172.20.32.105 (172.20.32.105) 0.371 ms 0.264 ms 0.317 ms
2 145.94.1.0 (145.94.1.0) 0.518 ms 0.462 ms 0.511 ms
3 130.161.2.121 (130.161.2.121) 0.619 ms 0.589 ms 0.591 ms
4 dunet1.router.tudelft.nl (130.161.1.49) 0.573 ms 0.647 ms 0.733 ms
5 vl1-11-1-2032.XSR02.Amsterdam2A.surf.net (145.145.26.97) 2.849 ms 3.010 m s 2.943 ms
6 Pos3-15-1.XSR03.Amsterdam1A.surf.net (145.145.166.73) 2.925 ms 3.548 ms 3.311 ms
7 10ge-6-3.e600-1.ams5.true.nl (195.69.144.163) 3.317 ms 3.289 ms 2.845 m s
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *

[CyBeR]

hallo.nl staat niet bij true. kun je nog wel bij www.true.nl?

Een trace naar t.net stopt bij mij ook na die hop, dus ik ga er vanuit dat t.net daar achteraan komt met een firewall.

[ Voor 50% gewijzigd door CyBeR op 05-08-2006 15:27 ]

[BSeB]

Ja, ik kan wel op true komen, maar dus niet op tweakers! Wat ik dus wel op de server kan!

[PjotrP]

krijg je een lege pagina, of een foutmelding als je tweakers.net opvraagt?

Een foutmelding krijg je als je uberhaupt geen verbinding met poort 80 van tweakers.net kunt maken

Een lege pagina kan komen doordat je wel een http-connectie maakt, maar dat die gedropt wordt door de firewall van tweakers (bijvoorbeeld omdat je gefragmenteerde packetten stuurt).
Een ppp-verbinding die niet altijd werkt, riekt naar dit laatste (ppp-verbindingen zetten extra bytes in data-packets, waardoor de maximale packet size (MTU) kan worden overschreden).

De MTU van je interface kun je veranderen met:
# ifconfig eth0 xxxx

(vanuit een shell, als root, gebruik voor eth0 de naam je netwerkkaart, verlaag xxxx naar bijvoorbeeld 1400)

[BSeB]

Dit is de error die ik krijg, de MTU van de dsl verbinding is:
MTU:1492

Maar op de server zelf waar ik nu dus zelf op ingelogd ben om te posten heb ik nergens last van ik post hier op dit forum, op de client is de MTU:
MTU:1500

Adsl-start/stop etc heeft nooit problemen gegeven, terwijl die gewoon de ppp gebruikt, wat is hier anders aan dan?

An error occurred while loading http://www.tweakers.net:
Timeout on server
tweakers.net

[PjotrP]

Jouw server gebruikt de MTU van de ppp-verbinding, jouw client niet.
Al geprobeerd om de MTU flink te verlagen op je client?

[daft_dutch]

mischien het herstarten van de ppp
heb ik ooit een keer last van gehad. stom ding ging dingen negeren

[PjotrP]

net getest op server:
# ifconfig rl0 mtu 1400

en hoppa.. ik krijg vanaf mijn client een time-out als ik tweakers.net wil bezoeken, rest gaat prima. De firewall van tweakers accepteert geen gefragmenteerde packets

[BSeB]

PjotrP schreef op zaterdag 05 augustus 2006 @ 16:31:
net getest op server:
# ifconfig rl0 mtu 1400

en hoppa.. ik krijg vanaf mijn client een time-out als ik tweakers.net wil bezoeken, rest gaat prima. De firewall van tweakers accepteert geen gefragmenteerde packets

Betekent dit dat ik mijn MTU op de server van de ppp verbinding dus omlaag moet brengen?

[PjotrP]

nee, juist niet. Met dit voorbeeld simuleerde ik jouw situatie: de packet size van mijn client was groter dan die van mijn server.

In jouw geval mag de MTU van je client dus niet hoger zijn dan de server MTU minus de overhead van de ppp verbinding, zodat je server geen packets hoeft te fragmenteren.

Je kunt zelf testen wat je maximale client MTU mag zijn met ping -M dont -s xxxx nu.nl
(ping nu.nl, packets mogen niet fragmenteren, vul voor xxxx packet size in)
Begin met xxxx=1400. Loop dan langzaam op. Waarschijnlijk kun jij tot 1464 doorgaan. Bij het grootste getal waarmee je nu.nl nog kunt pingen mag je 28 bytes optellen: dit is jouw maximale client MTU.
(28 bytes is ping-overhead).

Als je geen zin hebt om dit te testen, neem je gewoon een MTU van 1400, zit je zowiezo goed.

[ Voor 3% gewijzigd door PjotrP op 05-08-2006 17:53 ]

[BSeB]

Ik kan vanaf mijn client met een MTU van 1500 gewoon pingen naar nu.nl.

Terwijl dus de MTU van de ppp connectie 1492 is. Standaard voor ppp connecties!

Laat ik dan nog iets anders als voorbeeld nemen. Ik heb bijvoorbeeld de site marktplaats.nl.

Deze site opent wel, maar alleen de knoppenbalk de rest laat niet, lijkt op vastlopen en uiteindeijk time-out. Pingen naar marktplaats gaat wel gewoon. Ook met mtu van 1500.

[PjotrP]

ik wil je dolgraag helpen, maar dan moet je wel een beetje meewerken.
Dat pingen van nu.nl gaat prima, TENZIJ je -M dont als parameter meegeeft en een te grote packet size probeert.

Overigens krijg ik precies hetzelfde op marktplaats als ik mijn server MTU terugschroef.

Dus als je nou gewoon even probeert je client MTU omlaag te zetten...

[BSeB]

client001@Hash-001:~> ping -M dont -s 1469 nu.nl
PING nu.nl (62.69.179.230) 1469(1497) bytes of data.
1477 bytes from 62.69.179.230: icmp_seq=1 ttl=55 time=4.37 ms
1477 bytes from 62.69.179.230: icmp_seq=2 ttl=55 time=5.02 ms

--- nu.nl ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 999ms
rtt min/avg/max/mdev = 4.376/4.700/5.024/0.324 ms
client001@Hash-001:~>

Dit is de hoogste MTU die ik kan pingen, hier zou ik dus 28 bij op mogen tellen, wat dus betekent dat ik op 1497.

Deze waarde is nog steeds hoger als die van de server welke 1492 is!

Moet ik nu de MTU met ifconfig eth0 mtu 1497 doen?
En moet ik dan nog iets doen? Want als ik die 1492 opgeef dan gebeurd er nog vrij weinig!

[ Voor 6% gewijzigd door BSeB op 05-08-2006 18:47 ]

[PjotrP]

BSeB schreef op zaterdag 05 augustus 2006 @ 18:42:
client001@Hash-001:~> ping -M dont -s 1469 nu.nl
PING nu.nl (62.69.179.230) 1469(1497) bytes of data.
1477 bytes from 62.69.179.230: icmp_seq=1 ttl=55 time=4.37 ms
1477 bytes from 62.69.179.230: icmp_seq=2 ttl=55 time=5.02 ms

ik neem aan dat Hash-001 je client is?

Dit is de hoogste MTU die ik kan pingen, hier zou ik dus 28 bij op mogen tellen, wat dus betekent dat ik op 1497.

hmm.. das een gekke waarde.

Deze waarde is nog steeds hoger als die van de server welke 1492 is!

kun je mij de output van ifconfig van al je interfaces van je server geven?

Moet ik nu de MTU met ifconfig eth0 mtu 1497 doen?
En moet ik dan nog iets doen? Want als ik die 1492 opgeef dan gebeurd er nog vrij weinig!

daarom vroeg ik een tijd geleden of je je MTU op 1400 wilt zetten. Want als je MTU het probleem was, is het dan iig opgelost. Daarna kun je je MTU gaan finetunen.

[BSeB]

Client:

eth0 Link encap:Ethernet HWaddr
inet addr:172.20.32.108 Bcast:172.20.35.255 Mask:255.255.252.0
inet6 addr: fe80::211:9ff:feed:15d4/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:31792 errors:0 dropped:0 overruns:0 frame:57
TX packets:21069 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:30750938 (29.3 Mb) TX bytes:3171421 (3.0 Mb)
Interrupt:66

Server
dsl0 Link encap:Point-to-Point Protocol
inet addr:xxxxxxxxx P-t-P:145.94.1.0 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1492 Metric:1
RX packets:56714 errors:0 dropped:0 overruns:0 frame:0
TX packets:38971 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:3
RX bytes:38450138 (36.6 Mb) TX bytes:3123755 (2.9 Mb)

eth0 Link encap:Ethernet HWaddr
inet addr:172.20.32.105 Bcast:172.20.35.255 Mask:255.255.252.0
inet6 addr: fe80::20e:cff:feaa:91b4/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:237905478 errors:62 dropped:0 overruns:0 frame:31
TX packets:735606 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:2493872443 (2378.3 Mb) TX bytes:546673767 (521.3 Mb)
Base address:0xc000 Memory:cb020000-cb040000

eth1 Link encap:Ethernet HWaddr
inet addr:172.20.32.106 Bcast:172.20.35.255 Mask:255.255.252.0
inet6 addr: fe80::20e:cff:feb8:c4f3/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:237692635 errors:0 dropped:0 overruns:0 frame:0
TX packets:299481 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:2545907286 (2427.9 Mb) TX bytes:32448534 (30.9 Mb)
Base address:0xc800 Memory:cb040000-cb060000

[BSeB]

He ik heb iets gevonden als ik de MTU op de client op de gevraagde 1400 zet kan ik 1 maal snel een pagina opvragen, als ik te lang wacht verlies ik door de te lage MTU de connectie naar de server en klapt alles eruit. Als ik hierna de MTU weer op 1500 zet gaat alles weer goed.

Misschien heb je wat aan deze info. Overigens is de device die ik gebruik om de bak de server te benaderen eth1 of 0 dat moet niks uitmaken, ook andere mensen die niet op internet kunnen moeten de server kunnen bereiken!

[PjotrP]

je hebt nogal wat gefragmenteerde packets (zie frame: xxxx)
(overigens is dit op zich niet fout. Alleen accepteren sommige firewalls alleen 'normale' pakketjes).

Laat ik voor de vlotheid maar eens 1 vraag per keer stellen:
doet je verbinding het wel normaal als je client een MTU van 1400 heeft?

[PjotrP]

BSeB schreef op zaterdag 05 augustus 2006 @ 19:17:
He ik heb iets gevonden als ik de MTU op de client op de gevraagde 1400 zet kan ik 1 maal snel een pagina opvragen

prima. Dat was dus de oorzaak.

als ik te lang wacht verlies ik door de te lage MTU de connectie naar de server

specificeer. Heb je een continue-verbinding met de server die je verliest? Hoe weet je dat?

en klapt alles eruit.

wat klapt eruit? Krijg je foutmeldingen? Verlies je je IP-adres?

Als ik hierna de MTU weer op 1500 zet gaat alles weer goed.

alles? Dus dan kun je weer op tweakers.net? Lijkt me sterk..

Misschien heb je wat aan deze info. Overigens is de device die ik gebruik om de bak de server te benaderen eth1 of 0 dat moet niks uitmaken

zo te zien gebruik jij eth0
En idd, het maakt niks uit. De bottleneck zit in de DSL-interface

[BSeB]

Nee, ik bedoel hiermee dat als ik de MTU op 1400 zet dat ik dan 1 maal een pagina zoals tweakers kan openen, hierna sluit de verbinding naar de server, hij accepteerd zeg maar geen pakketjes meer van mijn client door de geweizigde mtu, ik kan dus ook niet meer internetten, ik kan alleen nog wat pingen in het netwerk (intern).

Als ik hierna de MTU weer omhoog zet naar 1500 kan ik weer internetten alleen niet op de eerder genoemde sites!

[freggy]

Welke kernelversie? Heb je ecn aan of uit staan (cat /proc/sys/net/ipv4/tcp_ecn), en wat met tcp window scaling (cat /proc/sys/net/ipv4/tcp_window_scaling)? Check ook eens http://kerneltrap.org/node/6723 .

[BSeB]

Om je vragen te beantwoorden, dit is mijn client:

client001@Hash-001:~> cat /proc/sys/net/ipv4/tcp_ecn
0
client001@Hash-001:~> cat /proc/sys/net/ipv4/tcp_window_scaling
1
client001@Hash-001:~> uname -a
Linux Hash-001 2.6.16.13-4-default #1 Wed May 3 04:53:23 UTC 2006 x86_64 x86_64 x86_64 GNU/Linux
client001@Hash-001:~>

En dit de server:

Hash:~ # cat /proc/sys/net/ipv4/tcp_ecn
0
Hash:~ # cat /proc/sys/net/ipv4/tcp_window_scaling
1
Hash:~ # uname -a
Linux Hash 2.6.16.13-4-default #1 Wed May 3 04:53:23 UTC 2006 i686 athlon i386 GNU/Linux
Hash:~ #

[PjotrP]

window scaling is niet de oorzaak. Met 2.6.17 kun je bijvoorbeeld http://www.everymac.com/ niet bekijken.
Ik draai 2.6.17 en kan idd everymac.com niet bekijken. tweakers.net en dynamische gedeelte van marktplaats.nl wel tenzij mijn server een te lage MTU heeft. Precies hetzelfde als Saiya_Jin_Vegeta heeft.
Aan je ifconfig-output te zien creeert je server fragmented packets, iets wat de firewall van tweakers niet wil zien.

Met een MTU van 1400 kun je dus 1-malig tweakers.net opvragen.. heel vreemd. Je zegt dat je verbinding 'er dan uitklapt'. Komt dat door de server of door je client?

Testje: verlaag je MTU op je client naar 1400, vraag pagina's op totdat je verbinding er uit klapt.
Wat is nu de output van ifconfig?

Probeer verbinding te herstellen door vernieuwde dhcp aanvraag (ik neem aan dat je je IP via DHCP krijgt). Als je dhcpcd gebruikt:
# dhcpcd -k && dhcpcd

Wat gebeurt er nu?

[BSeB]

Hoi, ik ben op dit moment niet in mijn huis, maar ik stel mijn netwerk statisch in, heb dus niks met dhcp te maken.

Ik ben morgenavond weer thuis en kan ik weer verder testen en zal ik meteen het gevraagde testen.

Kan het niet zo zijn dat de MTU aan beide kanten van de lijn verlaagd moet worden, dus de mtu van de client naar 1400 en de eth0 van de server naar 1400?

[PjotrP]

als je de MTU verlaagd hebt en je de ifconfig-output hebt gepost, kun je ook nog iets anders proberen.

Op je server kun je de MSS (maximum segment size) veranderen; stel deze ook op 1400 in. Hiervoor gebruik je het commando 'route'
1) # route
(vraag alle bestaande routes op, zoek route die je verkeer route naar buiten, dus met extern-IP als gateway)
2) # route del xxx
(verwijder route xxx, waarbij xxx=route naar buiten)
3) # route add xxx netmask ..... gw ..... metric ... mss 1400 dev eth0
(zet nieuwe route, gebruik alle oude waardes behalve mss. Zet deze op 1400)

Lees even de manual van route door om te weten wat je allemaal kunt veranderen en wat het betekent.

Na stap 2 ben je je internetverbinding kwijt, na stap 3 moet deze weer terug zijn.

[Kees]

TCPMSS
This target allows to alter the MSS value of TCP SYN packets, to control the maximum size for that connec-
tion (usually limiting it to your outgoing interface's MTU minus 40). Of course, it can only be used in
conjunction with -p tcp.
This target 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

--set-mss value
Explicitly set MSS option to specified value.

--clamp-mss-to-pmtu
Automatically clamp MSS value to (path_MTU - 40).

These options are mutually exclusive.

Dat kan je probleem zijn

[BSeB]

Ga ik vanavond als ik terug ben meteen proberen!

[BSeB]

Kees schreef op maandag 07 augustus 2006 @ 15:48:
[...]
Dat kan je probleem zijn

You're the man, het werkt nu hemelaal weer top. Ik ben je zeer dankbaar.

[Verwijderd]

BSeB schreef op maandag 07 augustus 2006 @ 23:09:
[...]
You're the man, het werkt nu hemelaal weer top. Ik ben je zeer dankbaar.

Ik ben ZEER benieuwd naar waar je de 3 rules hebt ingevoerd. Ikzelf heb dit probleem ook gehad toen ik suse linux installeerde. Toen gebruikte ik susefirewall2. Heb jij die ook gebruikt?

Moeten die rules dan in "/etc/sysconfig/SuSEfirewall2" worden ingevoerd?
Moet
"iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN \
-j TCPMSS --clamp-mss-to-pmtu"
ingevoerd worden als:
"iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu"
Alvast bedankt