web-dev-qa-db-ja.com

apacheは80でリッスンしていますが、他のポートではリッスンしていません

example.com(exampleIP = 1.2.3.4)の動作中のApache構成を変更して、デフォルトのポート80からポート8001に変更し、 http://example.com:8001 が動作するようにしました。 。私はそうすることができませんでした、そして私が試みたことを文書化します。 iptablesのサポートが必要かもしれないと思います。

私の/ etc/hostsは最初は大丈夫です

1.2.3.4    example.com

次の場所でポート80を8001に置き換えることから始めました

  1. /etc/Apache2/ports.conf

    1.2.3.4:8001を聞く

  2. /etc/Apache2/conf.d/virtual.conf

    NameVirtualHost 1.2.3.4:8001

  3. /etc/Apache2/sites-enabled/example.com

    <VirtualHost 1.2.3.4:8001>

          ServerName example.com:8001
          #UPDATE: ServerName example.com doesn't make a difference either
    

    </ VirtualHost>

上記の3つのケースで8001を80に置き換えると、機能します。 8001では接続を確立できません。 tcpdumpは着信要求も表示しません。

再起動時にApacheデーモンがエラーをスローしなかったため、Webサーバーが8001でリッスンしているかどうかを確認しようとしました

$ Sudo lsof -i |grep 8001
Apache2     731     root    3u  IPv4 46858730       TCP example.com:8001 (LISTEN)
Apache2     734 www-data    3u  IPv4 46858730       TCP example.com:8001 (LISTEN)
Apache2     736 www-data    3u  IPv4 46858730       TCP example.com:8001 (LISTEN)
Apache2     737 www-data    3u  IPv4 46858730       TCP example.com:8001 (LISTEN)
Apache2     738 www-data    3u  IPv4 46858730       TCP example.com:8001 (LISTEN)
Apache2     739 www-data    3u  IPv4 46858730       TCP example.com:8001 (LISTEN)

8001でリッスンしているようです。次のiptableルールを端末に適用しようとしました。

$ Sudo iptables -A INPUT -p tcp --dport 8001 -j ACCEPT
$ Sudo iptables -A OUTPUT -p tcp --sport 8001 -j ACCEPT
$ Sudo iptables -A INPUT -m limit --limit 5/min -j LOG --log-prefix "iptables denied:  " --log-level 7

拒否されたログを取得したことはありません。 iptablesの冗長モードが示すものは次のとおりです

$ Sudo iptables -L -v -n
Chain INPUT (policy ACCEPT 3052M packets, 785G bytes)
pkts bytes target     prot opt in     out     source               destination         
   25  1690 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:8001 
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:8001 
   92  6484 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0           limit: avg 5/min burst 5 LOG flags 0 level 7 prefix `iptables denied:  ' 

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 4317M packets, 695G bytes)
 pkts bytes target     prot opt in     out     source               destination         
   20  1760 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp spt:8001 

私はiptableルールに精通していないので、上記で見逃したルールのヒントは素晴らしいでしょう。他のスレッドを読んで、これが理由になるのではないかと思いました。

$ cat /proc/sys/net/ipv4/conf/eth0/forwarding 
0

この情報を考えると、8001では実行されているが80では実行されていないWebサーバーを停止している可能性があることについてのヒントはありますか?

UPDATE 1:すべてのiptableルールをフラッシュしてみました

$ Sudo iptables -X
$ Sudo iptables -F

また、tcpdumpが何かをキャッチしているかどうかを確認しようとしました

 Sudo tcpdump -i eth0 port 8001 -v

8001にはありませんが、ポートを80に変更します(^ 3か所で)。

私は確立されたリスニングプロセスを探してみました

$ netstat -an
tcp        0      1.2.3.4:8001            0.0.0.0:*               LISTEN   

最後に私のローカルマシンから、私もカールを試しました

curl http://1.2.3.4:8001 -v
* About to connect() to 1.2.3.4 port 8001 (#0)
*   Trying 1.2.3.4... No route to Host
* couldn't connect to Host
* Closing connection #0
curl: (7) couldn't connect to Host

UPDATE 2

さらに、iptablesエラーをキャッチする/ etc/log/messagesは、次のようにスローされたようです。しかし、tcpdumpを開始および終了すると、これらが表示されることがわかります。

Jan 22 09:30:31 node1 kernel: device eth0 entered promiscuous mode
Jan 22 09:30:31 node1 kernel: audit(1264152631.798:54): dev=eth0 prom=256 old_prom=0 auid=4294967295
Jan 22 09:30:33 node1 kernel: device eth0 left promiscuous mode

UPDATE 3はtcpdumpのよくある質問でこれを見つけました

...これは、キャプチャしているインターフェイスがスイッチに接続されていることが原因である可能性があります。スイッチドネットワークでは、2つのポート間のユニキャストトラフィックが他のポートに表示されるとは限りません-ブロードキャストトラフィックとマルチキャストトラフィックのみがすべてのポートに送信されます...

...これは、10Mbポートでスニッフィングすると、100Mbポートに送信されるトラフィックが表示されないことを示します。その逆も同様です。 。

...マシンがスイッチドネットワークまたはデュアルスピードハブに接続されていない場合、またはスイッチドネットワークに接続されているが、すべてのトラフィックが複製されるようにポートが設定されている場合、ネットワークインターフェイスに問題がある可能性がありますキャプチャしているが「無差別」モードをサポートしていないか、OSがインターフェイスを無差別モードにできないため...

したがって、この特殊なケースを要約すると:

  • iptablesは-F、-Xでフラッシュされました
  • 1.2.3.4:80でリッスンしているApacheで問題なくリクエスト
  • tcpdumpは、1.2.3.4:8001でリッスンしているApacheでは何もキャッチしません(UPDATE 1,3を参照)。
1
Bosky

ステップ3であなたは言及しました

/etc/Apache2/sites-enabled/example.com

<VirtualHost 1.2.3.4:80> ServerName example.com:8001 ... </VirtualHost>

これは正しくありません。そのはず

<VirtualHost 1.2.3.4:8001> ServerName example.com ... </VirtualHost>

1
proy

気にならない場合は、次の方法でインターフェイスにバインドしてみてください。

Listen 0.0.0.0:8001

また、ServerNameは次のようになります。

ServerName example.com

残りは、すでに構成したままにしておきます。 NameVirtualHostとVirtualHostは同じ署名を持っている必要があることに注意してください。また、これは名前ベースの仮想ホストであるため、ブラウザを使用してマシン上のhostsファイルに次のような行を追加する必要があります。

1.2.3.4 example.com

そして http://example.com:8001/ でブラウザのURLとして使用します(curl、wget、MSIE、Firefox)

デバッグ用:

tshark -V -i eth0 port 8001 or port 80

Error.logとaccess.logで何が起こっているかを確認してください

0

私がホスティングの人々に連絡したとき、それは結局ファイアウォールの問題でした。

これを実施するために実際に何をしたかについて、彼らに詳しく説明させようとします。

結局、素敵なシステム管理者の演習になりました。みんな、ありがとう...

0
Bosky