Apache で稼働している Web サイトがあります。LAN から完全にアクセスできます。
また、サーバーの一部を WAN からアクセスできるように設定しました。最初はうまくいきましたが (間違いなく初心者の幸運)、現在はERR_CONNECTION_RESET一貫してエラーが返されます。考えられるすべての方法を試し、Apache を再インストールしましたが、もうアイデアがありません。
ポート転送は適切に設定されており、 で検証されていますnmap。ローカル スキャンとリモート スキャンの両方でポートが開いていることが示されています。
ルールを再確認しufw、ログを有効にしました。ログには、[UFW ALLOW]ローカルとリモートの両方の着信接続でパケットが取得されたことが示されています。
クライアントから Wireshark キャプチャを実行しました。(失敗した) リモート接続シナリオでは、3 つのパケットのみが交換されます。
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 からの接続に成功した場合、2 番目のパケットには が含まれMSS=1460、3 番目のパケットには が含まれることです。また、送信されると、4 番目のパケットには、送信元として自分の LAN IP を使用したWin=65536HTTP コマンドが含まれます。GET
tcpdumpサーバー側で使用すると、問題のある (WAN 側) シナリオで次のようになります (connection reset受信後に break が呼び出されます)。
$ 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
ローカルに接続すると、次のようになります。3 番目のパケットのウィンドウ サイズが異なることに注意してください。
$ 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ではなく、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 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 と入力します。これらのいずれも機能しない場合は、ISP に問い合わせてください。一部の国では一部のポートを開くことが許可されていない場合があります。たとえば、半年前にキプロスにいましたが、そこではポート 80 を開くことが禁止されていました。
- アップデート -
私の理解では、別のコンピュータからクライアントとして接続することはできますが、サーバーとして接続しようとするとページを表示できません。これが主な問題です。プロキシを使用しないと、ルーターは自分自身から自分自身に送信されるリクエストをルーティングできません。Web プロキシを使用してみてください。この場合はおそらくうまくいくでしょう。サーバーとしてこれについて何もできません。プロキシなしでは自分のネットワークに接続することはできません。