VPNユーザー必見！ネットボランチのDNS設定

By /

VPNユーザー必見！ネットボランチのDNS設定を徹底解説 – セキュリティと快適性を両立する詳細ガイド

インターネットは、私たちのビジネスや日常生活において欠かせないインフラとなりました。そして、リモートワークや多拠点連携が一般的になるにつれて、VPN（Virtual Private Network）の利用も急速に拡大しています。VPNは、インターネット上に仮想的なプライベートネットワークを構築し、離れた場所にある端末やネットワーク間を安全に接続するための技術です。

VPNを利用する上で、多くの方が通信の暗号化や認証によるセキュリティ強化に注目します。もちろんこれらはVPNの重要な機能ですが、実は見落とされがちな、しかし非常に重要な要素があります。それが「DNS設定」です。特に、多くの企業や個人事業主が利用しているヤマハ製の高機能ルーター「ネットボランチ」シリーズにおいて、VPN環境下での適切なDNS設定は、セキュリティリスクの回避、名前解決の高速化、そして快適なネットワーク利用のために不可欠です。

この記事では、VPNユーザー、特にネットボランチをネットワークの中心に据えている方々に向けて、DNSの基本からVPN環境におけるDNS設定の重要性、そしてネットボランチでの具体的な設定方法、さらにDNSリーク対策までを、詳細かつ網羅的に解説します。約5000語のボリュームで、あなたが抱えるDNSに関する疑問や不安を解消し、より安全で快適なVPNライフを実現するための一助となることを目指します。

第1章：なぜVPNユーザーにDNS設定が重要なのか？

インターネットを利用する際に、私たちは通常、ウェブサイトのURL（例: www.google.com）を入力します。しかし、コンピューターやネットワーク機器は、この人間が理解しやすいドメイン名を直接扱うことはできません。代わりに、IPアドレス（例: 172.217.160.142）という数値で通信相手を識別します。このドメイン名とIPアドレスを相互に変換するシステムこそが、DNS（Domain Name System）です。

1.1 DNS（Domain Name System）の基本

DNSは、インターネットの「電話帳」や「住所録」に例えられます。私たちが電話をかける際に相手の名前を知っていれば電話帳で電話番号を調べられるように、ウェブサイトにアクセスする際にドメイン名を知っていれば、DNSを使ってそのサイトのIPアドレスを調べることができます。この「ドメイン名からIPアドレスを調べるプロセス」を「名前解決」と呼びます。

名前解決は、以下のような流れで行われます。

  1. ユーザーのコンピューターが名前解決要求を出す: ブラウザで www.example.com にアクセスしようとすると、コンピューターは設定されているDNSサーバーに対して「www.example.com のIPアドレスを教えてください」という問い合わせ（DNSクエリ）を送ります。
  2. DNSサーバーが問い合わせを処理する: コンピューターから問い合わせを受けたDNSサーバー（ローカルDNSサーバー、またはキャッシュDNSサーバーと呼ばれることが多い）は、まず自身のキャッシュに該当のドメイン名とIPアドレスの対応情報がないかを確認します。
  3. キャッシュにある場合: 情報が見つかれば、そのIPアドレスをユーザーのコンピューターに返します。これが最も高速な名前解決のパターンです。
  4. キャッシュにない場合: 情報が見つからなければ、DNSサーバーはインターネット上の他のDNSサーバーに問い合わせを始めます。まず、ルートDNSサーバーに問い合わせ、次にTLD（Top-Level Domain）サーバー（.com, .org, .jp などを管理するサーバー）に、そして最終的にそのドメイン名を管理している権威DNSサーバーに問い合わせを行います。
  5. 権威DNSサーバーが応答する: 権威DNSサーバーは、管理しているドメイン名の正確なIPアドレス情報を持っており、それをキャッシュDNSサーバーに返します。
  6. キャッシュDNSサーバーがユーザーに返す: キャッシュDNSサーバーは、受け取った情報を自身のキャッシュに保存するとともに、ユーザーのコンピューターにIPアドレスを返します。
  7. コンピューターが通信を開始する: IPアドレスを受け取ったコンピューターは、そのIPアドレス宛にHTTPなどのプロトコルで通信を開始し、ウェブサイトが表示されるというわけです。

通常、家庭やオフィスのネットワークでは、ルーターがプロバイダから提供されたDNSサーバーの情報を受け取り、そのDNSサーバーをネットワーク内のコンピューターにDHCPなどで配布します。コンピューターは、配布されたDNSサーバーを利用して名前解決を行います。

1.2 VPN環境におけるDNSの特殊性

さて、ここでVPNが登場します。VPNは、インターネット上に仮想的なトンネルを掘り、そのトンネル内をデータが安全に流れるようにします。しかし、この「トンネル」が常にすべての通信を通過させるわけではありません。VPNの接続方式には、大きく分けて以下の2種類があります。

  • フルトンネル (Full Tunneling): VPN接続を確立した端末からのすべての通信をVPNトンネル経由で流す方式です。インターネット上の通信も、社内ネットワークへの通信も、すべてVPN接続先のVPNサーバーを経由します。
  • 分割トンネル (Split Tunneling): VPN接続を確立した端末からの通信のうち、特定の宛先（通常はVPN接続先の社内ネットワークなど）への通信のみをVPNトンネル経由で流し、それ以外のインターネット上の通信は端末が接続しているローカルネットワークから直接インターネットへ流す方式です。

このフルトンネルと分割トンネル、どちらを利用するかによって、DNSの名前解決の挙動に大きな違いが出てきます。

  • フルトンネルの場合: 端末からの通信はすべてVPNトンネルを通過します。したがって、DNSクエリもVPNトンネル経由でVPNサーバー側に設定されたDNSサーバーに送られることが期待されます。これにより、アクセス先の情報（ドメイン名）がVPNトンネルの外に漏れることなく、安全に名前解決が行われます。
  • 分割トンネルの場合: 社内ネットワークへの通信はVPNトンネルを通りますが、インターネット上の通信はローカルネットワークから直接行われます。このとき、DNSクエリはどちらの経路を通るべきでしょうか？ 通常、端末はローカルネットワークでDHCPから受け取ったDNSサーバーと、VPN接続時にVPNサーバーから配布されたDNSサーバーの両方、あるいはどちらか一方を名前解決に使用しようとします。

問題となるのは、意図しないDNSサーバーが使われてしまうケースです。特に分割トンネル環境では、社内ネットワークの名前解決（例: 社内サーバー名 fileserver.internal.local）はVPNトンネルを通って社内DNSサーバーで行う必要がありますが、一般的なインターネット上の名前解決（例: www.google.com）はローカルネットワークのDNSサーバーで行う方が、VPNサーバーに負荷をかけず、通信も高速になる可能性があります。しかし、設定によっては、社内DNSサーバーへの問い合わせがローカルネットワークに流れてしまったり、逆にインターネット上のDNSサーバーへの問い合わせがVPNトンネルを通ってしまったり、さらにはローカルネットワークのDNSサーバーに意図せず問い合わせてしまい、アクセス先の情報が漏れてしまうといった問題が発生します。

1.3 DNSリークの危険性

ここで最も警戒すべきなのが「DNSリーク（DNS Leak）」と呼ばれる現象です。DNSリークとは、VPN接続中に、名前解決のためのDNSクエリがVPNトンネルを経由せず、ローカルネットワークのDNSサーバーに直接送信されてしまう状態を指します。

なぜこれが問題なのでしょうか？

  • プライバシーの侵害: あなたがどのウェブサイトにアクセスしようとしたか（ドメイン名）の情報が、VPN接続をしていないかのような形で、ローカルネットワークのISPや公衆Wi-Fiの管理者などに筒抜けになってしまいます。VPNでIPアドレスを隠していても、アクセス先のドメイン名が知られてしまっては、プライバシー保護の目的が損なわれます。
  • セキュリティリスク: 悪意のある第三者が運営する偽のDNSサーバーを使用した場合、誤ったIPアドレスを応答されてフィッシングサイトなどに誘導される可能性があります。また、社内ネットワークにアクセスする際に、社内限定のドメイン名が外部のDNSサーバーに問い合わせられてしまい、ネットワーク構成の一部が漏洩するリスクもあります。
  • 名前解決の失敗: 分割トンネルで社内リソースにアクセスしようとした際に、社内ネットワーク外のDNSサーバーに問い合わせてしまい、名前解決ができずにリソースにアクセスできない、といった問題が発生します。

VPN接続を利用する最大の理由の一つは、通信の秘匿性や安全性を確保することです。しかし、DNSリークが発生すると、その目的が大きく損なわれてしまいます。特にビジネスでVPNを利用する場合、アクセス先の情報が漏洩することは、情報セキュリティポリシーに反する重大な問題となり得ます。

したがって、VPNユーザーにとって、適切なDNS設定を行い、DNSリークを防ぐことは、VPN接続そのもののセキュリティと有効性を確保するために極めて重要なのです。そして、その設定の中心的な役割を担うのが、ネットボランチのようなネットワーク機器になります。

第2章：ネットボランチにおけるDNS設定の基本

ネットボランチシリーズ（RTX、NVRなど）は、高性能かつ多機能な業務用ルーターとして広く利用されています。VPN機能も充実しており、IPsec、L2TP/IPsec、OpenVPN、PPTPなど、様々なプロトコルをサポートしています。ネットボランチにおけるDNS設定は、大きく分けて以下の2つの側面があります。

  1. ルーター自身がインターネット上の名前解決や各種サービス（NTP、ファームウェアアップデートなど）のために使用するDNSサーバーの設定
  2. ルーター配下のLANクライアント（PC、スマートフォンなど）に配布するDNSサーバーの設定（主にDHCPサーバー機能を利用）

VPN環境では、特に後者の「クライアントに配布するDNSサーバー」の設定が重要になります。

2.1 ネットボランチの設定画面へのアクセス

ネットボランチの設定は、主に以下の2つの方法で行います。

  • Web GUI: Webブラウザを使用して、ルーターのIPアドレス（工場出荷時は 192.168.100.1 など）にアクセスし、ユーザー名とパスワードを入力してログインします。視覚的に分かりやすく、基本的な設定はこちらで行うことが多いです。
  • CUI (Command Line Interface): Telnet、SSH、またはコンソールケーブルを使用してルーターに接続し、コマンドを入力して設定を行います。GUIよりも詳細な設定や、より高度なカスタマイズを行う場合に利用します。VPN関連の細かな設定や、特定の通信制御などはCUIで行うことが一般的です。

本記事では、CUIでの設定を中心に解説します。CUIでの設定は、コマンドを覚える必要がありますが、設定内容をテキストとして保存・管理しやすく、より柔軟な設定が可能です。

2.2 ルーター自身が使用するDNSサーバーの設定

ネットボランチルーター自身も、インターネット上のホスト名やサービスにアクセスするために名前解決を行う必要があります。例えば、NTPサーバーと時刻同期したり、ダイナミックDNSサービスにホスト名を登録したり、新しいファームウェアをダウンロードしたりする際に、ルーターはDNSを利用します。

ルーター自身が使用するDNSサーバーは、通常、プロバイダから自動的に取得します。しかし、手動で特定のDNSサーバーを指定することも可能です。設定コマンドは dns server です。

“`bash

現在の設定を確認

show dns server

プロバイダから自動取得（デフォルト設定）

dns server nat

手動でDNSサーバーを指定する場合（例: Google Public DNS）

優先順位はリストの上位から高くなる

dns server 8.8.8.8
dns server 8.8.4.4
“`

dns server nat は、WAN側のインターフェースでDHCPクライアントとして取得したDNSサーバーを使用するという意味です。通常はこの設定で問題ありませんが、特定のDNSサーバーを利用したい場合や、セキュリティ上の理由から信頼できるDNSサーバー（例: Cloudflare DNS 1.1.1.1, Google Public DNS 8.8.8.8 など）を使用したい場合は、手動で指定します。

この設定は、主にルーター自身の名前解決に影響しますが、後述するDNSフォワーディング機能を利用する場合など、LANクライアントの名前解決にも間接的に影響する場合があります。

2.3 LANクライアントに配布するDNSサーバーの設定 (DHCP)

ネットボランチをDHCPサーバーとして利用している場合、LAN内のコンピューターやスマートフォンは、ルーターからIPアドレス、サブネットマスク、デフォルトゲートウェイなどのネットワーク設定を自動的に取得します。このとき、クライアントが名前解決に使用するDNSサーバーの情報もDHCPオプションとして配布されます。

このDHCPで配布するDNSサーバーを指定する設定が、VPN環境においては特に重要になります。設定は、DHCPスコープに対して行います。

“`bash

現在のDHCP設定を確認 (scope 1 の場合)

show dhcp scope 1

DHCPスコープで配布するDNSサーバーを指定するコマンド

形式: dhcp scope option DNS [ …]

例1: ルーター自身をDNSサーバーとして配布する（ルーターがDNSフォワーダーとして機能）

dhcp scope option DNS 192.168.1.1 # ルーターのLAN側IPアドレス

例2: 特定のDNSサーバーを配布する（例: Google Public DNS）

dhcp scope option DNS 8.8.8.8 8.8.4.4

例3: 社内DNSサーバーを配布する（VPN接続クライアント向けなど）

dhcp scope option DNS 192.168.10.1
“`

dhcp scope option DNS コマンドは、DHCPクライアントにDNSサーバーのIPアドレスを通知します。クライアントは通常、このDHCPオプションで指定されたDNSサーバーを優先的に使用して名前解決を行います。

例えば、オフィスネットワークでネットボランチがDHCPサーバーになっている場合、社内リソース（ファイルサーバーやイントラネットなど）の名前解決には社内DNSサーバー（例: Windows ServerのActive Directory統合DNSなど）が必要です。この場合、DHCPで社内DNSサーバーのIPアドレスを配布するように設定します。

第3章：ネットボランチにおけるVPN環境でのDNS設定

ここからが本題です。VPN環境、特にリモートアクセスVPNと拠点間VPN、それぞれのシナリオでネットボランチのDNS設定をどのように行うべきか、詳しく見ていきます。

3.1 リモートアクセスVPNにおけるDNS設定

リモートアクセスVPNは、自宅や外出先のPC、スマートフォンなどから、会社のネットワークに安全に接続するためのVPNです。L2TP/IPsecやOpenVPNなどのプロトコルがよく使われます。

リモートアクセスVPN接続を確立したクライアント（PCなど）は、会社のネットワーク内のIPアドレス（仮想IPアドレスなど）を取得し、あたかも社内にいるかのように社内リソースにアクセスできるようになります。このとき、クライアントが名前解決に使用するDNSサーバーの設定が重要になります。

理想的な挙動としては、以下のようになります。

  • 社内リソースの名前解決: 社内ネットワーク内にあるサーバーやプリンター、イントラネットなどの名前解決（例: fileserver.internal.local）は、社内DNSサーバーで行う必要があります。このクエリはVPNトンネルを経由して社内DNSサーバーに到達すべきです。
  • インターネット上の名前解決: ウェブサイトや外部のサービスなどの名前解決（例: www.google.com）は、パブリックDNSサーバーで行うことが一般的です。これが分割トンネルの場合はローカルネットワークから直接、フルトンネルの場合はVPNサーバーを経由して行うことになります。

ネットボランチでリモートアクセスVPNを設定する際、VPN接続してきたクライアントにどのようなIPアドレスやネットワーク設定を配布するかを定義します。これには、IPアドレス範囲だけでなく、サブネットマスク、デフォルトゲートウェイ、そしてDNSサーバーが含まれます。

VPN接続クライアントに配布するDNSサーバーを設定する主な方法は、以下の2つです。

  1. VPN接続用のDHCPスコープでDNSサーバーを配布する:
    多くのリモートアクセスVPNプロトコル（特にL2TP/IPsecなど、クライアントがDHCPクライアントとして動作する場合）では、VPN接続が確立したクライアントに、ルーター側で設定したDHCPスコープからIPアドレスなどの情報を配布します。このDHCPスコープで、配布するDNSサーバーを指定します。
    bash
    # VPN接続クライアント用のDHCPスコープを設定していると仮定
    # 例: スコープ番号 2 を VPN 用に使用
    dhcp scope 2 192.168.200.10-192.168.200.50/24
    dhcp scope option 2 default-router 192.168.200.1 # VPN接続時のデフォルトゲートウェイ
    # ここで配布するDNSサーバーを指定
    dhcp scope option 2 DNS 192.168.10.1 # 社内DNSサーバーのIPアドレス
    この設定により、VPN接続したクライアントは、DHCPで社内DNSサーバーのIPアドレスを受け取り、名前解決にそのサーバーを使用するようになります。

  2. VPNプロトコルの設定でDNSサーバー情報をプッシュする:
    OpenVPNなど、一部のVPNプロトコルでは、VPNサーバー側からクライアントに対して特定のネットワーク設定情報を「プッシュ」することができます。ネットボランチのOpenVPNサーバー機能を利用する場合、この方法でDNSサーバー情報をクライアントに通知することが可能です。
    bash
    # OpenVPNサーバー設定の一部として
    # クライアントに社内DNSサーバー (192.168.10.1) を配布
    openvpn-bridge tunnel openvpn1
    openvpn-bridge tunnel openvpn1 mode server
    openvpn-bridge tunnel openvpn1 remote-network 192.168.200.0/24
    # DNSサーバー情報をプッシュする設定（pushオプション）
    openvpn-bridge tunnel openvpn1 push "dhcp-option DNS 192.168.10.1"
    # 複数のDNSサーバーをプッシュする場合
    # openvpn-bridge tunnel openvpn1 push "dhcp-option DNS 192.168.10.1"
    # openvpn-bridge tunnel openvpn1 push "dhcp-option DNS 8.8.8.8"
    この設定により、OpenVPNクライアントはVPN接続確立時にプッシュされたDNSサーバー情報を利用するようになります。

どちらの方法にせよ、重要なのはVPN接続クライアントが社内リソースの名前解決に必要なDNSサーバーを正しく認識し、利用するように設定することです。通常、これは社内ネットワーク内に設置されたDNSサーバーのIPアドレスになります。

3.1.1 分割トンネル vs. フルトンネルとDNS

リモートアクセスVPNにおけるDNS設定の考慮事項は、分割トンネルかフルトンネルかによって大きく変わります。

  • フルトンネルの場合:
    すべての通信がVPNトンネルを経由するため、DNSクエリもVPNトンネルを通ります。したがって、VPN接続クライアントには、VPNサーバー側で設定された信頼できるDNSサーバー（社内DNSサーバー、またはVPNサーバーがある拠点のネットワークからアクセスできるパブリックDNSサーバーなど）を配布する必要があります。
    この場合、DHCPオプションやOpenVPNのpushオプションで配布するDNSサーバーは、社内DNSサーバーのIPアドレス（例: 192.168.10.1）を指定します。これにより、インターネット上の名前解決も、社内リソースの名前解決も、すべてこのDNSサーバー経由で行われるようになります。これにより、DNSリークのリスクは低減されます。

  • 分割トンネルの場合:
    社内ネットワーク宛ての通信はVPNトンネルを通りますが、インターネット宛ての通信はローカルネットワークから直接行われます。このシナリオがDNSリークのリスクが最も高まるケースです。
    DNSクエリの処理は、通常クライアントOSの設定に依存します。VPN接続時に配布されたDNSサーバー（社内DNS）と、ローカルネットワークでDHCPから取得したDNSサーバー（ローカルISPのDNSなど）の両方がクライアントに設定されている場合、クライアントOSはどちらのDNSサーバーを使うかを判断します。多くのOSは、設定されたDNSサーバーリストの上位にあるものや、応答が速いものを使おうとします。
    ここで問題となるのは、社内ドメイン名（例: internal.local）の名前解決クエリが、誤ってローカルネットワークのDNSサーバーに送られてしまうことです。ローカルのDNSサーバーは社内ドメイン名の情報を知らないため、名前解決に失敗するか、あるいは最悪の場合、問い合わせた社内ドメイン名が外部に漏洩してしまいます。
    逆に、インターネット上のドメイン名（例: www.google.com）の名前解決クエリが、社内DNSサーバーに送られてしまうと、社内DNSサーバーに余計な負荷がかかるだけでなく、場合によっては名前解決に時間がかかったり、特定のフィルタリングによってアクセスが制限されたりする可能性があります。

分割トンネル環境でのDNSリークを防ぎ、かつ名前解決を効率的に行うためには、いくつかの対策が必要です。

3.1.2 分割トンネル環境におけるDNSリーク対策と適切な名前解決

分割トンネル環境で、社内ドメイン名は社内DNS、インターネット上のドメイン名はパブリックDNSで解決させるように制御するためには、以下の設定や考慮が必要です。

  1. クライアントへのDNS配布:
    VPN接続時にクライアントに配布するDNSサーバーとして、社内DNSサーバーのIPアドレスのみを指定します。
    bash
    # VPN接続クライアント用のDHCPスコープ設定で
    dhcp scope option <VPN用スコープ番号> DNS 192.168.10.1 # 社内DNSサーバー
    これにより、クライアントは優先的に社内DNSサーバーを使おうとします。ただし、ローカルネットワークで取得したDNS設定がクライアントに残っている場合、そちらも使われる可能性があるため、これだけでは不十分な場合があります。

  2. クライアント側の設定:
    VPNクライアントソフトウェアの設定で、「リモートネットワークでデフォルトゲートウェイを使用する」といったオプションを無効にする（分割トンネルの設定）とともに、「リモートDNSサーバーを使用する」といったオプションが有効になっているか確認します。また、クライアントOSのネットワークアダプターのDNS設定において、VPN接続時にはローカルネットワーク側のDNSサーバーが無効になるか、VPN側DNSサーバーが優先されることを確認します。多くのVPNクライアントソフトウェアはこの辺りを自動的に制御してくれますが、手動設定の場合は注意が必要です。

  3. ネットボランチでの条件付きフォワーディング (Conditional Forwarding):
    ネットボランチ自身をDNSフォワーダーとして機能させ、特定のドメイン名の名前解決要求を特定のDNSサーバーに転送する設定です。これにより、クライアントからネットボランチに来たDNSクエリを、ドメイン名によって振り分けることができます。
    例えば、クライアントに配布するDNSサーバーとしてネットボランチ自身のIPアドレス（例: 192.168.1.1）を指定し、ネットボランチ側で以下の設定を行います。
    “`bash
    # クライアントに配布するDNSサーバーをルーター自身に設定
    dhcp scope option DNS 192.168.1.1
    # ネットボランチ自身のDNSサーバー設定（プロバイダから取得 or パブリックDNS）
    dns server nat
    # または
    # dns server 8.8.8.8 8.8.4.4

    特定のドメイン名 (.internal.local など) の名前解決要求を社内DNSサーバー (192.168.10.1) に転送する設定

    ヤマハルーターでは dns forwarding コマンドを使用します。

    形式: dns forwarding zone <ドメイン名> <転送先DNSサーバーIP>

    dns forwarding zone internal.local 192.168.10.1

    クライアントからのDNSクエリを受け付けるインターフェースを指定する場合（セキュリティ強化）

    例えば、LAN1インターフェース (通常 192.168.1.1) でのみDNSクエリを受け付ける

    ip lan1 address 192.168.1.1/24

    dns service on

    listen on lan1

    ``
    この設定により、クライアントからの    *.internal.local` の名前解決要求はネットボランチ経由で社内DNSサーバーへ、それ以外の名前解決要求はネットボランチ自身のDNS設定（プロバイダまたはパブリックDNS）に従って解決されるようになります。これにより、分割トンネル環境でも適切な名前解決経路を確保できます。

  4. ファイアウォールによる制御:
    最も確実なDNSリーク対策の一つは、ファイアウォールでDNSクエリの送信先を制限することです。VPN接続してきたクライアントからの、VPNトンネルを経由しない外部のDNSサーバー（IPアドレス53番ポート UDP/TCP）へのアクセスをブロックします。
    ネットボランチでは、ip filter コマンドを使用してファイアウォール設定を行います。
    “`bash
    # VPNクライアントが接続してくるインターフェースまたはIPアドレス範囲からのフィルタリングルールを設定
    # 例: VPN接続クライアントのIPアドレス範囲が 192.168.200.0/24 の場合
    # この範囲からの、宛先ポート 53 (UDP/TCP) の通信を拒否するフィルターを作成
    # (社内DNSサーバー 192.168.10.1 への通信は許可する必要がある)

    まず、社内DNSサーバーへの通信は許可するフィルター

    filter 100 pass * 192.168.200.0/24 192.168.10.1 * * *

    filter 100 pass * 192.168.200.0/24 192.168.10.1 udp,tcp * 53

    次に、それ以外の全てのIPアドレス (社内DNSサーバー以外) のポート 53 への通信を拒否するフィルター

    宛先IPアドレスを指定しない場合は全ての外部IPアドレス宛てになります。

    厳密には、社内ネットワーク外のIPアドレス宛てを指定する必要がありますが、

    シンプルにするため、許可リスト以外のポート53を拒否する形で実現します。

    フィルターリストを作成 (例: 適用するインターフェースに in direction で適用)

    順番が重要です！許可ルールを先に、拒否ルールを後に書きます。

    filter 100 pass * 192.168.200.0/24 192.168.10.1 udp * 53 # 社内DNS UDP許可

    filter 101 pass * 192.168.200.0/24 192.168.10.1 tcp * 53 # 社内DNS TCP許可

    filter 102 reject * 192.168.200.0/24 * udp * 53 # それ以外の宛先 UDP/53 拒否

    filter 103 reject * 192.168.200.0/24 * tcp * 53 # それ以外の宛先 TCP/53 拒否

    filter 199 pass * * * * * * * # それ以外の通信は通過 (必須)

    このフィルターリストを、VPNクライアントが接続してくるインターフェースに適用します。

    例えば、L2TP/IPsecの仮想インターフェースに適用する場合など。

    ipsec tunnel 1

    ipsec tunnel 1 ip interface address 192.168.200.1/24

    ipsec tunnel 1 ipsec sa policy 1 remote-id any

    ipsec tunnel 1 remote address dhcp

    ipsec tunnel 1 tcp mss limit auto

    ipsec tunnel 1 ip filter 100 in # フィルターリスト100をin方向 (クライアント -> ルーター) に適用

    注意: 上記フィルター設定例は概念を示しています。実際の適用インターフェースや

    IPアドレス範囲、フィルター番号は、お客様のネットワーク構成に合わせて適切に設定してください。

    特に、VPNクライアントのIPアドレス範囲を正確に指定することが重要です。

    また、reject フィルターの後に pass filter を入れることで、DNS以外の通信がブロックされないようにします。

    “`
    このファイアウォール設定により、VPN接続クライアントからのDNSクエリは強制的に社内DNSサーバー（許可したIPアドレス）か、VPNトンネルを経由して到達するネットボランチ自身（DNSフォワーディング設定がある場合）にしか送られなくなります。これにより、ローカルネットワークのDNSサーバーへの意図しない問い合わせを防ぎ、DNSリークを効果的に防止できます。

3.2 拠点間VPNにおけるDNS設定

拠点間VPNは、離れた場所にある複数のオフィスネットワーク（拠点）同士を安全に接続するためのVPNです。主にIPsecプロトコルが使われます。

拠点間VPNの場合、各拠点のルーター同士がVPN接続を確立し、あたかも同じLANに接続されているかのように、各拠点内の端末が相手拠点のネットワークにあるリソースにアクセスできるようになります。

拠点間VPNにおけるDNS設定で考慮すべきポイントは、以下の通りです。

  • 相手拠点内のリソースの名前解決: 例えば、本社ネットワーク（192.168.10.0/24）にあるファイルサーバー（fileserver.head.local）に、支店ネットワーク（192.168.20.0/24）のPCからアクセスする場合などです。支店のPCが fileserver.head.local の名前解決を要求した際に、本社にあるDNSサーバー（例: 192.168.10.1）に問い合わせる必要があります。
  • 各拠点のルーター自身の名前解決: 各拠点ルーターが、拠点間VPNの対向ルーターのIPアドレスをホスト名で指定している場合や、各種インターネットサービスを利用する場合に名前解決が必要です。

拠点間VPN環境での適切なDNS設定は、以下の方法で行います。

  1. 各拠点のPC向けDHCPサーバー設定:
    各拠点内のPCに配布するDNSサーバーとして、通常はその拠点内にあるDNSサーバーを指定します。社内ネットワーク全体でActive Directory統合DNSなどを運用している場合は、本社に社内DNSサーバーがあり、各支店のPCはその本社DNSサーバーに問い合わせる設計になっていることが多いでしょう。
    この場合、各拠点ルーターのDHCP設定で、配布するDNSサーバーとして本社DNSサーバーのIPアドレスを指定します。
    bash
    # 支店ルーター (192.168.20.1) の設定例
    # 支店内のPCに配布するDHCPスコープ (例: スコープ番号 1)
    dhcp scope 1 192.168.20.10-192.168.20.200/24
    dhcp scope option 1 default-router 192.168.20.1
    # 配布するDNSサーバーとして、本社DNSサーバーのIPアドレスを指定
    dhcp scope option 1 DNS 192.168.10.1
    これにより、支店のPCは名前解決を行う際に本社DNSサーバー（192.168.10.1）に問い合わせを行います。この問い合わせパケットは、支店ルーターのルーティング設定に従って、本社ルーターとの間のVPNトンネルを経由して本社ネットワークに到達し、本社DNSサーバーで名前解決が行われます。

  2. ネットボランチでの条件付きフォワーディング:
    拠点間VPNの場合も、前述のリモートアクセスVPNの分割トンネルと同様に、条件付きフォワーディングが有効な場合があります。例えば、各拠点にローカルなDNSサーバーを置いておき、*.branchX.local は各支店のローカルDNSで解決させ、*.head.local は本社DNSで解決させる、といった使い分けをする場合です。
    “`bash
    # 支店ルーターの設定例
    # 支店内のPCに配布するDNSサーバーとして、支店ルーター自身を指定
    dhcp scope option 1 DNS 192.168.20.1

    支店ルーター自身のDNSサーバー設定（インターネットの名前解決用）

    dns server nat # またはパブリックDNS

    本社ドメイン (.head.local) の名前解決要求を本社DNSサーバー (192.168.10.1) に転送

    dns forwarding zone head.local 192.168.10.1

    支店ドメイン (.branchX.local) は支店ルーター自身のDNS機能で解決（または支店内のローカルDNSへ転送）

    例: 支店内にローカルDNSサーバーがある場合 (192.168.20.100)

    dns forwarding zone branchX.local 192.168.20.100

    “`
    この設定により、支店のPCからの名前解決要求は一旦支店ルーターに送られ、支店ルーターがドメイン名に応じて適切なDNSサーバー（本社DNSまたはローカルDNS）へ転送します。

  3. ルーティング設定の確認:
    DNSクエリのパケット（通常は宛先ポート53 UDP/TCP）が、意図したDNSサーバー（本社DNSサーバーなど）へ到達するためには、ルーターのルーティング設定が正しく行われている必要があります。特に、相手拠点のネットワーク（本社ネットワーク 192.168.10.0/24）への通信がVPNトンネルを経由するようにルーティング設定されていることが前提となります。これはVPN接続設定（IPsec peer configなど）の一部として行われることが多いです。

拠点間VPN環境では、各拠点のローカルな名前解決と、広域ネットワーク全体での名前解決をどのように設計するかが重要です。DNSサーバーの設置場所や役割（権威DNSサーバー、キャッシュDNSサーバー、フォワーダー）に応じて、ルーターのDHCP配布設定やDNSフォワーディング設定を適切に行う必要があります。

3.3 CUIによる詳細設定例

ネットボランチのCUIでは、より細かくDNS関連の設定を行うことができます。以下にいくつかのコマンドとその用途を補足します。

  • dns service
    ネットボランチルーターがDNSサービス（DNSリゾルバー、DNSフォワーダーなど）として機能するかどうかを設定します。通常は on に設定します。
    bash
    dns service on

  • listen on
    dns service on にしている場合、どのインターフェースからのDNSクエリを受け付けるかを指定します。セキュリティ上の理由から、信頼できるLAN側のインターフェース（例: lan1）や特定のVPNインターフェースのみを指定することが推奨されます。
    “`bash
    # LAN1インターフェースからのDNSクエリを受け付ける
    listen on lan1

    複数のインターフェースからのDNSクエリを受け付ける

    listen on lan1 lan2 vpn1

    “`

  • dns server
    ルーター自身が名前解決を行う際に使用するDNSサーバーを指定します。プロバイダから取得 (nat) するか、手動で指定します。
    bash
    dns server nat # プロバイダから取得
    dns server 8.8.8.8 8.8.4.4 # 手動指定 (Google Public DNS)

  • dns forwarding zone
    特定のドメイン名の名前解決要求を、指定したDNSサーバーに転送する設定です。前述の条件付きフォワーディングに利用します。
    bash
    # internal.local の名前解決要求を 192.168.10.1 に転送
    dns forwarding zone internal.local 192.168.10.1

  • dhcp scope option DNS
    DHCPサーバー機能でクライアントに配布するDNSサーバーを指定します。
    bash
    # スコープ1で 192.168.1.1 (ルーター自身) を配布
    dhcp scope option 1 DNS 192.168.1.1

  • ip filter
    ファイアウォール設定です。ポート53 (DNS) の通信を制御し、DNSリーク対策などに利用します。

これらのコマンドを組み合わせて、ネットワーク構成やVPNの要件に応じた最適なDNS設定をネットボランチに行います。特にCUIでの設定は、コマンドの入力順序や、設定を有効にするための save や restart コマンドが必要な場合があるため、注意が必要です。

第4章：設定の確認とトラブルシューティング

適切なDNS設定を行った後、それが正しく機能しているかを確認することが重要です。また、名前解決に関する問題が発生した場合のトラブルシューティング方法を知っておくことも役立ちます。

4.1 設定の確認方法

  1. クライアント側のDNSサーバー確認:
    VPN接続を確立したPCやスマートフォンで、現在使用されているDNSサーバーのIPアドレスを確認します。

    • Windows: コマンドプロンプトを開き、ipconfig /all コマンドを実行します。表示される「DNS Servers」のリストを確認します。VPN接続で使用しているネットワークアダプターの項目を確認してください。
    • macOS: ターミナルを開き、scutil --dns コマンドを実行します。VPNインターフェース（例: utun0, ppp0など）に関連付けられたDNSサーバーのアドレスを確認します。
    • Linux: ターミナルを開き、cat /etc/resolv.conf コマンドを実行します。表示される nameserver の行を確認します。

  2. 名前解決の確認:
    特定のホスト名やドメイン名が、意図したIPアドレスに解決されるかを確認します。

    • ping <ホスト名またはドメイン名>
    • nslookup <ホスト名またはドメイン名> [<使用したいDNSサーバーIP>] (特定のDNSサーバーを指定して問い合わせる場合に便利)
    • dig <ホスト名またはドメイン名> @<使用したいDNSサーバーIP> (より詳細なDNS情報を確認できる)

  3. DNSリークテストサイトの利用:
    VPN接続中に、DNSリークが発生していないかを確認できるオンラインサービスがあります。

    • DNS leak test – Test if your VPN is leaking DNS requests
    • ExpressVPN DNS Leak Test
      これらのサイトにアクセスし、「Standard test」または「Extended test」を実行します。表示されるDNSサーバーのIPアドレスが、VPN接続先の国のもの（フルトンネルの場合）や、意図した社内DNSサーバー（分割トンネルで条件付きフォワーディングを利用している場合）になっているかを確認します。ローカルネットワークのISPのIPアドレスが表示される場合は、DNSリークが発生している可能性があります。

  4. ネットボランチのステータス確認:
    ネットボランチのWeb GUIまたはCUIで、DNSサービスの状態やDHCP配布状況などを確認します。

    • CUI: show dns service, show dns server, show dhcp scope <番号>, show ip filter <番号> などのコマンドで設定内容を確認します。

4.2 トラブルシューティング

名前解決ができない、特定のサーバーにアクセスできない、またはDNSリークが疑われる場合、以下の点を確認します。

  1. ネットボランチの設定ミス:

    • ルーター自身のDNS設定 (dns server) は正しいか？
    • DHCPでクライアントに配布するDNSサーバー (dhcp scope option DNS) は正しいか？特にVPN用のDHCPスコープを確認します。
    • 条件付きフォワーディング (dns forwarding zone) の設定は正しいか？ドメイン名と転送先IPアドレスが一致しているか？
    • ファイアウォール設定 (ip filter) で、ポート53 (UDP/TCP) の通信が意図せずブロックされていないか？特に社内DNSサーバーへの通信が許可されているか確認します。また、フィルターの適用方向 (in/out) と適用インターフェースは正しいか？

  2. VPN接続自体の問題:

    • VPN接続は正常に確立されているか？
    • VPNクライアントに割り当てられたIPアドレスは正しいか？
    • VPNトンネルを経由したルーティングは正しく行われているか？（例: ping <社内サーバーIP> が疎通するか）

  3. クライアント側の設定:

    • VPNクライアントソフトウェアの設定は正しいか？VPN接続時にリモートDNSサーバーを使用する設定になっているか？
    • クライアントOSのネットワークアダプターのDNS設定が手動で固定されておらず、DHCPで取得した設定が優先されるようになっているか？（場合によっては手動でVPN側DNSのみを指定する必要があるかもしれません）
    • クライアントOSのHostsファイルに該当ドメイン名のエントリがないか？

  4. DNSサーバー自体の問題:

    • 社内DNSサーバーが正常に稼働しているか？
    • 社内DNSサーバーから、名前解決したいホスト名やドメイン名の情報が正しく応答されるか？（DNSサーバーが設置されているサーバーで nslookup や dig を実行して確認）
    • 社内DNSサーバーからインターネット上のDNSサーバーへのフォワーディング設定は正しいか？

  5. 通信経路上の問題:

    • ルーターやVPN接続先のネットワーク機器で、DNSクエリパケットがブロックされていないか？
    • VPNトンネルの確立に問題はないか？

  6. ログの確認:
    ネットボランチルーターのログ機能（syslog コマンドなどで設定）を確認することで、DNS関連のエラーや、ファイアウォールによるパケットのブロックなど、問題の原因を特定できる場合があります。

これらの確認ポイントを順に追っていくことで、問題の原因を絞り込み、適切な対処を行うことができます。特にファイアウォール設定は複雑になりやすいため、誤った設定が名前解決だけでなく、他の通信にも影響を与える可能性があるため、慎重に確認が必要です。

第5章：より高度な設定と考慮事項

ネットボランチのDNS設定には、さらに高度な機能や考慮すべき点があります。

5.1 DNSキャッシュ機能

ネットボランチは、DNSキャッシュサーバーとして機能することができます。一度名前解決を行った結果を一定期間キャッシュしておき、同じ問い合わせが来た場合にキャッシュから迅速に応答することで、名前解決にかかる時間を短縮し、上位のDNSサーバーへの負荷を軽減できます。

通常、dns service on に設定されていれば、ネットボランチは自動的にDNSキャッシュ機能も有効にします。

5.2 分割DNS (Split-Horizon DNS)

分割DNSは、内部ネットワークからの問い合わせと外部ネットワークからの問い合わせに対して、異なるIPアドレスを応答するDNS設定です。例えば、社内Webサーバー www.example.com が、社内からはプライベートIPアドレス（例: 192.168.10.100）でアクセスでき、外部からはグローバルIPアドレス（例: 203.0.113.50）でアクセスできるような場合に利用されます。

ネットボランチ自身が権威DNSサーバーとして機能するわけではありませんが、条件付きフォワーディング (dns forwarding zone) や、クライアントに配布するDNSサーバーを内部向け/外部向けで分けるといった設定により、分割DNSのような挙動を実現できる場合があります。

例えば、リモートアクセスVPN（分割トンネル）で、VPNクライアントには社内DNSサーバーを配布し、社内DNSサーバーでは社内ドメイン名に対しては内部IPを、外部ドメイン名に対しては外部DNSにフォワードして解決させる、といった設計が考えられます。

5.3 セキュリティに関する追加の考慮事項

  • 信頼できるDNSサーバーの選択: パブリックDNSサーバーを利用する場合、信頼できる提供元（Cloudflare, Google, Quad9など）を選択することが重要です。悪意のあるDNSサーバーは、ユーザーを偽サイトに誘導したり、通信内容を傍受したりする可能性があります。
  • DNS over TLS (DoT) / DNS over HTTPS (DoH): これらのプロトコルは、DNSクエリを暗号化することで、第三者による傍受や改ざんを防ぎ、プライバシーとセキュリティを向上させます。現時点では、ネットボランチルーター自身がこれらのプロトコルで名前解決を行う機能は限定的かもしれませんが、クライアントOSレベルでDoT/DoHを有効にする場合は、ルーターの設定がそれに干渉しないか確認する必要があります。
  • DNSSEC: DNSSEC (Domain Name System Security Extensions) は、DNS応答の正当性を検証するための仕組みです。DNS応答が改ざんされていないことを確認できます。DNSSECを有効にするには、ドメイン名の登録側、権威DNSサーバー側、そして名前解決を行うキャッシュDNSサーバー（またはリゾルバー）側のすべてが対応している必要があります。ネットボランチルーターがDNSSEC検証リゾルバーとして機能するかどうかは機種やファームウェアに依存しますが、対応している場合は有効にすることでセキュリティが向上します。

まとめ

VPNユーザーにとって、DNS設定は単に「インターネットに繋がる」ための設定ではありません。通信のプライバシー、セキュリティ、そして快適なネットワーク利用のために、その重要性を理解し、適切に設定することが不可欠です。特にネットボランチのような多機能ルーターを使用している場合、DHCPによるDNS配布、条件付きフォワーディング、そしてファイアウォールによる制御といった機能を組み合わせることで、VPN環境下での最適な名前解決環境を構築し、DNSリークといったリスクを効果的に防止することができます。

この記事では、DNSの基本から始まり、VPN環境におけるDNSリークの危険性、そしてネットボランチのWeb GUIやCUIでの具体的なDNS関連設定（ルーター自身の設定、DHCP配布設定、VPN環境での設定、条件付きフォワーディング、ファイアウォール）について詳細に解説しました。また、設定後の確認方法やトラブルシューティングのポイント、さらに高度な設定やセキュリティに関する考慮事項についても触れました。

あなたのネットワーク構成やVPNの利用シナリオ（リモートアクセスか拠点間か、フルトンネルか分割トンネルかなど）によって、最適なDNS設定は異なります。本記事で解説した内容を参考に、あなたの環境に合わせた適切な設定をネットボランチに行い、安全で快適なVPN通信を実現してください。設定を行う際には、必ず現在の設定をバックアップし、変更がネットワーク全体に与える影響を十分に考慮して慎重に進めることをお勧めします。不明な点があれば、ヤマハの公式マニュアルやサポート情報を参照することも忘れずに行ってください。

適切なDNS設定は、VPN接続の「見えない」しかし「重要な」基盤です。この機会に、ぜひあなたのネットボランチのDNS設定を見直し、VPN接続をより強固で信頼性の高いものにしてください。

コメントする

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です

上部へスクロール