Tengo sitios web en funcionamiento que se ejecutan en Apache. Son perfectamente accesibles desde la LAN.
También configuré parte del servidor para que sea accesible desde WAN. Esto funcionó al principio (suerte del principiante, sin duda), pero ahora ERR_CONNECTION_RESETse devuelve constantemente. He explorado todas las vías que se me ocurrieron, incluso reinstalé Apache, y ahora se me acabaron las ideas.
El reenvío de puertos está configurado correctamente y verificado con nmap. Tanto el escaneo local como el remoto muestran que mi puerto está abierto.
Verifiqué dos veces mi ufwregla y habilité el registro. El registro muestra que los paquetes llegan [UFW ALLOW]tanto para conexiones entrantes locales como remotas.
He ejecutado capturas de Wireshark desde el cliente. Sólo se intercambian tres paquetes en el escenario de conexión remota (fallida):
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
Las diferencias significativas son que cuando se conecta exitosamente desde LAN, el segundo paquete tendrá MSS=1460y el tercer paquete tendrá Win=65536. Y cuando se envía, el cuarto paquete contiene el GETcomando HTTP con la IP de mi LAN como origen, y así sucesivamente.
Si lo uso tcpdumpen el lado del servidor, obtengo lo siguiente en el escenario problemático (lado WAN) (se llamó a la interrupción después de connection resetrecibirse):
$ 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
Cuando se conecta localmente, se ve así; tenga en cuenta el tamaño de ventana diferente en el tercer paquete:
$ 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
He notado que el servicio aparentemente se ejecuta solo con tcp6mi servidor ssh; ¿Podria ser esta la causa? Actualización: aparentemente NO como Listen 0.0.0.0:1123lo /etc/apache2/ports.confhizo Force tcp, pero el problema persistió al conectarse desde el 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
No he podido capturar nada /var/log/apache2sobre estos eventos usando lo siguiente: LogLevel infoy LogLevel debug( LogLevel trace8y el reinicio del servicio apropiado). Todos los archivos de la carpeta mantienen la misma marca de fecha antes y después de la conexión fallida, en todos los casos.
Puede que me equivoque, pero como Apache proporciona tan poca información, ahora me pregunto si esto podría estar relacionado con un problema de SQL o PHP con enlaces externos, pero en realidad no tengo ninguna experiencia con ellos. El servicio en cuestión aquí es ownCloud.
¿Alguna idea sobre cómo solucionar este problema y descubrir qué podría estar mal?
Respuesta1
En primer lugar, compruebe si los puertos funcionan bien. Puede hacer esto con una herramienta de escaneo de puertos comoeste. Si hay problemas, verifique su IP nuevamente porque probablemente tenga una IP dinámica y cambie por algunos períodos si está bien o el resultado de la prueba está bien, probablemente en casa configuró una IP dinámica. Desde sus conexiones de red, configure una IP estática para usted comoaquí. Y evita que alguien obtenga la misma IP que usted reserva en la configuración del módem. Reservar una IP es bastante simple: busque la configuración de dhcp en su módem. Supongamos que su módem está en 192.168.1.1 y usted mismo configuró 192.168.1.2. En este caso, en la configuración de dhcp, escriba 192.168.1.3 como punto de inicio. Si ninguno de estos funciona, comuníquese con su ISP. en algunos países es posible que no se permita la apertura de algunos puertos, por ejemplo, estuve en Chipre hace medio año y la apertura del puerto 80 está prohibida allí.
--ACTUALIZAR--
Según tengo entendido, como cliente desde otra computadora puede conectarse, pero como servidor, cuando intenta conectarse, no puede ver la página. Este es un problema principal, a menos que no use enrutadores proxy, no puede enrutar solicitudes que salen de sí mismo. Intente usar un proxy web, en este caso probablemente funcionará. No puede hacer nada al respecto ya que el servidor no puede conectarse a su propia red sin proxy