前書き#
この記事を書こうと思ったとき、どこかがおかしいと感じました。なぜ私が xlog で書いた記事はすべて日本のネットワークに関するものなのでしょうか？
実際、私はコンピューターネットワークの基礎には詳しくありません。これは私の知識領域の中で非常に弱い部分です。日本のサイトやネットワークビジネスは、私ができることですが、それは非常に上位のアプリケーションであり、私は実際には得意ではありません。
しかし、これは原因でもあり結果でもあります。私が得意ではないため、私は「まれな」問題に直面することがあり、この問題は実際には誰にとっても問題ではありません。
これは一種の非快適領域の逆説です。
nat ループバック#
nat ループバック、または hairpinning とも呼ばれます。これは非常に単純な問題を解決します... つまり、nat のループバックです！
あなたのパブリック IPv4 が 1.2.3.4 であり、ポートフォワードを設定して、1.2.3.4:1000 から 192.168.1.2:1000 に転送しているとします。そして、（1 つの）ルーターの IP アドレスが 192.168.1.1 であるとします。もしもあなたが内部ネットワークにいる場合、/24 を例にすると、あなたのネットワークの IP アドレスは 192.168.1.200 です。この場合、1.2.3.4:1000 にアクセスしようとすると問題が発生します。
通常、ルーターのポートフォワードは、背後の iptable と対応しており、外部（WAN 側）から内部（LAN）側に転送されます。言い換えれば、WAN 側でリッスンし、任意の（外部の）IP からポート 1000 へのリクエストをすべて 192.168.1.2:1000 に転送します。
対応するルールは次のとおりです。
-A zone_wan_prerouting -p tcp -m tcp --dport 1000 -j DNAT --to-destination 192.168.1.2:1000
では問題です、もしもあなたが外部ネットワークではなく内部ネットワークにいて、1.2.3.4:1000 にアクセスしようとした場合、どうなるでしょうか？（ただし、実際には多くの場合、この追加の設定はデフォルトで存在します）この dnat ルールだけでは通信できません。なぜなら、入口チェーンが WAN 側に制限されているからです。
nat ループバック？#
では、この問題は一体何の問題なのでしょうか？nat ループバック？
もしこの問題を知らなければ、この問題を提起することはできません。
幸いにも、技術は私たちに新しいものをもたらしてくれました。今日では、私たちは直接 chatgpt に質問することで、私たちの問題が何であるかを知ることができます。
問題を尋ねるのではなく、問題が何であるかを尋ねる。Ask what the question is, instead of how to solve it.
これは私が chatgpt を典型的に使用する方法です。広範な技術分野では、従来のクエリと技術学習の方法では、空中楼閣で何かをするためには運が必要です。ABCEFG の 6 つの技術を習得しても、それらを結びつけることはできず、以前は試行錯誤 / 蓄積 HIGK をするしかありませんでしたが、実際に不足していたのは D でした。大規模モデルの生産性は実際には非常に限られており、彼女はまだ多くの未知のことをすることができませんが、このシナリオは非常に典型的です。
nat ループバック！#
実際のところ、現代のルーターシステムでは、nat ループバックは既に考慮されています。
openwrt では、その背後にある設計は reflection です。
次のようなルールが得られます。
-A zone_lan_prerouting -s 192.168.1.0/24 -d 192.168.0.3/32 -p tcp -m tcp --dport 1000 -m comment --comment "!fw3: 1000 (reflection)" -j DNAT --to-destination 192.168.1.2:1000
タイトルの注意書きに注意してください。ブリッジ環境ではないため、ここでの openwrt の WAN 環境の IP アドレスは 192.168.0.3 です。
リンク#
問題！#
ブリッジ環境では、openwrt は pppoe ダイヤルアップを直接行っても nat ループバックは失敗しません。ただし、ブリッジ環境ではない場合、つまり、光モデムルーターモードの場合は失敗します。
問題は、openwrt の nat ループバックが実際には断続的に問題が発生していることであり、バージョンの断片化と組み合わさると、インターネットの騒音の中で自分のエラーがどれなのかを見つけるのは非常に困難です。
これにより、問題が多く、答えも多くなりますが、みんなのプラグが互換性がないという状況が生まれます。
さまざまな方法が見つかります。たとえば、特定のバージョンの openwrt のバグや、どのカーネルフラグを設定する必要があるかなど、さまざまな「正しい」方法があります。しかし、それらはあなたの問題に答えることはできません。
この問題は、大規模モデルでも解決できません。解決できないどころか、彼女はこの問題に関しては非常に巧妙になることができます。
彼女が最も得意とすることは、草の根台を築くことです。
問題の根本的な原因は、このルールが 192.168.0.3 を入口として設定しているだけであり、実際の入口はパブリック WAN も含まれるべきだということです。
-A zone_lan_prerouting -s 192.168.1.0/24 -d 192.168.0.3/32 -p tcp -m tcp --dport 1000 -m comment --comment "!fw3: 1000 (reflection)" -j DNAT --to-destination 192.168.1.2:1000
つまり、LAN 側からパブリック IP にアクセスする場合、直接目的のホストに転送する必要があります。
しかし、これでは優雅ではありませんね。
完了#
IP=$(curl -s 4.ipw.cn | grep -oE '\b[0-9]{1,3}(\.[0-9]{1,3}){3}\b' | head -n 1)
iptables -t nat -A PREROUTING -s 192.168.1.0/24 -d $IP/32 -p tcp -m tcp --dport 1000 -j zone_wan_prerouting
したがって、カスタムのファイアウォールルールを直接追加することができます。nft を使用する場合、大規模モデルがお手伝いします。実際、これらの 2 行も chatgpt が書いたものです。
パブリック IP を取得した後、リクエストをzone_wan_preroutingに戻すだけで十分であり、目的のホストを再度書く必要はありません。
実際には、より簡略化 / 汎用化することもできますが、これにより openwrt の uci にバインドされるため、padavan もあります。
LAN=$(uci show network.lan.ipaddr | cut -d"'" -f2)
IP=$(curl -s 4.ipw.cn | grep -oE '\b[0-9]{1,3}(\.[0-9]{1,3}){3}\b' | head -n 1)
iptables -t nat -A PREROUTING -s $LAN/24 -d $IP/32 -p tcp -m tcp --dport 1000 -j zone_wan_prerouting
padavan では、より優れた方法で処理されており、reflection ではなく次のようになります。
-A PREROUTING -d 1.2.3.4/32 -j vserver
-A PREROUTING -d 192.168.0.1/32 -j vserver
vserverを外部入力チェーンとして定義しています。