☰

iptables/https: ルータはポート 443 から着信トラフィックを取得します。

tag-icon • tag-icon iptables nginx https
iptables/https: ルータはポート 443 から着信トラフィックを取得します。

私はこれがnginx / httpsの問題だと思いますが、iptables私が誤解することに関連している可能性があります。

私は最近、Webサーバー（nginx）とインターネットの間のルーターにファイアウォールを設定しました。 Nginxはポート80と443でリッスンするように設定されており、Let's encrypt証明書を使用してほとんどの80通話を443にリダイレクトします。適切な配信を使用すると、すべてがうまく機能します。少なくともまだ何の欠陥も見つかっていません。

ファイアウォール（iptablesフィルタテーブル）はACCEPTポリシーに設定されていますが、パケットがチェーンの終わりに達すると、それを記録して破棄するチェーンINPUTに転送されます。LOGDROP

ログを確認したところ、サーバーポート443でルーターに送信されたパケットが破棄されたことがわかりました。はい（MACとIPアドレスのランダム化、.136はいサーバー、.122はいルーター）：

Oct 10 05:18:47 ASUS user.warn kernel: IPTables-Dropped: IN=br0 OUT= MAC=3C:AE:78:D4:B1:E3 SRC=192.168.1.136 DST=192.168.1.122 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=10743 DF PROTO=TCP SPT=443 DPT=33272 WINDOW=0 RES=0x00 RST URGP=0

このような試みは夜の間に半定期的に（10分ごとに1～3回試み）現れて消えます。

ログが正しく解釈されたと仮定すると、サーバーはhttpsポートから直接ルーターに接続します。これは言葉ではありません。ルーターに暗号化されているか暗号化されていないWebコンテンツが必要なのはなぜですか？聞かずにもらえると思いますか？

FORWARDhttpsコンテンツの外部要求がチェーンを双方向に通過するため、ここに表示されないとします。私が言ったように、AFAICTサーバーへのすべてのhttpsリクエストは期待どおりに応答されます。

私の質問は次のとおりです

このパケットの可能な説明は何ですか？奇妙なサーバーティックのため、nginxは要求せずにパケットを送信しますか？それともどこかのコンピュータから要求を受け取って誤って応答しますか？

答え1

提供されるログメッセージの例は、RST宛先ポートでリッスンしているエントリがない場合に通常カーネルから送信されるパケットです。

Oct 10 05:18:47 ASUS user.warn kernel: IPTables-Dropped:
    IN=br0 OUT= MAC=3C:AE:78:D4:B1:E3 SRC=192.168.1.136 DST=192.168.1.122
    LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=10743 DF PROTO=TCP SPT=443 DPT=33272
    WINDOW=0 RES=0x00 RST URGP=0

具体的には、192.168.1.122から192.168.1.136:443までの以前の要求がありました。 （または192.168にファイアウォールがあります。）1.136には、対応するREJECTアドレス/ポートの組み合わせに関する規則があります。このレベルでは違いがわかりません。 )

残念ながら、これは.122のルーターが.136のnginxと通信しようとする理由を説明していませんが、ログファイルメッセージをより簡単に解釈するのに役立ちます。

関連情報