
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_RESET
kommt 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 ufw
und 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=1460
und das dritte Paket enthalten wird Win=65536
. Und wenn das vierte Paket gesendet wird, enthält es den HTTP- GET
Befehl mit meiner LAN-IP als Quelle und so weiter.
Wenn ich es tcpdump
serverseitig verwende, erhalte ich im problematischen Szenario (WAN-Seite) Folgendes (Break wurde aufgerufen, nachdem connection reset
es 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
tcp6
Mir 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:1123
da /etc/apache2/ports.conf
ich 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/apache2
mit Folgendem nichts über diese Ereignisse erfassen: LogLevel info
, LogLevel debug
und 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.