www.google.com segt/okontaktbart via iptables NAT

Permalänk
Medlem

www.google.com segt/okontaktbart via iptables NAT

FINAL EDIT: Löste problemet genom att gå runt det. En separat brandväggsburk som fick köra Ubuntu 10.04 med kernel 2.6.* fick min routing att hoppa igång på maxfart igen.

EDIT: Märkte att problemet försvann när jag körde en virtuell Windows 7 -maskin på min dator. Så adderad komplexitet och ett extra hopp gjorde att det gick snabbare :S

Jag har nyligen uppgraderat min server/brandvägg hemma och har råkat ut för ett oerhört irriterande problem.

När man i webläsaren på en av klienterna skriver in www.google.com i adressfältet första gången efter man startat webläsaren (chrome canary, chrome, IE) står det i statusfältet "waiting for www.google.com" eller "website found, waiting for reply" i allt från en till 5-20sek innan sidan laddas, ibland laddas den inte alls. Oftast tar det 5-10SEK.
När man lämnar webläsaren med ett googlefönster öppet och senare försöker söka, då får man ofta inga resultat alls.

Min ISP är comhem och jag har 200/10.

Om jag låter servern använda de av comhems DHCP tillhandahållna DNSerna blir väntetiderna snarare 20sek och än oftare kommer jag inte åt google alls.

Kör jag 8.8.8.8 och 130.237.72.200 som namnservrar, både på servern och klienterna, fungerar det bättre, men fortfarande långt från stabilt.

Servern kör Ubuntu LTS 12.04 och jag använder iptables för NAT/brandvägg och kör ett script som tidigare fungerat fint.

Lite småfördröjningar uppstår även på andra siter, men inget som jag bryr mig om. Det är bara google som är såhär katastrofalt dålig...
Om jag kör lynx på servern fungerar google felfritt.

Nedan följer mitt iptablesscript (minus öppna portar):
#!/bin/sh
LAN_IP="192.168.0.1/32"
LAN_BCAST_ADRESS="192.168.0.255/32"

LOCALHOST_IP="127.0.0.1/32"
#Uncomment next line if you have a static IP to the Internet.
#STATIC_IP="1.2.3.4"
#Uncomment next line if you have a dynamic IP to the Internet. Pay attention to select the correct
#ethernetcard.
STATIC_IP=`/sbin/ifconfig eth0 |sed -n '/inet/s/^[ ]*inet addr:\([0-9.]*\).*/\1/p'`

INET_IFACE="eth0"
LAN_IFACE="eth1"
IPTABLES="/sbin/iptables"

echo "Starting IPv4 firewall..."

#This line will start the NAT.
echo "1" > /proc/sys/net/ipv4/ip_forward
#This line will protect from some DOS (Denial of service) attacks.
echo "1" > /proc/sys/net/ipv4/tcp_syncookies

#Log and drop packets that do not follow the rules bellow.
$IPTABLES -N logdrop
#$IPTABLES -A logdrop -j LOG
$IPTABLES -A logdrop -j DROP
#Log and drop connections that were not started from your network.
$IPTABLES -A INPUT -p tcp ! --syn -m state --state NEW -j LOG --log-prefix "NEW NOT SYN "
$IPTABLES -A INPUT -p tcp ! --syn -m state --state NEW -j DROP
$IPTABLES -A FORWARD -p tcp ! --syn -m state --state NEW -j LOG --log-prefix "NEW NOT SYN "
$IPTABLES -A FORWARD -p tcp ! --syn -m state --state NEW -j DROP

#Log and drop connections that tried to reach your internal network.
$IPTABLES -A FORWARD --in-interface $INET_IFACE --destination $LAN_BCAST_ADRESS -j logdrop
$IPTABLES -A FORWARD --in-interface $LAN_IFACE --destination $STATIC_IP -j logdrop

#Allowing forwarding.
$IPTABLES -A FORWARD --in-interface $LAN_IFACE -j ACCEPT
$IPTABLES -A FORWARD --in-interface $INET_IFACE -m state --state ESTABLISHED,RELATED -j ACCEPT

#Accepting some icmptypes...
$IPTABLES -A INPUT -p icmp --icmp-type 0 -j ACCEPT
$IPTABLES -A INPUT -p icmp --icmp-type 8 -j ACCEPT
$IPTABLES -A INPUT -p icmp --icmp-type 3 -j ACCEPT
$IPTABLES -A INPUT -p icmp --icmp-type 11 -j ACCEPT

#Allow the server to talk to itself.
$IPTABLES -A INPUT --in-interface lo --source 127.0.0/8 -j ACCEPT

#Allow connections that starts from you network to get answer.
$IPTABLES -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
#Allow all connections with source from your local network. Only comment this line out if you are sure of what you
#are doing.
$IPTABLES -A INPUT -p ALL -d $LAN_IP -j ACCEPT
********************************************************

$IPTABLES -A INPUT -j logdrop
$IPTABLES -I INPUT -s 212.113.64.9 -j DROP
#Prevent slow DNS lookups and list
$IPTABLES -n -L

Permalänk
Medlem

google var segt ett tag för mig idag men nu har det ordnat till sig verkar det som.
Använder /ncr f.ö

Permalänk
Medlem

Ovan har pågått sedan jag bytte maskin som kör brandväggen för ett par dagar sedan, så jag misstänker att det är något i mitt script som funkade i Ubuntu 10.10 men som inte riktigt funkar i 12.04.

Jag är helt förvirrad av detta. Har aldrig sett ett liknande problem...

EDIT: insåg just att det här problemet är påtagligt endast i kontakt med amerikanska siter, typ facebook, google, imdb osv och inte alls märks med svenska siter i stil med aftonbladet, sweclockers, IDG och swedroid.

EDIT: Med någon av klienterna inkopplad direkt i modemet fungerar allt klanderfritt och namnuppslagningarna går på nolltid. Så om någon moderator ser detta, flytta gärna tråden till linuxforumet eftersom problemet ligger i min konfiguration av NAT/DNS/DHCP.

Permalänk
Medlem

Funkar det bättre om du stänger av din FW (flusha alla regler utom NAT)?
Har du öppnat för DNS (udp port 53)?

Har du ipv6 aktiverat? Testa att stänga av i dina datorer.

Annars är ett generellt tips att köra wireshark/tcpdump så ser du vad som går fel.
Du har ju möjlighet att göra detta på både eth0 och eth1.

Permalänk
Medlem

-Marginellt snabbare svarstider om jag endast kör NAT, kan vara placebo...
-Ja, port 53 är öppen för UDP-paket
-Ja, IPV6 var aktivt men är avstängt nu
-TCPdump avslöjar inget kosntigt vad jag kan se

Om jag manuellt skriver in www.google.coms IP (173.194.32.51) på någon av klienterna så försvinner all fördröjning helt och hållet. Så problemet har garanterat med DNS-uppslag att göra på något plan.

Permalänk
Medlem

Postar en tracert till google. först från min maskin sedan från servern. Ser inget konstigt förutom att hoppet till 213.200.189.136 tar hysteriskt lång tid, men inga 30 sekunder...

C:\Windows\system32>tracert www.google.com

Tracing route to www.google.com [173.194.32.49]
over a maximum of 30 hops:

1 <1 ms 1 ms <1 ms XXXXXXXXXXXXXXXXXX [192.168.0.1]
2 8 ms 7 ms 7 ms to-doc-3-cable4-0.comhem.se [80.217.48.1]
3 591 ms 300 ms 211 ms 213.200.189.136
4 9 ms 8 ms 7 ms 83.255.253.204
5 9 ms 9 ms 9 ms google-link.comhem.se [83.255.245.246]
6 29 ms 10 ms 10 ms 209.85.250.192
7 17 ms 12 ms 11 ms 216.239.43.255
8 12 ms 21 ms 10 ms arn06s02-in-f17.1e100.net [173.194.32.49]

Trace complete.

root@XXX:/etc/bind# traceroute www.google.com
traceroute to www.google.com (173.194.32.48), 30 hops max, 60 byte packets
1 to-doc-3-cable4-0.comhem.se (80.217.48.1) 7.791 ms 7.793 ms 7.780 ms
2 213.200.189.136 (213.200.189.136) 1652.915 ms 1653.237 ms 1653.644 ms
3 83.255.253.204 (83.255.253.204) 10.237 ms 10.224 ms 10.307 ms
4 netnod-ix-ge-b-sth-1500.google.com (194.68.128.115) 8.649 ms 9.220 ms 9.213 ms
5 209.85.250.192 (209.85.250.192) 10.112 ms 10.100 ms 10.060 ms
6 216.239.43.255 (216.239.43.255) 9.142 ms 11.187 ms 11.075 ms
7 arn06s02-in-f16.1e100.net (173.194.32.48) 8.142 ms 8.117 ms 8.092 ms

Permalänk
Medlem
Skrivet av Gabrioth:

-TCPdump avslöjar inget kosntigt vad jag kan se

Om du bara sniffar på port 53 och gör en nslookup på en klient så borde du se när i tid frågan skickas och när ett svar på frågan anländer. Vad jag menar är att du borde kunna se svarstider på dina dns-frågor på LAN resp WAN sidan av servern.

Skrivet av Gabrioth:

root@XXX:/etc/bind#

Kör du en egen DNS?
Funkar det bättre om du sätter upp den som en rekursiv resolver, dvs dina klienter har din server som DNS och den skickar i sin tur frågorna vidare till en "riktig" DNS-resolver?

Permalänk
Medlem
Skrivet av madtop:

Om du bara sniffar på port 53 och gör en nslookup på en klient så borde du se när i tid frågan skickas och när ett svar på frågan anländer. Vad jag menar är att du borde kunna se svarstider på dina dns-frågor på LAN resp WAN sidan av servern.

Ah, underligt nog så sker hela förfarandet på under en sekund när jag gör så...

Skrivet av madtop:

Kör du en egen DNS?
Funkar det bättre om du sätter upp den som en rekursiv resolver, dvs dina klienter har din server som DNS och den skickar i sin tur frågorna vidare till en "riktig" DNS-resolver?

Japp, bind9, endast cachande/forwardande. Att sätta den som primär DNS har ingen effekt.

Märkte att problemet inte uppstår när jag kör en virtuell Windows 7 -maskin på min dator. Så adderad komplexitet och ett extra hopp gjorde att det gick snabbare :S Likaså fungerade det klanderfritt med en virtuell maskin på servern.

Permalänk
Medlem

Gick runt problemet genom att sätta en separat burk med Ubuntu 10.04 som brandvägg. Nu funkar det felfritt.
Frågan är varför just google.com fungerade så dåligt om man körde mitt iptablesscript på nyare kärna än 2.6?

Permalänk
Medlem

När du resolvar t.ex. www.google.com får du både IPv6 och IPv4 svar.
Antagligen försökte din webläsare gå till IPv6 adressen - vilket inte gick.. så den timar ut och webläsaren går då mot en IPv4 adress vilket gick bättre.

Du kan bekräfta beteendet i en sniffer som wireshark eller tcpdump.

Visa signatur

Networking geek, #28735

Permalänk
Medlem
Skrivet av thadizzy:

När du resolvar t.ex. www.google.com får du både IPv6 och IPv4 svar.
Antagligen försökte din webläsare gå till IPv6 adressen - vilket inte gick.. så den timar ut och webläsaren går då mot en IPv4 adress vilket gick bättre.

Du kan bekräfta beteendet i en sniffer som wireshark eller tcpdump.

Men, varför funkar då exakt samma brandväggs/NATregler på en äldre dist/kärna? Räcker det inte att slå av IPV6 i klienten och routern för att den inte skall försöka gå via IPV6? Jag klickade alltså ur rutan IPV6 i egentskaperna för nicet i windows.
Försökte även med att sätta upp rudimentär NAT/Forwarding för IPV6 på routern.
Plus att comhem tyvärr inte stödjer IPV6 ännu