У меня есть работающие веб-сайты, работающие под Apache. Они прекрасно доступны из локальной сети.
Я также настроил часть сервера так, чтобы он был доступен из 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
Существенные различия заключаются в том, что при успешном подключении из локальной сети второй пакет будет иметь MSS=1460, а третий пакет будет иметь Win=65536. А при отправке четвертый пакет содержит GETкоманду HTTP с моим IP-адресом локальной сети в качестве источника и т. д.
Если я использую на стороне сервера, то в проблемном сценарии (сторона WAN) (вызванный после получения tcpdumpbreak) я получаю следующее :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.confforce 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, который меняется с определенной периодичностью, если все в порядке или результаты теста в порядке, возможно, дома вы установили динамический IP. Из сетевых подключений установите для себя статический IP, напримерздесь. И вы не дадите никому получить тот же самый IP, поскольку вы зарезервировали этот IP в настройках модема. Зарезервировать IP довольно просто, найдите настройку DHCP под вашим модемом, предположим, что ваш модем находится на 192.168.1.1, и вы устанавливаете для себя 192.168.1.2, в этом случае в настройках DHCP введите 192.168.1.3 в качестве начальной точки, если ничего из этого не работает, свяжитесь со своим интернет-провайдером, в некоторых странах некоторые порты могут быть не открыты, например, я был на Кипре полгода назад, и открытие порта 80 там запрещено.
--ОБНОВЛЯТЬ--
Как я понимаю, как клиент с другого компьютера вы можете подключиться, но как сервер при попытке подключения вы не можете увидеть страницу. Это основная проблема, если вы не используете прокси-маршрутизаторы не могут направлять запросы, которые исходят из себя в себя, попробуйте использовать веб-прокси, в этом случае, вероятно, это сработает. Вы ничего не можете с этим сделать, как сервер, вы не можете подключиться к своей собственной сети без прокси-сервера