Tenho sites em funcionamento rodando no Apache. Eles são perfeitamente acessíveis a partir da LAN.
Também configurei parte do servidor para ser acessível pela WAN. Isso funcionou no início (sorte de iniciante, sem dúvida), mas agora ERR_CONNECTION_RESETé retornado de forma consistente. Eu explorei todos os caminhos que pude imaginar, até 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 que minha porta está aberta.
Verifiquei novamente minha ufwregra e habilitei o registro para ela. O log mostra que os pacotes chegam [UFW ALLOW]para conexões de entrada locais e remotas.
Executei capturas do 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, ao conectar-se com sucesso a partir da LAN, o segundo pacote terá MSS=1460e o terceiro pacote terá Win=65536. E quando enviado, o quarto pacote contém o GETcomando HTTP com meu IP da LAN como origem e assim por diante.
Se eu usar tcpdumpno lado do servidor, recebo o seguinte no cenário problemático (lado WAN) (quebra chamada após connection reseto recebimento):
$ 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 conectar localmente, fica assim; 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
Percebi que o serviço aparentemente é executado apenas em tcp6oposição ao meu servidor ssh; Isso poderia ser a causa? Atualização: aparentemente NÃO como Listen 0.0.0.0:1123fez /etc/apache2/ports.confforce tcp, mas o problema permaneceu ao conectar do lado 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 /var/log/apache2sobre esses eventos usando o seguinte: LogLevel infoe LogLevel debug( LogLevel trace8e a reinicialização do serviço apropriada). Todos os arquivos na pasta mantêm o mesmo carimbo de data antes e depois da falha na conexão, em todos os casos.
Posso estar errado, mas como o Apache fornece tão poucas informações, 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 é o ownCloud.
Alguma idéia de como solucionar isso ainda mais e descobrir o que pode estar errado?
Responder1
Verifique primeiro se as portas estão funcionando bem. Você pode fazer isso com uma ferramenta de verificação de porta, comoesse. Se houver problemas, verifique seu ip novamente porque provavelmente você tem ip dinâmico e mudando em alguns períodos se estiver bom ou o resultado do teste estiver bom, provavelmente em casa você definiu o ip dinâmico. A partir de suas conexões de rede, defina um ip estático para você, comoaqui. E você evita que alguém obtenha o mesmo ip que você reserva nas configurações do modem. Reservar um ip é bastante simples, encontre a configuração de dhcp em seu modem, vamos pegar seu modem em 192.168.1.1 e você definir para si mesmo 192.168.1.2, neste caso, nas configurações de dhcp, digite 192.168.1.3 como ponto de partida, se nenhuma dessas funcionar, entre em contato com seu ISP em alguns países, alguns portos podem não ser autorizados a abrir, por exemplo, estive em Chipre há meio ano e a abertura da porta 80 é proibida lá.
--ATUALIZAR--
Pelo que entendi, como cliente de outro computador você pode se conectar, mas como servidor, quando você tenta se conectar, não consegue ver a página. Este é um problema principal, a menos que você não use roteadores proxy, não é possível rotear solicitações que saem de si mesmo, tente usar um proxy da web, neste caso provavelmente funcionará. Você não pode fazer nada sobre isso, pois o servidor não pode se conectar à sua própria rede sem proxy