tcp, где начать смотреть? Я могу достигнуть сервера от LAN, но ДЕЛАТЬ ПЕРЕСАДКУ СБРОС от WAN
У меня есть рабочие веб-сайты, работающие под Apache. Они совершенно доступны от LAN.
Я также настроил часть сервера, чтобы быть доступным от WAN. Это работало сначала (удача новичка, несомненно), но теперь ERR_CONNECTION_RESET последовательно возвращается. Я исследовал все проспекты, о которых я мог думать, даже переустановил Apache и теперь вне идей.
Перенаправление портов правильно настраивается и проверяется с nmap. И локальные и удаленные сканирования показывают мой порт, чтобы быть открытыми.
Я перепроверил мой ufw управляйте и позволил регистрироваться для него. Журнал показывает, что пакеты добираются [UFW ALLOW] и для локальных и для удаленных входящих соединений.
Я выполнил получения Wireshark от клиента. Только тремя пакетами обмениваются в (неудавшемся) сценарии удаленного соединения:
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
Причем существенные различия - то, что при соединении успешно от LAN, второй пакет будет иметь MSS=1460 и третий пакет будет иметь Win=65536. И при отправке четвертый пакет содержит HTTP GET команда с моим IP LAN как источник, и так далее.
Если я использую tcpdump на стороне сервера я получаю следующее в проблематичном (сторона WAN) сценарий (повреждение, названное после connection reset был получен):
$ 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
При соединении локально, это скорее похоже на это; отметьте другой размер окна на третьем пакете:
$ 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 в противоположность моему ssh серверу; это могло быть причиной? Обновление: по-видимому, НЕ как Listen 0.0.0.0:1123 в /etc/apache2/ports.conf действительно вызывал tcp, но проблема осталась при соединении от стороны WAN.
$ 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
Я не мог получить что-либо в /var/log/apache2 об этих событиях с помощью следующего: LogLevel info, LogLevel debug и LogLevel trace8 (и соответствующий сервисный перезапуск). Все файлы в папке сохраняют ту же метку даты прежде и после неудавшегося соединения во всех случаях.
Я могу быть неправым, но так как Apache дает так мало информации, я теперь задаюсь вопросом, могло ли это быть связано с SQL или проблемой PHP с внешними ссылками, но у меня на самом деле нет опыта с теми. Рассматриваемый сервис здесь является ownCloud.
Какие-либо идеи о том, как диагностировать это далее и узнать то, что могло быть неправильным?
1 ответ
Проверьте, хорошо работают ли порты, в первую очередь. Можно сделать это инструмент сканирования портов такой как это . Если существует проверка задач Ваш IP снова, потому что, вероятно, у Вас есть динамический IP и изменение к нескольким периодам, если это прекрасно, или результат испытаний прекрасен, вероятно, дома u, устанавливает динамический IP .from, Ваши сетевые соединения устанавливают статический IP для себя как здесь . И эй предотвратите кого-то для получения того же самого IP, поскольку Вы резервируете этот IP на настройках модема. Резервирование IP является довольно простой находкой dhcp устанавливающий под Вашим модемом, позволяет, берут yur модем, находится на 192.168.1.1, и Вы устанавливаете для себя 192.168.1.2 в этом случае в dhcp типе 192.168.1.3 настроек как startpoint, если не этих работ контакт к Вашему ISP в некоторых странах некоторым портам нельзя было бы позволить открыться, например, я был на Кипре половину года назад, и вводный порт 80 запрещается там.
- ОБНОВЛЕНИЕ -
, Как я понимаю как клиент от другого компьютера, который можно подключить, но как сервер, когда Вы пытаетесь соединиться, не видят страницу. Это - основная проблема, если Вы не используете маршрутизаторы прокси, не может запросы маршрута, который идет из себя в себя, пытаются использовать веб-прокси в этом случае, вероятно, это собирается работать. Вы ничего не можете сделать об этом как сервер, который Вы не можете подключить к своей собственной сети без прокси