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. 그리고 전송되면 네 번째 패킷에는 내 LAN IP를 소스로 하는 HTTP GET명령 등이 포함됩니다.
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 서버가 아닌 다른 환경 에서만 실행되는 것으로 나타났습니다 . 이것이 원인이 아닐까? 업데이트: 분명히 force Listen 0.0.0.0:1123와는 다르지만 WAN 측에서 연결할 때 문제가 남아 있습니다./etc/apache2/ports.conftcp
$ 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 infoLogLevel debugLogLevel 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을 시작점으로 설정합니다. 이러한 작업이 ISP에 연결되지 않으면 시작점으로 사용됩니다. 일부 국가에서는 일부 포트를 열 수 없습니다. 예를 들어 저는 반년 전에 키프로스에 있었고 그곳에서는 포트 80을 여는 것이 금지되어 있습니다.
--업데이트--
다른 컴퓨터의 클라이언트로 연결할 수는 있지만 연결을 시도하면 서버로 페이지를 볼 수 없다는 것을 알고 있습니다. 이것은 프록시 라우터를 사용하지 않는 한 주요 문제입니다. 자체에서 자체로 나가는 요청을 라우팅할 수 없습니다. 이 경우 웹 프록시를 사용하려고 하면 아마도 작동할 것입니다. 프록시 없이는 서버가 자신의 네트워크에 연결할 수 없기 때문에 이에 대해 아무것도 할 수 없습니다