Eu tenho sites funcionando em execução no Apache. Eles são perfeitamente acessíveis a partir da LAN.
Eu também configurei parte do servidor para ser acessível a partir da WAN. Isso funcionou no começo (sorte do principiante, sem dúvida), mas agora ERR_CONNECTION_RESET é retornado consistentemente. Eu explorei todos os caminhos em que consegui pensar, até mesmo reinstalei o Apache e agora estou sem ideias.
O encaminhamento de porta está configurado corretamente e verificado com nmap . As verificações locais e remotas mostram minha porta aberta.
Eu verifiquei novamente a regra ufw e habilitei o registro para ela. O log mostra que os pacotes recebem [UFW ALLOW] para conexões de entrada locais e remotas.
Eu executei as capturas Wireshark do cliente. Apenas três pacotes são trocados no cenário de conexão remota (com falha):
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
As diferenças significativas são que quando se conecta com sucesso da LAN, o segundo pacote terá MSS=1460 e o terceiro pacote terá Win=65536 . E quando enviado, o quarto pacote contém o comando GET do HTTP com o meu IP da LAN como fonte, e assim por diante.
Se eu usar tcpdump no lado do servidor, obtenho o seguinte no cenário problemático (lado da WAN) (quebra chamada depois que connection reset foi recebido):
$ 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
Ao se conectar localmente, ele se parece com isso; observe o tamanho diferente da janela no terceiro pacote:
$ 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
Tenho notado que aparentemente o serviço é executado apenas com tcp6 em oposição ao meu servidor ssh; Isso poderia ser a causa? Atualização: aparentemente NÃO porque Listen 0.0.0.0:1123 em /etc/apache2/ports.conf forçou tcp , mas o problema permaneceu ao conectar do lado da 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
Não consegui capturar nada em /var/log/apache2 sobre esses eventos usando o seguinte: LogLevel info , LogLevel debug e LogLevel trace8 (e a reinicialização do serviço apropriada). Todos os arquivos na pasta mantêm o mesmo registro de data antes e depois da falha na conexão, em todos os casos.
Eu posso estar errado, mas como o Apache fornece tão pouca informação, agora estou me perguntando se isso poderia estar relacionado a um problema de SQL ou PHP com links externos, mas na verdade não tenho nenhuma experiência com eles. O serviço em questão aqui é ownCloud.
Alguma idéia de como solucionar isso ainda mais e descobrir o que poderia estar errado?