Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
https hinterm Router funktioniert nicht immer
View unanswered posts
View posts from last 24 hours
View posts from last 7 days

 
Reply to topic    Gentoo Forums Forum Index Deutsches Forum (German) Diskussionsforum
View previous topic :: View next topic  
Author Message
manuels
Advocate
Advocate


Joined: 22 Nov 2003
Posts: 2146
Location: Europe

PostPosted: Mon Oct 08, 2012 10:36 pm    Post subject: https hinterm Router funktioniert nicht immer Reply with quote

Hallo,

ich habe auf meinem Router folgende iptables-Einstellungen:
Code:
# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     all  --  192.168.0.0/24       anywhere             ctstate NEW
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination


Der Router geht mit eth0 übers Kabelmodem ins Internet und "verteilt" es dann mittels wlan0 (hostapd):
Code:
# ifconfig eth0
eth0      Link encap:Ethernet  HWaddr 00:0d:b9:16:3e:e0 
          inet addr:84.112.204.30  Bcast:255.255.255.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:512789 errors:0 dropped:0 overruns:0 frame:0
          TX packets:255385 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:673310645 (673.3 MB)  TX bytes:22659566 (22.6 MB)
          Interrupt:11 Base address:0x2000

# ifconfig wlan0
wlan0     Link encap:Ethernet  HWaddr 00:14:a4:30:20:2d 
          inet addr:192.168.0.1  Bcast:192.168.0.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1400  Metric:1
          RX packets:122627 errors:0 dropped:0 overruns:0 frame:0
          TX packets:228309 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:11936091 (11.9 MB)  TX bytes:217468302 (217.4 MB)


Meistens funktioniert die Internet-Verbindung über WLAN von meinem Desktop aus auch ziemlich gut. Manchmal stockert das ganze aber ganz schön. Ich weiss allerdings nicht woran das liegen könnte.

Aber folgendes ist mir gerade aufgefallen:
HTTPS Verbindungen funktionieren im Allgemeinen (beispielsweise zu Github). Nur kann ich komischerweise vom Desktop nicht auf https://1.gravatar.com zugreifen:
Code:
$ curl -v 'https://1.gravatar.com/avatar/ad516503a11cd5ca435acc9bb6523536?s=25&d=identicon&forcedefault=y&r=G'
* About to connect() to 1.gravatar.com port 443 (#0)
*   Trying 68.232.35.121... connected
* successfully set certificate verify locations:
*   CAfile: none
  CApath: /etc/ssl/certs
* SSLv3, TLS handshake, Client hello (1):
Dort bleibt die Verbindung dann hängen.

Wenn ich aber das selbe Kommando auf dem Router starte, bekomme ich von 1.gravatar.com eine Antwort.
Wenn ich die URL ohne https, sondern nur mit http vom Desktop aufrufe, bekomme ich ebenfalls eine Antwort.

tcpdump liefert während des gescheiterten HTTPS-Verbindungsaufbaus vom Desktop aus (tcpdump gestartet auf dem Router) folgendes:
Code:
# tcpdump -i eth0 -v tcp
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
00:33:13.951489 IP (tos 0x0, ttl 63, id 13253, offset 0, flags [DF], proto TCP (6), length 60)
    84.112.204.30.37321 > 68.232.35.121.https: Flags [S], cksum 0x152a (correct), seq 2569911274, win 14600, options [mss 1460,sackOK,TS val 1411119 ecr 0,nop,wscale 4], length 0
00:33:13.959947 IP (tos 0x0, ttl 58, id 0, offset 0, flags [DF], proto TCP (6), length 52)
    68.232.35.121.https > 84.112.204.30.37321: Flags [S.], cksum 0x0fa6 (correct), seq 1338598653, ack 2569911275, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 6], length 0
00:33:13.960752 IP (tos 0x0, ttl 63, id 13254, offset 0, flags [DF], proto TCP (6), length 40)
    84.112.204.30.37321 > 68.232.35.121.https: Flags [.], cksum 0x85ee (correct), ack 1, win 913, length 0
00:33:13.963119 IP (tos 0x0, ttl 63, id 13255, offset 0, flags [DF], proto TCP (6), length 285)
    84.112.204.30.37321 > 68.232.35.121.https: Flags [P.], cksum 0x86fc (correct), seq 1:246, ack 1, win 913, length 245
00:33:13.977106 IP (tos 0x0, ttl 58, id 36454, offset 0, flags [DF], proto TCP (6), length 40)
    68.232.35.121.https > 84.112.204.30.37321: Flags [.], cksum 0x8795 (correct), ack 246, win 245, length 0
00:33:13.977835 IP (tos 0x0, ttl 58, id 36455, offset 0, flags [DF], proto TCP (6), length 1500)
    68.232.35.121.https > 84.112.204.30.37321: Flags [.], cksum 0x8cd4 (correct), seq 1:1461, ack 246, win 245, length 1460
00:33:13.978054 IP (tos 0x0, ttl 58, id 36456, offset 0, flags [DF], proto TCP (6), length 1500)
    68.232.35.121.https > 84.112.204.30.37321: Flags [.], cksum 0x7d85 (correct), seq 1461:2921, ack 246, win 245, length 1460
00:33:13.978876 IP (tos 0x0, ttl 58, id 36457, offset 0, flags [DF], proto TCP (6), length 1216)
    68.232.35.121.https > 84.112.204.30.37321: Flags [P.], cksum 0xfc85 (correct), seq 2921:4097, ack 246, win 245, length 1176
00:33:13.978945 IP (tos 0x0, ttl 58, id 36458, offset 0, flags [DF], proto TCP (6), length 715)
    68.232.35.121.https > 84.112.204.30.37321: Flags [P.], cksum 0x9a31 (correct), seq 4097:4772, ack 246, win 245, length 675
00:33:13.979959 IP (tos 0x0, ttl 63, id 13256, offset 0, flags [DF], proto TCP (6), length 52)
    84.112.204.30.37321 > 68.232.35.121.https: Flags [.], cksum 0xc9ea (correct), ack 1, win 913, options [nop,nop,sack 1 {2921:4097}], length 0
00:33:13.980518 IP (tos 0x0, ttl 63, id 13257, offset 0, flags [DF], proto TCP (6), length 52)
    84.112.204.30.37321 > 68.232.35.121.https: Flags [.], cksum 0xc747 (correct), ack 1, win 913, options [nop,nop,sack 1 {2921:4772}], length 0
00:33:13.999093 IP (tos 0x0, ttl 58, id 36459, offset 0, flags [DF], proto TCP (6), length 1500)
    68.232.35.121.https > 84.112.204.30.37321: Flags [.], cksum 0x8cd4 (correct), seq 1:1461, ack 246, win 245, length 1460

Weiss jemand von euch was hier vor sich gehen könnte.

Ich habe keine Ahnung warum die HTTPS-Verbindung vom Desktop aus scheitert, aber vom Router aus funktioniert.
Und warum es mit HTTP von beiden (Desktop und Router) aus funktioniert macht es für mich noch schleierhafter....

Danke für eure Tipps!

Manuel
_________________
Build your own live cd with catalyst 2.0!
Back to top
View user's profile Send private message
Treborius
Guru
Guru


Joined: 18 Oct 2005
Posts: 538
Location: Berlin

PostPosted: Tue Oct 09, 2012 6:57 am    Post subject: Reply with quote

kannst du mal zeigen, wie du iptables konfiguriert hast?
NAT zB?

habe das selbe setup ...
bei deiner anfrage bekommst du in tcpdump einfach keine antwort vom server ...

meine forward chain sieht auch anders aus ... imho fehlt dir da die "rückrichtung"

Code:

Chain FORWARD (policy DROP)
target     prot opt source               destination
DROP       all  --  anywhere             10.18.0.0/24
ACCEPT     all  --  10.18.0.0/24         anywhere
ACCEPT     all  --  anywhere             10.18.0.0/24

_________________
System : Intel Core2 Quad Q6600
Back to top
View user's profile Send private message
bell
Guru
Guru


Joined: 27 Nov 2007
Posts: 420

PostPosted: Tue Oct 09, 2012 7:09 am    Post subject: Reply with quote

Quote:
Chain FORWARD (policy ACCEPT)
Deine Firewall lässt alles durch. Daran kann es also nicht liegen. Die "curl" Ausgabe sagt auch "connected". Landet irgend was in /var/log/messages wenn die Verbindung hängt?
Back to top
View user's profile Send private message
manuels
Advocate
Advocate


Joined: 22 Nov 2003
Posts: 2146
Location: Europe

PostPosted: Tue Oct 09, 2012 5:56 pm    Post subject: Reply with quote

nach /var/log/messages wird kein Fehler geschrieben.

hier meine Kommandos:
Code:
iptables --flush
iptables --table nat --flush
iptables --delete-chain
iptables --table nat --delete-chain

iptables -A FORWARD -i wlan0 -o eth0 -s 192.168.0.0/24 -m conntrack --ctstate NEW -j ACCEPT
iptables -A FORWARD -i wlan0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
ifconfig eth0 mtu 1500

_________________
Build your own live cd with catalyst 2.0!
Back to top
View user's profile Send private message
bell
Guru
Guru


Joined: 27 Nov 2007
Posts: 420

PostPosted: Wed Oct 10, 2012 12:18 pm    Post subject: Reply with quote

Wie gesagt, Deine Firewall solltest Du überdenken. Denn diese bietet 0-Schutz. Es wird wirklich alles durchgelassen, denn dort ist kein einziger "DROP" oder "REJECT". Aber das wäre jetzt ein anderes Thema.

Das einzige was ich mir vorstellen kann ist dass "ifconfig eth0 mtu 1500" das Problem verursachen könnte. Lasse die MTU doch beim Standard wie das Interface sich selbst konfiguriert.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Deutsches Forum (German) Diskussionsforum All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum