VPNの背後にあるサービスに ufw allow 443 は効かなかった

VPNクライアントからpingは通るのに、TCPサービスはタイムアウトし、ufw allow 443/tcpを実行しても何も変わりません。アプリケーションがゲートウェイ自身ではなくゲートウェイの背後のホストで動いているなら、その許可は間違った通信経路に対して書かれたものです。パケットはファイアウォール宛てではなく、ローカルプロセスにも渡らないため、入力ルールは決してそれを見ません。修正は転送フローを狙った経路ルールであり、その証拠はすでにログにあります。

宛先がローカルか転送かを判断する

カーネルが見るままにパケットを読みます。ゲートウェイ上のサービスへ届けられる通信はローカル入力です。ゲートウェイが別のホストへ転送する通信は転送であり、UFWは二つの経路に対して別々のルールセットを持ちます。区別を決めるのは宛先アドレスと経路検索であり、パケットが到着したインターフェースではありません。

INとOUTの両フィールドに同じインターフェースを表示するログ行でも、一つの機器からクライアントを出し入れするトンネルはまさにそう見えるため、ルーティングされたパケットを表していることがあります。インターフェース名よりも宛先アドレスのほうが速くこの問題を決めます。同じ名前を二度見てもローカル配送の証明にはならず、配備が一度も作らなかったトンネルインターフェースをでっち上げても助けになりません。

ルールを追加する前にブロックを読む

許可された接続試行を一つ再現し、その送信元、宛先、プロトコル、宛先ポートをゲートウェイが記録したとおりに捕捉します。これら四つの値をログの項目とサービスの実際の場所と比較します。以前のpingの成功は、その交換自体が許可されていたことしか証明せず、ファイアウォールはアプリケーション宛てのTCP SYNをまったく別に扱うことがあります。

sudo dmesg | grep "UFW BLOCK" | tail -n 5
sudo ufw status numbered

最初のコマンドは判定をそのフィールドとともに返し、二番目は何がすでに読み込まれ、どの順序かを示します。あなたのルールより上にある以前の拒否が、欠けているルールがなくても同じ症状を説明するので、何かを編集する前に両方を読んでください。

当てはまる最も狭い経路ルールを書く

この例ではクライアントは172.20.8.0/24からtun0に到着し、サービスは10.30.0.15の8443番ポートで待ち受け、ゲートウェイはens5から出ます。これらの値は、クラウドVPCの既定である10.0.0.0/16や家庭の192.168.0.0/16とはまったく似ないように選ばれており、8443は例をゲートウェイ自身の443リスナーから遠ざけます。

sudo ufw --dry-run route allow in on tun0 out on ens5 proto tcp from 172.20.8.0/24 to 10.30.0.15 port 8443

ドライランは結果として生じるルールセットを出力し、あなたのルールが既存の拒否の前に入るか後に入るかを見る最も安い方法です。インターフェース名と内側のアドレスは例ではなく配備に対して確認し、宛先NATが先に実行される場合フィルタは変換後の宛先を見ることを覚えておいてください。

戻り経路はステートフルに保つ

UFWは許可された接続を追跡するので、許可された転送フローへの応答は明示的な逆方向ルールなしで受け入れられます。物事を動かすために逆方向へ無制限のルールを加えるとポリシーは一つのサービスをはるかに超えて広がり、通常の要求と応答の交換には不要です。戻り経路は暗黙のまま、ルールセットは読みやすく保ちます。

ドライランが意図と一致してから初めてルールを適用し、順序付きリストが期待した位置にそれを示すことを確認します。VPNリスナーと管理ルールは別の問題として保ち、それらを変えるのは一つのアプリケーションを通すこととは別の判断です。トポロジーが書かれているのと同じ場所に変更を記録し、次のエンジニアがパケットキャプチャから再発見しなくて済むようにします。

sudo ufw route allow in on tun0 out on ens5 proto tcp from 172.20.8.0/24 to 10.30.0.15 port 8443
sudo ufw status numbered

UFWが代わりに強制できないことを確認する

正しいルールでも、カーネルの転送とサービスに届く経路が依然として必要です。ファイアウォールを二度目に責める前に両方を確認してください。

sysctl net.ipv4.ip_forward
ip route get 10.30.0.15

次にホストの外を見ます。クラウドインスタンスでは、ゲストのUFWポリシーはセキュリティグループ、サブネットACL、プロバイダー自身の転送設定を置き換えないため、ローカルのブロックは一つの層についての証拠であり、他のすべての層がサービスを許可している証拠ではありません。

ファイアウォールを有効にしたまま、許可された送信元からと無関係な送信元からの新しい接続を試して終わります。UFWを無効にすると同じコマンドで症状が消え証拠も壊れるので、それは最初ではなく最後の実験であるべきです。