Mikrotik RB2011ルーター/ファイアウォールを使用しています。ファイアウォールの内側にプライベートIPを持つWebサーバーがあります(192.168.1.5だとしましょう)
ファイアウォールのWAN側)に静的IPがあります(192.0.43.10-www.example.comと仮定します)。
ファイアウォール/ルーターはNATを実行しています。
HTTPSトラフィックをサーバーに渡すdstnatルールがあり、それは機能します。
今では古くからの問題は、内部PCが接続しようとすると、 https://www.example.com このエラーがChromeで表示されたページの読み込みに失敗することです。
Www.example.comへのGoogleChromeの接続試行は拒否されました。 Webサイトがダウンしているか、ネットワークが適切に構成されていない可能性があります。
ここにいくつかの提案があります:後でこのウェブページをリロードしてください。インターネット接続を確認してください。使用している可能性のあるルーター、モデム、またはその他のネットワークデバイスを再起動します。 Google Chromeをファイアウォールまたはウイルス対策ソフトウェアの設定で許可されたプログラムとして追加します。すでに許可されているプログラムである場合は、許可されたプログラムのリストから削除して、もう一度追加してください。プロキシサーバー、プロキシ設定を確認するか、ネットワーク管理者に連絡して、プロキシサーバーが機能していることを確認してください。プロキシサーバーを使用する必要がないと思われる場合は、プロキシ設定を調整してください。Chromeメニュー>設定> +詳細設定を表示>プロキシ設定を変更...で、構成が「プロキシなし」または「直接」に設定されていることを確認してください。エラー102(net :: ERR_CONNECTION_REFUSED):サーバーが接続を拒否しました。
従来、私は、www.example.comへのdnsルックアップが外部ではなくサーバーの内部IPを返すスプリットDNSまたはデュアルDNSタイプのセットアップを使用してこれを解決しました。ただし、ここではその設定の贅沢はありません。
事前ルーティングルールを使用してmikrotikでこれを解決する方法があるはずですが、それを設定する方法がわかりません。どうすればいいですか?
これは私が私のnatテーブルに持っているものです。しかし、繰り返しますが、そうではありません。サーバーでtcpdumpを実行していますが、およびパケットが実際に到達していないことがわかります。
[admin@MikroTik] /ip firewall nat> print
Flags: X - disabled, I - invalid, D - dynamic
0 chain=dstnat action=dst-nat to-addresses=192.168.0.10 protocol=tcp
dst-address=114.134.xxx.xxx in-interface=wan dst-port=22
1 chain=dstnat action=dst-nat to-addresses=192.168.0.10 protocol=tcp
dst-address=114.134.xxx.xxx in-interface=wan dst-port=443
2 chain=srcnat action=masquerade src-address=192.168.0.0/24
dst-address=192.168.0.0/24
3 ;;; default configuration
chain=srcnat action=masquerade to-addresses=114.134.xxx.xxx
out-interface=wan
複雑な「Hairpin_NAT」があなたのシーンではない場合、遅延の解決策:
ローカルサーバーを指す静的DNSエントリをMTデバイスに追加するだけです。並べ替えられます。すべてのローカルリクエストはルーターをバイパスして正しく解決され、すべての外部のものはDNSエントリを無視するため、 dstnatルート。
/ip dns
set allow-remote-requests=yes cache-size=8048KiB servers=\
8.8.8.8,8.8.4.4
/ip dns static
add address=192.168.1.5 name=www.example.com
独自の内部DNSサーバーを実行していると仮定すると、「example.com」ゾーンに対して権限を持ち、他のすべてのクエリをOpenDNSやGoogleのパブリックリゾルバーなどに転送することができます(または、困難な再帰リゾルバーとして機能します)。内部の権威ある「example.com」ゾーンでは、世界に面した権威ゾーンのすべてのレコードに対応するが、非公開のIP番号を提供するレコードが必要です。以下の例は、内部トラフィックをローカルに保ちながら、内部クライアントと外部クライアントに個別の回答を提供するDNSサーバーを示しています。
したがって、非公開ゾーン(ファイルexample.com_internalに保存されている)は次のようになります。
$ TTL 7D $ Origin example.com @ IN SOAexample.com。hostmaster.example.com( 1000001;シリアル番号 8H;更新間隔 2H;再試行間隔 4W;有効期限 1D;最小 ) @ IN NS dns.example.com @ IN A 192.168.1.5 dns IN A 192.168.1.3 dns IN A 192.168.1.4 www IN CNAME @
パブリックゾーン(ファイルexample.com_publicに保存されている)は次のようになります。
$ TTL 7D $ Origin example.com @ IN SOA example.com。hostmaster.example.com( 249590;シリアル番号 8H;更新間隔 2H;再試行間隔 4W;有効期限 1D;最小 ) @ IN NS dns.example.com @ IN A 192.0.43.10 www IN CNAME @ dns IN A 192.0.43.10
次に、ネームサーバーを次のように構成します。
options { directory "/var/named"; }; controls { inet 127.0.0.1 allow { localhost; }キー{rndc_key; }; }; key "rndc_key" { algorithm hmac-md5; secret "ht3pp9a4cik1aq530g6uri06p9g28yrvikqdzr7h"; } ; acl internal { 127.0.0.0/8; 192.168.1.0/24 ; } acl external { !192.168.1.0/24; !240.0.0.0/4; } view internal { match-clients {internal; }; フォワーダー{8.8.8.8; 8.8.4.4;}; 転送のみ; ゾーン "0.0.127.in-addr.arpa" { タイプマスター; ファイル "zone/127.0 .0 "; allow-query {192.168.1.0/24;}; }; ゾーン" 1.168.192.in-addr.arpa " { type master; file "zone/192.168.1"; allow-query {192.168.1.0/24;}; }; ゾーン "example.com" { タイプマスター; ファイル "zone/example.com_internal"; allow-query {192.168.1.0/24 ;}; }; } 外部を見る{ match-clients {external; }; 再帰番号; ゾーン "example.com" { タイプマスター; ファイル "zone/example.com_public"; } ; ゾーン "43.0.192.in-addr.arpa" { タイプマスター; ファイル "zone/192.0.43"; }; }
これはすべて非常に簡単なことであり、本番環境に展開する前に、ラボ環境でテストする必要があります。 「example.com」のすべての場合、マシンは内部アドレスを取得し、顧客はパブリックアドレスを取得します。レプリケーションと一貫性を確保できるように、DNSサーバー間にマスタースレーブ配置をセットアップする必要もあります。