tcp, wo soll ich anfangen zu suchen? Ich kann den Server vom LAN aus erreichen, bekomme aber CONNECTION RESET vom WAN

tcp, wo soll ich anfangen zu suchen? Ich kann den Server vom LAN aus erreichen, bekomme aber CONNECTION RESET vom WAN

Ich habe funktionierende Websites, die unter Apache laufen. Sie sind vom LAN aus problemlos zugänglich.

Ich habe auch einen Teil des Servers so eingerichtet, dass er über WAN erreichbar ist. Das hat zunächst funktioniert (zweifellos Anfängerglück), aber jetzt ERR_CONNECTION_RESETkommt es ständig wieder. Ich habe alle Möglichkeiten erkundet, die mir eingefallen sind, habe sogar Apache neu installiert und habe jetzt keine Ideen mehr.

Die Portweiterleitung ist ordnungsgemäß eingerichtet und wurde mit überprüft nmap. Sowohl lokale als auch Remote-Scans zeigen, dass mein Port geöffnet ist.

Ich habe meine Regel noch einmal überprüft ufwund die Protokollierung dafür aktiviert. Das Protokoll zeigt, dass Pakete [UFW ALLOW]sowohl für lokale als auch für Remote-Verbindungen eingehen.

Ich habe Wireshark-Captures vom Client aus ausgeführt. Im (fehlgeschlagenen) Remote-Verbindungsszenario werden nur drei Pakete ausgetauscht:

1   0.000000000 [local_IP]  [remote_IP]   TCP 66  49527→1123 [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1
2   0.058425000 [remote_IP]   [local_IP]  TCP 66  1123→49527 [SYN, ACK] Seq=0 Ack=1 Win=29200 Len=0 MSS=1320 SACK_PERM=1 WS=128
3   0.058504000 [local_IP]  [remote_IP]   TCP 54  49527→1123 [ACK] Seq=1 Ack=1 Win=16384 Len=0

Die wesentlichen Unterschiede bestehen darin, dass bei einer erfolgreichen Verbindung vom LAN das zweite Paket MSS=1460und das dritte Paket enthalten wird Win=65536. Und wenn das vierte Paket gesendet wird, enthält es den HTTP- GETBefehl mit meiner LAN-IP als Quelle und so weiter.

Wenn ich es tcpdumpserverseitig verwende, erhalte ich im problematischen Szenario (WAN-Seite) Folgendes (Break wurde aufgerufen, nachdem connection resetes empfangen wurde):

$ sudo tcpdump -n -tttt -i eth0 port 1123
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
2015-07-14 06:38:45.291695 IP 92.95.32.112.49361 > 192.168.1.10.1123: Flags [S], seq 3726787794, win 8192, options [mss 1320,nop,wscale 8,nop,nop,sackOK], length 0
2015-07-14 06:38:45.291735 IP 192.168.1.10.1123 > 92.95.32.112.49361: Flags [S.], seq 2812896430, ack 3726787795, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
2015-07-14 06:38:45.351536 IP 92.95.32.112.49361 > 192.168.1.10.1123: Flags [.], ack 1, win 64, length 0
^C
3 packets captured
3 packets received by filter
0 packets dropped by kernel

Bei einer lokalen Verbindung sieht es eher so aus. Beachten Sie die unterschiedliche Fenstergröße beim dritten Paket:

$ sudo tcpdump -n -tttt -i eth0 port 1123
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
2015-07-14 06:41:33.112315 IP 192.168.1.50.49379 > 192.168.1.10.1123: Flags [S], seq 3570261874, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
2015-07-14 06:41:33.112357 IP 192.168.1.10.1123 > 192.168.1.50.49379: Flags [S.], seq 3490289174, ack 3570261875, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
2015-07-14 06:41:33.512742 IP 192.168.1.50.49379 > 192.168.1.10.1123: Flags [.], ack 1, win 256, length 0
2015-07-14 06:41:33.514046 IP 192.168.1.50.49379 > 192.168.1.10.1123: Flags [P.], seq 1:433, ack 1, win 256, length 432
2015-07-14 06:41:33.514079 IP 192.168.1.10.1123 > 192.168.1.50.49379: Flags [.], ack 433, win 237, length 0
2015-07-14 06:41:33.554794 IP 192.168.1.10.1123 > 192.168.1.50.49379: Flags [.], seq 1:1461, ack 433, win 237, length 1460
2015-07-14 06:41:33.554818 IP 192.168.1.10.1123 > 192.168.1.50.49379: Flags [P.], seq 1461:2768, ack 433, win 237, length 1307
[...]^C
919 packets captured
919 packets received by filter
0 packets dropped by kernel

tcp6Mir ist aufgefallen, dass der Dienst anscheinend nur mit und nicht mit meinem SSH-Server ausgeführt wird . Könnte das die Ursache sein? Update: anscheinend NICHT, Listen 0.0.0.0:1123da /etc/apache2/ports.confich es erzwungen habe tcp, aber das Problem blieb bei der Verbindung von der WAN-Seite bestehen.

$ sudo netstat -plunt | grep ssh
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      1510/sshd       
tcp6       0      0 :::22                   :::*                    LISTEN      1510/sshd       
$ sudo netstat -plunt | grep apache2
tcp6       0      0 :::1123                 :::*                    LISTEN      3290/apache2    

Ich konnte /var/log/apache2mit Folgendem nichts über diese Ereignisse erfassen: LogLevel info, LogLevel debugund LogLevel trace8(und den entsprechenden Neustart des Dienstes). Alle Dateien im Ordner behalten in allen Fällen den gleichen Datumsstempel vor und nach der fehlgeschlagenen Verbindung.

Ich kann mich irren, aber da Apache so wenig Informationen liefert, frage ich mich jetzt, ob dies mit einem SQL- oder PHP-Problem mit externen Links zusammenhängen könnte, aber damit habe ich eigentlich keine Erfahrung. Der hier in Frage kommende Dienst ist ownCloud.

Irgendwelche Ideen, wie man das Problem weiter beheben und herausfinden kann, was falsch sein könnte?

Antwort1

Überprüfen Sie zunächst, ob die Ports einwandfrei funktionieren. Sie können dies mit einem Port-Scan-Tool wieDas. Wenn es Probleme gibt, überprüfen Sie Ihre IP erneut, da Sie wahrscheinlich eine dynamische IP haben und diese sich in regelmäßigen Abständen ändert. Wenn dies in Ordnung ist oder das Testergebnis in Ordnung ist, legen Sie zu Hause wahrscheinlich eine dynamische IP fest. Legen Sie über Ihre Netzwerkverbindungen eine statische IP für sich selbst fest, z. B.Hier. Und um zu verhindern, dass jemand genau dieselbe IP erhält, indem Sie diese IP in den Modemeinstellungen reservieren. Das Reservieren einer IP ist ganz einfach. Suchen Sie die DHCP-Einstellungen unter Ihrem Modem. Nehmen wir an, Ihr Modem ist auf 192.168.1.1 eingestellt und Sie legen für sich selbst 192.168.1.2 fest. Geben Sie in diesem Fall in den DHCP-Einstellungen 192.168.1.3 als Startpunkt ein. Wenn nichts davon funktioniert, wenden Sie sich an Ihren ISP. In einigen Ländern dürfen einige Ports möglicherweise nicht geöffnet werden. Ich war beispielsweise vor einem halben Jahr auf Zypern und dort ist das Öffnen von Port 80 verboten.

--AKTUALISIEREN--

So wie ich es verstehe, können Sie als Client von einem anderen Computer aus eine Verbindung herstellen, aber als Server können Sie die Seite nicht sehen, wenn Sie versuchen, eine Verbindung herzustellen. Dies ist ein Hauptproblem, es sei denn, Sie verwenden keinen Proxy. Router können Anfragen, die von sich selbst ausgehen, nicht an sich selbst weiterleiten. Versuchen Sie, einen Webproxy zu verwenden. In diesem Fall wird es wahrscheinlich funktionieren. Als Server können Sie nichts dagegen tun. Ohne Proxy können Sie keine Verbindung zu Ihrem eigenen Netzwerk herstellen.

verwandte Informationen