☰

Webサーバーは、nftablesポート転送のパブリックIPアドレスを介して独自にアクセスできません。

tag-icon • tag-icon port-forwarding nftables wireguard
Webサーバーは、nftablesポート転送のパブリックIPアドレスを介して独自にアクセスできません。

エッジルーターとしてWireGuardサーバーがあります。すべてのhttpトラフィックを自分のWebサーバーに転送します。すべてがうまくいきますが、問題があります。 Web サーバーは WireGuard パブリック IP アドレスを介して独自に接続できません。 WebサーバーコンピュータでWebブラウザを使用してWebサイトにアクセスすることはできません。

NATベースがこの問題を解決できることがわかりましたが、daddrIPアドレスは異なる場合がありますが、固定される可能性があるため、より良い方法があるかどうかを知りたいですiif。私のNetgear WiFiルーターは、これらの問題なしにポート転送を実行できます。しかし、内部ルールを確認できず、daddrNATベースを使用していないようです。

これは次の構成です。WireGuardサーバー。

ワークグループ0

interface: wg0
  Address = 10.0.0.1/24
  public key: (hidden)
  private key: (hidden)
  listening port: 51820
peer: (hidden)
  endpoint: (hidden):51820
  allowed ips: 10.0.0.2/32
  latest handshake: 56 seconds ago
  transfer: 20.69 MiB received, 115.85 MiB sent

nftables

table ip firewall {
    chain input {
        type filter hook input priority filter; policy drop;
        ct state established,related accept
        udp dport {51820} accept
        tcp dport {22} accept
        ip saddr 10.0.0.0/24 accept
    }
    chain prerouting {
        type nat hook prerouting priority dstnat;
        iif eth0 tcp dport {80,443} dnat to 10.0.0.2
    }
    chain postrouting {
        type nat hook postrouting priority srcnat;
        ip saddr 10.0.0.0/24 masquerade
    }
    chain forward {
        type filter hook forward priority filter; policy drop;
        ct state established,related accept
        ct status dnat accept
        ip saddr 10.0.0.0/24 accept
    }
}

これは次の構成です。ネットワークサーバー。

ワークグループ0

interface: wg0
  Address = 10.0.0.2/24
  public key: (hidden)
  private key: (hidden)
  listening port: 51820
  fwmark: 0xca6c
peer: (hidden)
  endpoint: (hidden):51820
  allowed ips: 0.0.0.0/0
  latest handshake: 25 seconds ago
  transfer: 114.69 MiB received, 3.56 MiB sent
  persistent keepalive: every 25 seconds

ベストアンサー1

これは事件ですNATループバック扱う。

現在、WireGuardサーバー（「WGS」）は以下でのみ利用可能です。イーサネット0したがって、受信したトラフィックには何も起こりません。ワークグループ0。

Onでは、独自のパブリックIPアドレスに対してWGS受信トラフィックをポート80,443にリダイレクトする必要があります。しかし、質問があります。ルールがこのローカル宛先IPアドレスを知らずにパケットがローカルに分類されると、事前ルーティング段階でどのように推測できますか？この分類は、まだ発生していないルーティング決定フェーズで発生します。 （これを見てください。模式図パケットライフサイクルのさまざまなステップの概要を確認してください。

以下を使用して、パケットパスでカーネルがパケットをどのようにルーティングするかを動的に尋ねることができます。nftables'fib式（必須カーネル >= 4.10):

FIB発現

fib {saddr | daddr | mark | iif | oif} [. ...] {oif | oifname | type}

ㅏ嘘をつく式クエリ嘘をつく（配信情報ベース）特定のアドレスが使用する出力インターフェイスインデックスなどの情報を取得します。入力は、入力として使用される要素のタプルです。嘘をつく機能を見つけてください。

これはルーティングステップの前に実行でき、パケットが次の場合にのみリダイレクトを実行するために使用されます。暫定的にローカル宛先として分類：WGSに属するアドレス。これだからな事前ルーティング、実際のルーティング決定が行われると、もはやローカルパケットに分類されず、ルーティングされたパケット（送信者に再送信）として分類されます。

受信したトラフィックのリダイレクトワークグループ0（したがってWebサーバー（「WS」）から）WGSに属するすべてのアドレスに：

nft add rule ip firewall prerouting iif wg0 tcp dport '{ 80, 443 }' fib daddr type local dnat to 10.0.0.2

これは、WGSにローカルですが、必要に応じて存在しない宛先にさらにフィルタリングできます（たとえば、WGSのwg0アドレスでのみ待機している個人管理インターフェイスにアクセスできます）。ワークグループ010.0.0.1 は、以下を使用して一致します。

nft add rule ip firewall prerouting iif wg0 daddr != 10.0.0.1 tcp dport '{ 80, 443 }' fib daddr type local dnat to 10.0.0.2

nat/postroutingチェーンはすでに10.0.0.0/24ソース範囲内のすべてのアイテムを偽装しているため、追加の手順は必要ありません。 WSのソースアドレスはwg0のWGSアドレスに置き換えられます。 NATループバックにはソース変更が必要です（WSは独自のIPアドレスからパケットを受け入れることはできません）。

オプションで、この偽装ルールの前に専用ルールを挿入して別のIPアドレスを選択できます。スナット交換。 WSがWGSを介してルーティングされる限り、WGSがローカルであるかどうかにかかわらず、すべてのアドレス（生成されたソース10.0.0.1を除く）が可能です。次の例では、WS および WGS のルーティング テーブルが提供されていないため、正確ではない可能性があります。 WSの独自の10.0.0.2を置き換えるために存在しない10.0.1.2アドレスを選択すると、WSの独自のログは自分で要求を簡単に識別できます。

nft insert ip firewall postrouting ip saddr 10.0.0.2 ip daddr 10.0.0.2 snat to 10.0.1.2

それとも保守的です：

nft insert ip firewall postrouting ip saddr 10.0.0.2 ip daddr 10.0.0.2 tcp dport '{ 80, 443 }' ct status dnat oif wg0 snat to 10.0.1.2

おすすめ記事