📚

Yamaha RTXでクライアントの通信すべてをVPN経由で通信させる

2023/09/08に公開

VPN

はじめに

初回掲載時の情報だと結局うまくいかないので、下記の記事は一部書き直してある。

この記事は、自己流でコンフィグを書いていたら微妙に違っていたようなので公式情報に準拠したコンフィグに置き換えた際のメモである。

15年～5年ほど前までは、複数拠点からのインターネットへの通信はすべてセンター側を経由する構成が一般的だった。
センター一極集中型の構成をとる場合、ブランチ側からインターネットへの通信はセンター側と張ったトンネルを経由させる。
センター側の帯域がシビアになるが、一方でセキュリティ対策が1点で行えたメリットはあった。

最近はこの構成は限界があり、ゼロトラストの考えが一般になったためVPNレスの構成も多くなってきたが、そうは言ってもまだまだこういった構成は多いと思う。
この要件を満たす構成をRTXルータのフィルタ型ルーティングを用いて構成したい。

要件：

センター・ブランチともにIPアドレス不定の環境
ブランチはセンターのIPアドレスをネットボランチDNSを用いて解決する。
lan2はインターネット側のIFで、DHCPでアドレス取得する。
センター側のトンネルをtunnnel1で張る。
クライアントセグメント（192.168.50.0/24）からインターネット側の通信はtunnnel1を経由させる。
特定のあて先はlan2を経由して直にインターネットに疎通させる。

前提条件

RTXの初期設定、フィルタ設定は完了しているものとする。適切なポートが空いているものとする。
- RTXの初期設定ウィザードに従えば大丈夫。
すでにTunnnelは疎通しているものとする。

コンフィグ

関係のあるところだけ

# フィルタ型ルーティング
ip route default gateway dhcp lan2 filter 8000000 8000010 8000020 8000030 8000031 8000032 8000100 8000101 8000102 8000103 8000104 8000105 gateway tunnel 1

# ipsec l2tp
ip filter 8000000 pass * * udp * 500
ip filter 8000010 pass * * udp * 4500
ip filter 8000020 pass * * udp * 1701
ip filter 8000030 pass * * esp * *

# RTXが参照する上位DNS
ip filter 8000100 pass * 1.1.1.1,1.0.0.1 tcp,udp * domain

# ネットボランチdns（多分不要）
ip filter 8000101 pass * * tcp * 2002

# 検証用セグメントはlan2経由
ip filter 8000102 pass 192.168.51.0/24 * * *

# リポジトリサーバはlan2経由
ip filter 8000103 pass * 134.160.38.1 * *
ip filter 8000104 pass * 185.125.190.0/24 * *
ip filter 8000105 pass * 91.189.91.0/24 * *


# RTXが参照する上位DNSサーバ
dns server 1.1.1.1 1.0.0.1

# dhcpで払いだすアドレスレンジ
dhcp scope 1 192.168.50.70-192.168.50.100/24
# dhcpで通知するDNSサーバ（RTXが参照する上位DNSとは別にする）
dhcp scope option 1 dns=8.8.8.8,8.8.4.4

フィルタ型ルーティング説明

RTXで用意されているフィルタ型ルーティングを用いる。詳細は http://www.rtpro.yamaha.co.jp/RT/docs/filter-routing/filter-routing.html を参照する。
フィルタ型ルーティングでは事前にパケットフィルタ形式でフィルタを書いておき、合致するパケットは特定のゲートウェイを経由して通信させることが出来る。

書式が分かりにくいが、下記のように書く。

ip route default gateway <インターフェース> filter <←のIFで通信させたい条件のフィルタ番号> gateway <ヒットしない場合のIF>

複数のゲートウェイを列挙することもできる。

# フィルタ1に該当する場合トンネル1、フィルタ2に該当する場合トンネル2を経由する。
ip route default gateway dhcp lan2 filter 1 tunnel 1 filter 2 tunnnel 2

フィルタ型ルーティングは先頭から評価されるようなので、先に引っかかってほしいフィルタから書いていく。

今回の場合、ipsecに必要な通信（とl2tpに必要な通信）で使用するポート・プロトコルはlan2から疎通させる。そのほか、テストセグメントや一部のLinuxリポジトリサーバはlan2を経由させる。それ以外はtunnnel1を経由させる。

今回はlan2のアドレスをdhcpで取得するため lan2 dhcpと記載する。pppoeの場合はpp 1等と記載する。

今回はこのフィルタ型ルーティングを用いて任意のあて先に通信を振り分ける。

勘所

今回の構成は、センタもブランチもIPアドレス不定で、ブランチはセンタのIPアドレスをネットボランチDNSを利用して取得する。
ipsec saを疎通させるために最初にDNSへの通信が必要になる。そのため、ルータからDNSへの通信はlan2を経由する必要がある。
例えば、このような感じである。

ip route default gateway dhcp lan2 filter 8000000 8000010 8000020 8000030 8000100 8000101 8000102 8000103 gateway tunnel 1
ip filter 8000100 pass * 1.1.1.1,1.0.0.1 tcp,udp * domain
dns server 1.1.1.1 1.0.0.1

このようにコンフィグを構成すると、無事にipsec saが生成されVPNは疎通する。しかし、クライアントにdhcpで通知されるdnsサーバも、dns serverで指定したアドレスになり、フィルタ型ルーティングでlan2に流れてしまう。dnsの通信はセキュアDNSを使わない限り暗号化されないので、lan2側の上位設備でアクセスしているfqdnが分かってしまうし、中間者攻撃されてしまう可能性もあり要件を満たさない。

そこで、ネットボランチDNSの名前解決に用いるDNSサーバとクライアントに通知するDNSサーバのIPアドレスを変える。

dns server 1.1.1.1 1.0.0.1
dhcp scope option 1 dns=8.8.8.8,8.8.4.4

dns serverでルータが参照する上位DNSを指定する。ここではCloudflareの公開DNSを利用している。
そのうえでdhcpサーバとしてクライアントに配布するdnsオプションを変更し、Google Public dnsを参照するように変更する。

こうすることで、クライアント側からのDNSクエリはlan2を通る。

udp/53を用いてtracerouteを取得した結果は下記の通り。宛先によって経路が変化していることが分かる。

traceroute -U -p 53 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
 1  _gateway (192.168.50.1)  0.459 ms  0.556 ms  0.763 ms
 2  192.168.1.1 (192.168.1.1)  16.400 ms  16.410 ms  17.322 ms
 3  192.168.2.1 (192.168.2.1)  18.489 ms  18.494 ms  19.395 ms
 4  * * *


traceroute -U -p 53 1.1.1.1
traceroute to 1.1.1.1 (1.1.1.1), 30 hops max, 60 byte packets
 1  _gateway (192.168.50.1)  1.288 ms  1.241 ms  1.224 ms
 2  192.168.11.1 (192.168.11.1)  11.791 ms  11.777 ms  11.762 ms
 3  i125-201-244-4.s99.a049.ap.plala.or.jp (125.201.244.4)  11.748 ms  12.309 ms  12.294 ms
 4  125.201.244.41 (125.201.244.41)  13.265 ms  13.251 ms  14.264 ms

間違った例

下記のようにしてしまうとipsecのための通信もTunnnelを経由しようとしてしまい、結果としてVPNを疎通させることが出来ない。

# tunnnel1に全パケットが流れようとする⇒VPNが疎通しない
ip route default gateway tunnnel 1

余談

今回の構成を応用して、信頼できないネットワークからも安全かつ速度を両立したネットワークを構成することが出来る。

フィルタ型ルーティングを用いると、今流行りのインターネットブレイクアウトを簡易的に実装できる。

RTX830,1210以降であればfqdnを使用したフィルタ型ルーティングにも対応しているため、例えばWindowsUpdateの通信だけをオフロードすることもできる。
私が使っているRTX1200はipベースのポリシールーティングしかできないため、ipアドレス決め打ちできるサーバのみオフロードするようにした。

参考

(RTX)VPNで拠点～センター経由のインターネット接続