ローカルネットワークから転送されたパブリックIPアドレスへのループバック-ヘアピンNAT
これは 標準的な質問 ヘアピンについてNAT（ループバックNAT））です。
この質問の一般的な形式は次のとおりです。
クライアント、サーバー、およびNATルーターのネットワークがあります。ルーターにはサーバーへのポート転送があり、一部のサービスは外部で利用できます。外部を指すDNSがあります。 IP。ローカルネットワーククライアントは接続に失敗しますが、外部の作業はします。
- なぜこれが失敗するのですか？
- 統一された名前付けスキーム（ローカルと外部の両方で機能するDNS名）を作成するにはどうすればよいですか？
この質問には、他の複数の質問からマージされた回答があります。彼らは当初、FreeBSD、D-Link、Microtik、およびその他の機器を参照していました。彼らはすべて同じ問題を解決しようとしています。
お探しのものが「ヘアピンNAT」です。外部インターフェイスに割り当てられたIPアドレスに対する内部インターフェイスからの要求は、外部側インターフェイスから着信したかのようにNAT処理する必要があります。
FreeBSDの知識はまったくありませんが、OpenBSDの「pf」マニュアル（ http://www.openbsd.org/faq/pf/rdr.html ）を読んで、 DMZネットワーク、またはTCPプロキシを使用するスプリットホライズンDNSは、「pf」がヘアピンNATをサポートしていないと私に思わせました。
私は、スプリットホライズンDNSのルートをたどり、内部でURLのIPアドレスを使用するのではなく、名前を使用することを検討します。
これはヘアピンNATに関する正規の質問になるように昇格されたので、おそらく現在受け入れられているものよりも一般的に有効な答えがあるはずだと思いました。 FreeBSD。
この質問は、RFC1918でアドレス指定されたIPv4ネットワーク上のサーバーによって提供されるサービスに適用されます。これは、ゲートウェイで宛先NAT（DNAT））を導入することにより、外部ユーザーが利用できるようになります。内部ユーザーは、これらのサービスにアクセスしようとします外部アドレスを介して送信されます。パケットはクライアントからゲートウェイデバイスに送信され、宛先デバイスのアドレスが書き換えられてすぐに内部ネットワークに送り返されます。ゲートウェイでパケットが発生するこの急激な方向転換により、名前ヘアピンNATヘアピンターン との類推。
この問題は、ゲートウェイデバイスが送信元アドレスではなく宛先アドレスを書き換えたときに発生します。次に、サーバーは内部宛先アドレス（自身のアドレス）と内部送信元アドレス（クライアントのアドレス）を含むパケットを受信します。そのようなアドレスに直接返信できることを知っているので、そうします。その応答は直接的なものであるため、ゲートウェイを経由しないため、戻りの送信元アドレスを書き換えて、最初のパケットに対するインバウンド宛先NATの影響のバランスをとる機会は決してありません。パケット。
したがって、クライアントはexternal IPアドレスにパケットを送信しますが、-internal IPアドレスから応答を取得します。 2つのパケットが同じ会話の一部であることはわからないため、会話は行われません。
解決策はこのような宛先NATを必要とし、内部ネットワークからゲートウェイに到達するパケットの場合であり、インバウンドパケットでソースNAT（SNAT）も実行する、通常は送信元アドレスをゲートウェイのアドレスに書き換えます。サーバーは、クライアントがゲートウェイ自体であると見なし、それに直接応答します。これにより、ゲートウェイはDNATとSNATの両方の影響のバランスをとる機会が得られます戻りパケットの送信元アドレスと宛先アドレスの両方を書き換えることにより、受信パケット。
クライアントは、外部サーバーと通信していると考えています。サーバーは、ゲートウェイデバイスと通信していると考えています。すべてのパーティーは幸せです。この時点で図が役に立ちます。
一部のコンシューマゲートウェイデバイスは、2番目のNATステップが必要なパケットを認識するのに十分な明るさであり、ヘアピンですぐに機能する可能性がありますNATシナリオ。他のものは機能しておらず、機能しない可能性があり、機能する可能性は低いです。サーバー障害のトピックではない、どのコンシューマーグレードのデバイスであるかについての議論。
適切なネットワーキングデバイスは、通常、動作するように指示できますが、管理者を推測することはできないため、そうするように指示する必要があります。 Linuxはiptablesを使用してDNATを実行します。
iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to-destination 192.168.3.11
これにより、192.168.3.11の内部サーバーへのHTTPポートの単純なDNATが有効になります。ただし、ヘアピンNATを有効にするには、次のようなルールも必要です。
iptables -t nat -A POSTROUTING -d 192.168.3.11 -p tcp --dport 80 -j MASQUERADE
このようなルールは、適切に機能するために、関連するチェーンの適切な場所にある必要があることに注意してください。filterチェーンの設定によっては、NATされたトラフィックが流れるように追加のルールが必要になる場合があります。このような議論はすべて、この回答の範囲外です。
しかし、他の人が言ったように、ヘアピンを適切に有効にするNAT=は、問題を処理する最良の方法ではありません。最良の方法は、split-horizon DNS、内部ユーザーと外部ユーザーに異なる物理サーバーを使用するか、DNSサーバーを要求しているクライアントのアドレス。
ここでの問題は、ルーターがNAT内部クライアントのアドレスでないことです。したがって、TCPハンドシェイクは失敗します。
以下のIPを想定します
- クライアント：192.168.1.3
- サーバー：192.168.1.2
- ルーター内部：192.168.1
- 外部ルーター：123.123.123.1
これが起こっていることです：
- クライアント（192.168.1.3）がTCP-SYNを外部IP、ポート80（123.123.123.1:80）に送信します
- ルーターはポート転送ルールを確認し、ソースIP（192.168.1.3）を変更せずにパケットをサーバー（192.168.1.2:80）に転送します。
- クライアントは外部IPからのSYN-ACKを待ちます
- 同じサブネット上にあるため、サーバーは彼の回答をクライアントに直接送信します。 NATを逆にするルーターにパケットを送信しません。
- クライアントは、123.123.123.1ではなく192.168.1.2からSYN-ACKを受信します。そしてそれを破棄します。
- クライアントは引き続き123.123.123.1からのSYN-ACKを待機し、タイムアウトします。
どこでもIPアドレスをハードコーディングする代わりにスプリットホライズンDNSを使用しないのはなぜですか？ ext.yourdomainが外側で217.x.x.xを指し、次に内側で192.x.x.xを指します。
元のD-Linkルーター（つまり、Virgin MediaのリビジョンD /ファームウェアバージョン1.00VGではない）の場合は、これを回避するために設定を調整できるはずです。 （しかし、私は他の多くの理由でDD-WRTの前のポスターの提案に同意します！）
- ルーターのウェブインターフェースにログインします。
- 上部の[詳細]タブをクリックします
- 左側の「ファイアウォール設定」タブをクリックします
- 次に示すように、TCPエンドポイントフィルタリングの下にあるEndpoint Independentラジオボタンをクリックします。下のスクリーンショット（またはD-LinkのWebサイトで ルーターエミュレーター を参照）
- 変更内容を保存;あなたは終わった
このスクリーンショットはRev. Cモデルのものです。あなたのものは少し異なる場合があります。
最近同様の質問に回答しました： Cisco static NAT LAN側では機能しません そして、これは正規の質問であることがわかりました。ここでソリューションを要約します。
まず、NAT（可能な場合）について忘れる）-NATの構成についての質問はまったくありません。NATの後ろに配置されたサーバーへのアクセスについてですインターネットとLANの両方です。2つのDNSゾーンを使用することは、実行可能な代替手段ですが、常に解決策とは限りません。しかし、解決策は存在し、信じられないほど単純です（おそらく完璧ではありません）。
（1）サーバー上：255.255.255.255マスクを使用して、サーバーのネットワークインターフェイスにセカンダリIPアドレスとしてパブリックIPアドレスを追加します（Webサービスまたはサーバー上で必要なものは、このIPアドレスでもリッスンする必要があります）;最新のすべてのオペレーティングシステムでこれを行うことができます（または、プライマリIPにセカンダリIPを追加する代わりに、パブリックIPアドレスが割り当てられたループバックインターフェイスを使用できます）。
（2）LANホスト：パブリックIPアドレスのホストルートを追加します。たとえば、Windowsホストの場合は、次のコマンドを使用します：route -p add 203.0.113.130 mask 255.255.255.255 192.168 .1.11（DHCPの「静的ルート」オプションを使用してルートを配布することもできます）。または、クライアントとインターネットに接続するルーターの間にL3スイッチ/ルーターがある場合は、この（これらの）中間スイッチ/ルーターにホストルートを構成します。クライアントで。
TCPスリーウェイハンドシェイク：提案された構成では問題なく動作します。
フィードバックを提供してください（少なくとも投票）。
技術的な観点から見ると、この問題の最善の解決策は、ネットワークでIPv6を有効にすることです。 IPv6が有効になっている場合は、ドメインのAAAAレコードを作成する必要があります。 ルーターの外部IPv4を指す既存のAレコードを保持します。 serverのIPv6アドレスを指すAAAAレコードを作成します。
IPv6にはNATを回避するのに十分なアドレスがあるので、ヘアピンは必要ありませんNAT。IPv6を有効にしてAAAAレコードを作成すると、サポートするクライアントがサポートされます RFC 8305 IPv4の前にIPv6を試行します。これは、クライアントが使用しないため、ヘアピンNAT IPv4の場合も必要ないことを意味します。
世界の大部分がIPv6も有効にするまで、既存のIPv4 NAT発信接続と着信接続のポート転送が必要です。
それも同様に高速です。
IPv6を使用すると、ヘアピンNATよりもパフォーマンスが向上します。
ヘアピンNAT=を使用すると、クライアントはスイッチを介してルーターにパケットを送信し、ルーターは2ラウンドの変換を実行し、最後にスイッチを介してサーバーにパケットを送信します。サーバーからのパケットクライアントへのパスは、そのパス全体を逆に通過します。
IPv6では、NATを回避し、代わりにパケットがクライアントとサーバー間のスイッチを介して直接送信されます。つまり、ラウンドトリップでは、スイッチを通過するパスの数を4から2に減らし、ルーターを介した2つのトリップとルーターが実行する4つの変換を回避します。これにより、パフォーマンスが向上します。
これは、ルーターと同じボックスに組み込まれたスイッチを使用する場合にも当てはまります。
ISPにIPv6がない場合はどうなりますか？
IPv6をサポートしないISPを使用している場合、そのネットワークでサーバーをホストする必要があるかどうかを質問します。これらは、ISPが現在IPv6をサポートしていない場合の対処法に関する私の提案です。
まず、ISPにIPv6が必要であることを伝えます。また、IPv6プロトコルが20年前から存在しているため、IPv6プロトコルをサポートするのがかなり遅れていることを思い出させるかもしれません。 ISPが真剣にあなたを連れて行くのにそれが十分でないならば、他のISPを探し始めます。
IPv6対応のISPを見つけた場合、移行期間中は両方のISPで実行できます。新しいISPに接続されているルーターでは、LAN側でIPv4を無効にしてから、両方のルーターのLAN側を同じスイッチに接続できます。 IPv4とIPv6は2つの独立したプロトコルであるため、これらの接続が異なるルーターを経由しても問題はありません。副次的な利点として、接続の1つが停止した場合にある程度の冗長性が得られます。
IPv6対応のISPが見つからない場合は、サーバーをホスティング施設に移動することを検討してください。ホスティング施設内のサーバーを使用すると、地理的な場所への依存度が低くなるため、プロバイダー間の競争が激化し、ニーズを満たすプロバイダーを確保するのに役立ちます。
サーバーをホスティングファシリティに移動しても、クライアントにIPv6は付与されませんが、サーバーを移動すると、ヘアピンNATにアクセスする必要がなくなります。
してはいけないこと
IPv6トラフィックをルーティングする方法がない場合は、IPv6をオンにしてAAAAレコードを作成しないでください。 ISPがIPv6をサポートしていないが、とにかくLANでIPv6を有効にし（おそらくRFC 4193アドレスを使用）、AAAAレコードを作成する場合、LAN上のクライアントがLAN上のサーバーに到達するために機能します。しかし、LANと外部の世界との間の通信では、最初にIPv6が試行され（これは機能しません）、IPv4へのフォールバックに依存します。これは、せいぜい少し遅くなったり、最悪の場合は起こりません。
同様の問題を抱えている人たちの視野を広げるために、私の質問に答えます。
ISPに連絡して、問題を解決するように依頼しました。彼らが私に提供したのはサーバー専用の別のパブリックIPアドレスです。FreeBSDのWAN=側にローカルトラフィックがあり、サーバーのパブリックIPへのローカルトラフィックのスループットを向上させるために特定のパイプを作成しました
ここでのコメントは私の特定の問題を扱っていなかったので、ここに回答を追加します。 Linuxカーネルの厄介なバグに遭遇したためだと思います。設定は次のとおりです。
internet <--> modem 1.1.1.1/30 <--> switch <---> LAN 10.1.1.0/24
^
+----------------------+ |
| /--eth0 o <----/
| | |
| 10.1.1.1/24 br0 | v (antenna)
| 1.1.1.2/30 | | |
| \-wlan0 o ----------/
+----------------------+
複雑な外観にもかかわらず、他のコメントでカバーされている状況に関連する唯一の変更は、ソフトウェアブリッジbr0の追加です。ゲートウェイボックスがLANのワイヤレスアクセスポイントでもあるので、そこにあります。
私たちのゲートウェイボックスは、LAN上のマシンに対してNAT=義務を引き続き実行しています。イーサネットポートが1つしかないため、ヘアピンNATを強制されます。指定されたiptablesルールで動作するはずです。他のコメントではここにありますが、Linuxカーネル4.9では少なくともそうではありません。4.9では、ゲートウェイボックスはインターネットにアクセスでき、LAN上のマシンはNAT canない.
tcpdumpは、eth0にヒットする着信パケットへの応答を示しますが、br0からは除外されません。このコマンドを実行すると、次のことが修正されます。
ebtables -t brouter -A BROUTING -d 01:00:00:00:00:00/01:00:00:00:00:00 -j ACCEPT
ebtables -t brouter -A BROUTING -p IPv4 --ip-dst 10.1.1.0/24 -j ACCEPT
ebtables -t brouter -A BROUTING -p IPv4 --ip-src 10.1.1.0/24 -j ACCEPT
ebtables -t brouter -A BROUTING -p IPv4 -j DROP
そのコマンドが実行される前に、着信パケットはカーネルのデフォルトの動作に従って処理されます。これは、パケットをブリッジに渡して、カーネルのルーティングモジュールに渡すことです。このコマンドは、LANからのものではないパケットに強制的にブリッジをバイパスさせ、直接ルーティングに行きます。つまり、ブリッジはそれらをドロップする機会がありません。ブロードキャストアドレスとマルチキャストアドレスはブリッジする必要があります。そうしないと、DHCPやmDNSなどが機能しません。 IPv6を使用している場合は、IPv6のルールも追加する必要があります。
あなたはこれを使って問題を修正したくなるかもしれません：
brctl hairpin br0 eth0 on
brctl hairpin br0 wlan0 on
私は確かにとても誘惑されました-それは私の最初の試みでした。 LAN上のマシンがインターネットにアクセスできるようになったので、しばらくの間は動作しました。その後、次のことが起こりました（そして、私は実験を繰り返す気になりませんでした）：
- LANからゲートウェイへのping時間は約10秒間隔で2倍になり、0.1msから0.2ms、0.4ms、0.8ms、2msと続き、LANからゲートウェイボックスにアクセスできなくなりました。パケットストームのような匂いがしますが、STPがどこでもオンになっています。
- 間もなくすべてのワイヤレスアクセスポイントが停止しました。
- ワイヤレスで何が起こっているのかを診断しようとしたところ、すべてのIP電話が再起動しました。
- その後間もなく、有線マシンはLANとのすべての接続を失いました。
唯一の解決策は、建物内のすべてのマシンを再起動することでした。 1つの例外はハードウェアスイッチで、再起動できませんでした。彼らは電源を入れ直す必要がありました。
私もこの質問をしました（ を参照してください）外部IPを使用してファイアウォールの内側にNAT接続されたネットワークサービスに内部からアクセスするにはどうすればよいですか ）、ここにリダイレクトされましたが、ここでの回答はsolutionを提供します（一般的なexplanationsとは対照的に）ここにLinux（iptables固有）ソリューションを提供して、数時間の実験をすべての人に節約します。このファイルはiptables-restore形式であり、（もちろんIPアドレスを編集した後で）iptablesに直接読み込むことができます。これは、Webサーバー（ポート80）とIPv4専用です-IPv6とSSL（ポート443）のルールは類似しています。
# Port forwarding for VM / Container access with „hairpin NAT“.
*nat
:PREROUTING ACCEPT [3:205]
:INPUT ACCEPT [59:670]
:OUTPUT ACCEPT [16:172]
:POSTROUTING ACCEPT [20:257]
# This was simple port forwarding - access works from outside but not from inside
#-A PREROUTING -4 -p tcp -i eth0 --dport 80 -j DNAT --to web.local:80
# This is real hairpin NAT which allows „web.local“ to access itself via the VM hosts external IP.
# First we need to masquerade any traffic going out the external interface:
-A POSTROUTING -o eth0 -j MASQUERADE
# Then we need to reroute incoming traffic on the public IP to the local IP:
-A PREROUTING -4 -p tcp -d web.public.com --dport 80 -j DNAT --to web.local:80
# And finally we need to tell the router that the source IP of any traffic
# coming from the LAN must be source-rewritten when going to the web server:
-A POSTROUTING -4 -p tcp -s lan.local/24 -d web.local --dport 80 -j SNAT --to-source web.public.com:80
COMMIT
lan.local、web.localおよびweb.public.comをローカルネットワーク（10.0.x.0/24など）、ウェブサーバーのローカルIP（10.0.1.2など）、およびルーターのパブリックIPに置き換えます（例：4.5.6.7）。 -4は、IPv6とIPv4のルールを同じファイルで許可するためのものです（ip6tablesによって無視される行など）。また、IPv6アドレスにポート宣言が含まれている場合は、必ず[括弧]に入れてください。 [fe0a:bd52::2]:80。
これらすべてが、実際に試してみるときに髪を抜く原因となりましたimplementこの質問の説明。何も残していないといいのですが。
それは正規の質問なので。 Sonicwallルーターがあればお答えします。
知っている表現はNATループバックポリシー
このドキュメントでは、サーバーのパブリックIPアドレスからFQDNを使用して、SonicWall LAN上のホストがSonicWall LAN上のサーバーにアクセスする方法について説明します。プライマリLANサブネットが10.100.0.0/24であり、プライマリNSA IPが3.3.2.1であるWAN 4500（SonicOS Enhanced）ネットワークを想像してください。たとえば、顧客向けのWebサイトがあり、そのホスト名がであるとします。外部者がWebサイトにアクセスできるようにするために必要なポリシーとルールはすでに記述していますが、実際にはプライベートサイドサーバー10.100.0.2で実行されています。あなたはラップトップをプライベート側で使用していて、IPは10.100.0.200です。ラップトップを携帯しているときに同じことをするので、パブリック名を使用してサーバーにアクセスしたいとします。プライベート側、およびリクエスト http://www.example.com >、ループバックは、サーバーが実際にローカルIPアドレスのすぐ隣にあるにもかかわらず、それが機能することを可能にするものです。
この機能を許可するには、NATループバックポリシーを作成する必要があります。NATリフレクションまたはヘアピンとも呼ばれます。
WANインターフェースのIPアドレスを使用したループバックポリシー
Login to the SonicWall Management GUI.
Navigate to Manage | Rules | NAT Policies submenu.
Click on the Add button.
Create the following NAT Policy.
Original Source: LAN Subnets (or Firewalled Subnets if you want hosts in other zones to be included)
Translated Source: WAN Interface IP
Original Destination: WAN Interface IP
Translated Destination: (LAN server object)
Original Service: Any
Translated Service: Original
Inbound Interface: Any
Outbound Interface: Any
Sonicwallは、接続しようとする外部サービスを認識し、宛先アドレスをサーバー内部のアドレスに合わせて書き換えるので、コンピューターに対して透過的です。