フレッツ光の IPoE 環境から IPSec VPN (さくらインターネットの VPCルータサイト間VPN)に接続する
NTT東西が提供するフレッツ光、もしくはそれを卸で仕入れて小売する各社光コラボの回線では、旧来からの PPPoE接続に換えてより高速での通信が期待できる IPoE接続を使うユーザが増えてきている。
しかし、IPoE接続を使う構成では、旧来の PPPoE接続とは通信方法が異なるため、IPSec VPN を使う場合などで不具合が出る。この記事では、IPoE接続のフレッツ光回線を使う環境から、さくらインターネットの IPSec VPN(VPCルータサイト間VPN、以下サイト間VPN)へ接続することができたのでその背景や設定などを紹介する。
IPoE接続が使われる理由
まず、技術的な背景を知っていただくために、旧来からの PPPoE接続と、IPoE接続の違いについてカンタンに説明する。本題である IPSec VPN の問題と直接関係がないので、興味がなければ読み飛ばして頂いて構わない。
日本では、各家庭、各事業所からインターネットに接続する場合、ISP(Internet Service Provider)と呼ばれる事業者と契約して回線を提供してもらう。ISP の中には物理的な回線から接続サービスまですべてを一括して行う場合もあるが、多くの場合は物理的な回線は回線事業者(NTT東西、コミュファ光、au光など)のものを使い、その上での通信部分だけを自社で提供する形を取っている。昔はこの物理回線のところが電話のアナログ回線だったり、ISDN回線だったりしたが、2022年現在はほぼすべて光ファイバ回線になっている。
NTT東西が提供するフレッツ光のシェアが高く、各社光コラボでも物理的には同じ構成になっている。フレッツ光にはいくつかの世代があるが、最新の 10Gbps まで使えるフレッツ光クロスと、旧来のフレッツ光ネクストでは、細かい機器の構成などに差はあるが、どちらも大枠には NGN(Next Generation Network)という規格で作られている。
フレッツ光は物理的な回線なので、インターネットへのリーチャビリティは確保されておらず、インターネットへ接続するには各自が ISP と契約する必要がある。フレッツ光は NTT東西と直接契約して使うこともできるし、ISP がセット販売する光コラボというサービスを使うこともできる。(契約が違うだけで物理的には同じもの)
ISP は契約した顧客からの接続であることを確認してインターネットへ接続するために顧客情報の取得(ID、パスワード)が必要になる。電話回線(アナログ、ISDN)の場合は PPP(Point-to-Point Protocol、RFC1661) というプロトコルが使われていたがフレッツ光の場合は、PPPoE(PPP over Ethernet、RFC2516) というプロトコルに置き換えられた。
PPPoE ではユーザから ID とパスワードを送出、ISP側でそこから契約情報と突き合わせ、接続を提供する。仕組みとしては難しいものではなく、光ファイバ普及の上では大いに貢献してきたと考えられる。
初期のころのフレッツ光を除くと、フレッツ光ネクスト以降は NGN という規格になっており、各家庭各事業所に置かれる ONU～NTT局舎間の通信には IPv6 が使われる。前述の PPPoE も背景としてはこの IPv6通信の上で行われている。
[ネットワーク構成]
ISP各社
||
||
+----------------+
| NTE(47都道府県) |
+----------------+
||
NTT東西
||
|| PPPoE
||
+-------------+
| ONU + HGW |
| (ユーザ宅) |
+-------------+
| 192.168.1.1
|
-------+------- 192.168.1.0/24
そのうち、各社PPPoE の接続数が増えてきたのに伴い、NTT東西が ISP各社との接続インタフェイスとして設置している NTE(Network Termination Equipment) の設備が逼迫する問題が表面化してきた。ユーザサイドから見ると、混み合う時間になると回線速度が出なくなる、という状況になる。この回線速度の低下は、ISP のバックボーンに起因するものではなく、NTE の容量不足のため、ISP側では直接的な解決ができない。NTE の設置、増設は NTT東西が決めており、NTT東西としてはコストが掛かる設備投資になるため、増設に前向きとは言えない状況になっていた。余談だが、この NTE は 47都道府県に設置されている。(NTT東西は歴史的な背景から都道府県をまたぐ通信を提供しないため)
回線速度が上がらなければ、インターネット接続サービスとしての商品力が低下するので、ISP各社はこの NTE能力不足の問題の解決に当たることになり、NTE を使わない接続方式、IPoE を導入、普及させていくことになった。
前置きが長くなったが、2022年現在、ISP各社が IPoE接続のサービスを売出し、IPoE接続に変えると回線速度が速くなる理由はここにある。結論だけ言えば IPoE接続が速いわけではなく、PPPoE接続が遅かったのである。なお、IPoE接続に変えると速度が速くなる理由として IPv6 での接続が可能になるためと説明しているサイトがあるがこれはほぼ間違った説明であり、IPv6 での接続は IPoE接続の副次的な効果であり、IPv4 だけ使う場合も、PPPoE接続より IPoE接続のほうが仕組みの上では高速になる。(経路の中でトラヒックの集中する NTT東西の NTE を経由しないため)
この IPoE接続はどういうものかというと、NGN の基盤となっていた IPv6 の通信を、ユーザONU～NTT東西間の通信だけでなく、インターネットの接続まで使ってしまおう、というある意味、すでにある仕組みを流用する形で作られた。
ここで、IPoE導入に際して、技術的な課題が出てきた。NGN で使う IPv6 は NTT東西が管理するアドレスであり、インターネットには接続していない。インターネットまで疎通するには ISP の管理する IPv6アドレスが必要であり、これをユーザONU まで通す必要がある。
しかし、NGN はインターネットの接続だけを行っているわけではなく、NTT東西のひかり電話といったサービスのインフラともなっており、単純に ISP の管理するアドレスを振り出せばいい、ということにならない。
そこで NTT東西は、数社の VNE(Virtual Network Enabler) という事業者と個別に接続し、各ISP は VNE から接続を仕入れる、という形で落ち着いた。各ISP は顧客と契約、集金、サポートといった業務を請負い、回線に関しては VNE から卸販売を受ける、といったいわば回線販売代理店のような形になる。
[ネットワーク構成]
VNE各社 -> ISP各社に卸売り
||
||
+------------------+
| GRE(東西各1拠点) |
+------------------+
||
NTT東西
||
|| IPoE
||
+-------------+
| ONU + HGW |
| (ユーザ宅) |
+-------------+
| 2001:db8::1
|
-------+------- 2001:db8::/64VNE は大手では、KDDI系の JPNE、IIJ系のインターネットマルチフィード(以下MFeed)、SoftBank系の BBIX があり(初期参入の 3社)、後に接続事業者拡大に伴い、NTTコミュニケーションズや朝日ネットなども参入した。
巷に ISP は何百社と存在するが、IPoE接続で提供されるサービスは、どこかの VNE から仕入れたものを使っている。独立系 ISP の場合は、複数の VNE と契約し、回線ごとに VNE が違う場合もある。(古参ISP の DTI など)
IPoE 接続による IPv4 over IPv6 の方式
IPoE 接続は仕組みとしては上記で説明した通り、NGN のインフラとして使う IPv6回線を、インターネットの接続にも流用するというものであり、そのために VNE事業者が存在する、というだけでシンプルでわかりやすいものだ。しかし、IPoE接続は IPv6 のみで構成されているため、99.9%以上のユーザが必要としているであろう、IPv4 によるインターネットへのリーチャビリティは提供されない。
これでは ISP としてサービスにならないため、IPv4 による接続サービスを、IPv4 over IPv6 という仕組みを使って実装し、ユーザに提供している。
この具体的な実装は、VNE各社によって違うが、KDDI系JPNE では v6プラス、IIJ系MFeed では transix、SoftBank系BBIX では高速ハイブリッドサービスという名称で提供している。実装は v6プラスは MAP-E、transix は DS-Lite、高速ハイブリッドサービスは独自の IPIPトンネルを用いており、各ユーザ拠点と VNE の両方に変換を行うブリッヂが存在し、IPv4 のパケットを カプセル化した上で IPv6パケットとして通信している。各ユーザ拠点側の実装は、NTT東西からレンタルできる HGW上のソフトウェアとして動作させるのが一般的だが、HGW を使わずユーザが自前で用意したルータなど(YAMAHA RTシリーズなど)に機能が実装されていればそれを使うことができる。
[ネットワーク構成]
JPNE
||
||
+------------------+
| GRE(東西各1拠点) |
+------------------+
||
NTT東西
||
|| IPoE
||
+----------------------------+
| ONU + HGW + MAP-E + NAPT |
| (ユーザ宅) |
+----------------------------+
| 2001:db8::1
| 192.168.1.1
|
-------+------- 2001:db8::/64
192.168.1.0/24
ベストセラーであり企業での普及率が圧倒的に高い YAMAHA RTシリーズでは新しいファームウェアを使うことで、v6プラスと transix に対応することができる。
なお、BBIX(他社に販売していないため、SoftBank専用)が提供する高速ハイブリッドサービスは、独自規格の IPIPトンネルを使う方式のため、YAMAHA をはじめとした社外製ルータを使うことができず、SoftBank からレンタルする BB光ユニットを使う必要がある。
[ネットワーク構成]
BBIX
||
||
+------------------+
| GRE(東西各1拠点) |
+------------------+
||
NTT東西
||
|| IPoE
||
+--------------+
| ONU + HGW |
| (ユーザ宅) |
+--------------+
| 2001:db8::1
|
|
+-----------------------+
| BB光ユニット |
| IPv4 over IPv6 tunnel |
+-----------------------+
| 192.168.3.1
|
|
-------+------- 2001:db8:abcd:ef10::/64
192.168.3.0/24余談だが、SoftBank は高速ハイブリッドサービスを使うためには、BB光ユニットのレンタルが必要であるとしているが、これは IPv4 over IPv6 の通信を行うために使うだけであり、IPoE による IPv6接続だけでよければ、BB光ユニットのレンタルは必要ない。(そんなユーザが存在するかはわからない。外部に独自の IPIPトンネルのためのルータを所有し、そこと IPv6 でトンネルを張り、IPv4 のパケットはそのトンネルへ通過するような構成を取るのであれば、たしかに不要かもしれない。しかしそれなら、SoftBank の契約すら不要で、フレッツ光の v6オプション(IPv6折り返し)を使えばよいのだが、、、)
IPv4 over IPoE IPv6 を使う弊害
ほとんどのユーザでは、IPv4 が PPPoE で提供されていても、IPv4 over IPoE IPv6 で提供されていても、通信速度に違いがあるといった程度の差異しかなく、困ることはないと思う。
しかし、一部の特殊な構成では、IPv4 over IPoE IPv6 を使うことで不都合がでてくる。具体的には、グローバルIPv4アドレスの占有だ。
PPPoE による接続では、グローバルIPv4アドレスを他のユーザと共有しているが、接続中であれば割り当てられたブローバルIPv4アドレスを占有して使うことができる。接続ごとにアドレスが変わるため、固定IPアドレスとは違うものの、半固定といってよい運用ができる。
ポート開放を必要とするサービス(一部のオンラインゲームなど)では、占有するグローバルIPv4アドレスが必要だが、PPPoE による接続では、ユーザ宅内のブロードバンドルータの設定(ポート転送など)を使うことで実現できた。
しかし、IPv4 over IPoE IPv6サービスで提供される方式のうち、MAP-E や transix では、1つのグローバルIPv4アドレスを、「同時に」複数のユーザで共有する仕組みになっているためグローバルIPv4アドレスを必要とするサービスが使えない。1つのグローバルIPv4アドレスを複数のユーザで共有するために、ポートを区分して割り当てるといったことが行われており、ポートを指定する必要のあるサービスは全般的に使えないと考えてよい。
この、グローバルIPv4アドレスが必要になるサービスの一つが、IPSec VPN を使った接続で、IPSec VPN の場合は、VPNルータ自身がグローバルIPv4アドレスを持つ必要がある。IPSec ではパケットの書き換えが不可能なため(そもそも通信が暗号化されている上、書き換え = 改ざん、なので IPSec の意図からしたらありえない)、ブロードバンドルータで実装されるポート転送といった機能では実現し得ない。
PPPoE接続の場合は、PPPoE接続を行ったルータ自身がグローバルIPv4アドレスを持つので、ルータから IPSec VPN を張ることで問題なく使える。しかし、IPv4 over IPoE IPv6接続はグローバルIPv4アドレスが割り当てられないのでルータから IPSec VPN を張ることができない。
IPv4 over IPoE IPv6サービスのうち、SoftBank系BBIX の高速ハイブリッドサービスは、各ユーザに占有のグローバルIPv4アドレスを割り当てている。しかしこのグローバルIPv4アドレスは、BB光ユニット内部に割り当てられてしまい、ユーザは BB光ユニットが提供する NAPT配下からしかパケットの疎通ができない。BB光ユニットには IPSec VPN の接続のための機能が実装されていないので、IPSec VPN を使うことができない。
IPoE接続環境化からの、IPSec VPN 接続の実装
ここまで、フレッツ光(NTT NGN)に IPoE接続が提供されるようになった背景、IPoE接続の上で提供される IPv4 over IPv6サービスの概要をカンタンに解説した。以下、この環境で IPSec VPN 接続を実現した実装を紹介する。
具体的なサービスとして、光回線は NTT西日本のフレッツ光ネクスト(ひかり電話契約あり)、ISP契約は SoftBank系の Yahoo!BB光フレッツコース、拠点ルータは YAMAHA RTX1200、IPSec VPN の接続先はさくらインターネットの VPCルータサイト間VPN、を使った。
まず物理的な構成としては、NTT西日本から ONU一体型の HGW、SoftBank からは BB光ユニット(E-WMTA2.4)をレンタルし、HGW の LAN側端子に、BB光ユニットを接続する。
HGW の LAN側端子は標準設定では DHCP が動作しているが、これは停止させてある。DHCP が動いている場合、BB光ユニットの WAN側端子に HGW LAN から割り振られたプライベートIPv4アドレスが付与されるが、BB光ユニットは(HGW から RA で配布された)IPv6 を使って HGW/ONU と疎通するので、ここの設定は動作に影響しない。
BB光ユニットの LAN側端子を、RTX1200 の LAN3 に接続する。
BB光ユニットの LAN側端子は DHCP が動作しており、これは設定で変えられない。RTX1200 の LAN3 で dhcp client service を動作させると、BB光ユニットの DHCP から割り振られたプライベートIPv4アドレスが付与される。標準設定の場合、192.168.3.0/24 のネットワークが使われる。
この構成で、RTX1200 の LAN1 に NAPT を動作させ、IPv4、IPv6 のルーティングを、BB光ユニット(ip lan3 dhcp/ipv6 lan3 dhcp)に向けるだけで、インターネットに接続できる。RTX1200 が冗長であって本来は必要ないが、このような多段ルータ構成であってもネットワークとしては使える状態になる。(BB光ユニットの NAPT と RTX1200 の NAPT が多重になるのであまりうれしい状況ではない)
[ネットワーク構成]
BBIX
||
||
+------------------+
| GRE(東西各1拠点) |
+------------------+
||
NTT東西
||
|| IPoE
||
+--------------+
| ONU + HGW |
| (ユーザ宅) |
+--------------+
| 2400:2651:abcd:cb00:225:36ff:fe38:1234
|
|
+-------------------------+
| BB光ユニット(E-WMTA2.4) |
| IPv4 over IPv6 tunnel |
+-------------------------+
| 2400:2651:abcd:cb00:1111:1111:1111:1111
| 192.168.3.1
|
| 2400:2651:abcd:cbf3::1
| 192.168.3.254
+----[LAN3]----+
| RTX1200 |
| IPv4 NAPT |
+----[LAN1]----+
| 2400:2651:abcd:cbf1::1
| 172.30.128.254
|
-------+------- 2001:2651:abcd:cbf1::/64
172.30.128.0/24この構成だと、IPSec VPNルータとなる RTX1200 はグローバルIPv4アドレスを付与されないので、さくらインターネットのサイト間VPN を使うことができない。
ここで苦肉の策として出てきたのが、「IPoE環境だけど、あえての PPPoE接続を使う」という構成である。
すでに IPoE、そして IPv4 over IPv6 のサービスが動いているため、インターネットへの接続は問題なく行えているが、サイト間VPN を使うために、別途PPPoE接続も使う、という構成をとる。
Yahoo!BB光フレッツコースでは契約した時点で PPPoEアカウントを払い出され、回線を IPoE接続に変更したあとも、この PPPoEアカウントは引き続き使用することができる。ケチくさい話だが、1回線を IPoE接続で使っておいて、別の拠点でフレッツ光を契約してそちらで PPPoE接続を使うことも、技術的には不可能ではない。(つまり、1契約で 2拠点から接続する)
PPPoEアカウントが無効化されない理由としては、ユーザ宅内で BB光ユニットの配下にブロードバンドルータを設置して、そこに PPPoE の設定を入れているユーザなどがトラブって、サポートするコストを勘案すると、2回線分のサービスになってしまってもトータルで安いという判断があるのかもしれない。(今後の仕様変更で、IPoE接続に変更したユーザでは PPPoEアカウントが無効になる可能性もある)
RTX1200 から PPPoE で接続すると、RTX1200自身がグローバルIPv4アドレスを持つことができる。そして RTX1200 からこのアドレスを使えば IPSec VPN を張ることができる。物理的には HGW配下の BB光ユニット配下になっていて、多段ルータ構成に見えるが、RTX1200自体は HGW から RA で配布される IPv6アドレスを持っており、PPPoE はこの IPv6経路で ISP側の PPPサーバと通信しているので、経路的には多段ルータになっていない。(多段ルータとは、NAPT を使用する IPv4環境での構成のことで、IPv6 はほぼすべての環境で NAPT を使用せずスルーする)
[ネットワーク構成]
BBIX SoftBank
|| ||
|| ||
+------------------+ +-----+
| GRE(東西各1拠点) | | VNE |
+------------------+ +-----+
|| ||
||================||
NTT東西
||
|| IPoE + PPPoE
||
+--------------+
| ONU + HGW |
| (ユーザ宅) |
+--------------+
| 2400:2651:abcd:cb00:225:36ff:fe38:1234
|
|
+-------------------------+
| BB光ユニット(E-WMTA2.4) |
| IPv4 over IPv6 tunnel |----------+
+-------------------------+ |
| 2400:2651:abcd:cb00:1111:1111:1111:1111
| 192.168.3.1 |
| |
| 2400:2651:abcd:cbf3::1 |
| 192.168.3.254 | Global IPv4
+----[LAN3]------------------------[PPPoE]---+
| RTX1200 |
| IPv4 NAPT / IPv4 PPPoE |
+----[LAN1]----------------------------------+
| 2400:2651:abcd:cbf1::1
| 172.30.128.254
|
-------+------- 2001:2651:abcd:cbf1::/64
172.30.128.0/24RTX1200 では、サイト間VPN で使う対向ルータ(さくらインターネット側のルータ)宛の IPv4 のルーティングだけ、PPPoE接続へ流し、それ以外のパケットは LAN3 へ送ってしまえばよい。
ip routing on
ip route default gateway 192.168.3.1
ip route 27.133.132.134 gateway pp 1
ip route 172.30.251.0/24 gateway tunnel1
show ip route
宛先ネットワーク ゲートウェイ インタフェース 種別 付加情報
default 192.168.3.1 LAN3 static
27.133.132.134/32 - PP[01] static
172.30.128.0/24 172.30.128.254 LAN1 implicit
172.30.251.0/24 - TUNNEL[1] static
192.168.3.0/24 192.168.3.254 LAN3 implicit192.168.3.1 は LAN3 の先に居る BB光ユニットのアドレス、27.133.132.134 はサイト間VPN で使う対向ルータの IPアドレス、172.30.251.0/24 はサイト間VPN の先にあるネットワークである。
pp1 は PPPoE接続、tunnel1 はサイト間VPN である。
BB光ユニットを通さない PPPoE と IPv6
以上の構成を取ることで、IPoE環境にあるネットワークからも、サイト間VPN を使うことができた。この構成の場合、ネットワーク的には IPv6 で直接外へ疎通できているので問題ないものの、この構成で不要な BB光ユニットを物理的に介してしまっている。これは障害発生ポイントになることも考えられるので、さらに一歩、構成を工夫して BB光ユニットを経由しない構成にする。
RTX1200 は(ブロードバンドルータとは違って)本当のルータなので LAN1、LAN2、LAN3 というネットワークを物理的に構成できる。いまは、LAN1 に LAN、LAN3 に BB光ユニット経由の WAN環境を割り当てているので、余った LAN2 が使える。
構成はカンタンで、この LAN2 を HGW の LAN に繋いでしまえば良い。HGW の DHCP は殺してあるが、LAN2 で dhcp client service を稼働させなければ実害無いので動いていても問題ない。
[ネットワーク構成]
BBIX SoftBank
|| ||
|| ||
+------------------+ +-----+
| GRE(東西各1拠点) | | VNE |
+------------------+ +-----+
|| ||
||================||
NTT東西
||
|| IPoE
||
+--------------+
| ONU + HGW |
| (ユーザ宅) |---------------------+
+--------------+ |
| 2400:2651:abcd:cb00:225:36ff:fe38:1234
| |
| |
+-------------------------+ |
| BB光ユニット(E-WMTA2.4) | |
| IPv4 over IPv6 tunnel | |
+-------------------------+ |
| 2400:2651:abcd:cb00:1111:1111:1111:1111
| 192.168.3.1 |
| |
| 2400:2651:abcd:cbf3::1 |
| 192.168.3.254 | Global IPv4
+----[LAN3]-------------------- [LAN2/PPPoE]-+
| RTX1200 |
| IPv4 NAPT / IPv4 PPPoE |
+----[LAN1]----------------------------------+
| 2400:2651:abcd:cbf1::1
| 172.30.128.254
|
-------+------- 2001:2651:abcd:cbf1::/64
172.30.128.0/24LAN2 は IPv4 の通信は行わないので、RTX1200 で設定は不要である。いままでは、IPv6 の通信も LAN3 から BB光ユニット経由で行っているが、IPoE IPv6 は HGW の時点で疎通できるので、HGW から DHCPv6 でアドレスを割り当ててもらい、これを使うことができる。(ひかり電話契約が無い環境だと、DHCPv6 が使えない上、拠点用の IPv6 RA は BB光ユニットに取られてしまっているはずなのでこの構成が取れない(未確認))
no ipv6 lan3 address dhcp # <== BB光ユニット経由の IPv6 を無効化する
no ipv6 lan3 dhcp service client
ipv6 routing on
ipv6 routing default gateway dhcp lan2
ipv6 lan1 address dhcp-prefix@lan2::1:0:0:0:1/64
ipv6 lan2 address dhcp # <== HGWから DHCPv6 でアドレスをもらう
ipv6 lan2 dhcp service client
ipv6 prefix 1 fe80::1/64
ipv6 prefix 2 dhcp-prefix@lan2::1:0:0:0:1/64 # <== HGW からもらったアドレスを /64 で切って LAN1 に RA で配布
ipv6 lan1 rtadv send 1 2RTX1200 での PPPoE接続の設定は割愛。
tunnel select 1
ipsec tunnel 101
ipsec sa policy 101 1 esp aes-cbc sha-hmac
ipsec ike always-on 1 on
ipsec ike encryption 1 aes-cbc
ipsec ike group 1 modp1024
ipsec ike hash 1 sha
ipsec ike keepalive log 1 off
ipsec ike keepalive use 1 on dpd 15 2
ipsec ike local address 1 172.30.128.254
ipsec ike local id 1 172.30.128.254
ipsec ike pfs 1 on
ipsec ike pre-shared-key 1 text **PRE-SHARED-KEY**
ipsec ike remote address 1 27.133.132.134
ipsec ike remote id 1 172.30.251.0/24
ipsec auto refresh 1 on
ip tunnel mtu 1280
ip tunnel tcp mss limit auto
tunnel enable 1IPSec VPN の設定はさくらインターネットのサポートなどで紹介されているものがそのまま使える。
確認
この設定を行った状態で、RTX1200 の LAN1 につながった端末から、tracert してみる。
まずは、BB光ユニット経由の IPv4 over IPv6 の場合。
C:\>tracert -4 www.google.com
www.google.com [142.250.206.196] へのルートをトレースしています
経由するホップ数は最大 30 です:
1 <1 ms <1 ms <1 ms 172.30.128.254
2 1 ms 1 ms 1 ms 192.168.3.1
3 6 ms 5 ms 5 ms softbank221111179190.bbtec.net [221.111.179.190]
4 6 ms 5 ms 5 ms softbank221111179189.bbtec.net [221.111.179.189]
5 6 ms 6 ms 6 ms 10.9.203.130
6 6 ms 6 ms 6 ms 72.14.214.193
7 9 ms 8 ms 9 ms 108.170.235.199
8 7 ms 6 ms 6 ms 142.250.236.35
9 6 ms 6 ms 7 ms kix07s07-in-f4.1e100.net [142.250.206.196]
トレースを完了しました。172.30.128.254 は RTX1200 のアドレス(端末から見て、デフォルトゲートウェイに設定してある)、192.168.3.1 は BB光ユニットの LAN側端子のアドレス。
次に、BB光ユニットを経由しない IPoE IPv6 の場合。
C:\>tracert www.google.com
www.google.com [2404:6800:400a:80e::2004] へのルートをトレースしています
経由するホップ数は最大 30 です:
1 <1 ms <1 ms <1 ms 2400:2651:abcd:cbf1::1
2 1 ms 1 ms <1 ms 2400:2651:abcd:cb00:225:36ff:fe38:1234
3 * * * 要求がタイムアウトしました。
4 * * * 要求がタイムアウトしました。
5 * * * 要求がタイムアウトしました。
6 4 ms 4 ms 4 ms 2400:2000:bb1a:310d::1
7 7 ms 5 ms 6 ms 2400:2000:2:0:1a:0:2:21
8 7 ms 5 ms 5 ms 2400:2000:0:201:1:5169:1011:2
9 6 ms 6 ms 5 ms 2404:6800:8046::1
10 5 ms 5 ms 5 ms 2001:4860:0:1::18fe
11 5 ms 4 ms 5 ms 2001:4860:0:1::3c77
12 6 ms 4 ms 5 ms kix07s06-in-x04.1e100.net [2404:6800:400a:80e::2004]
トレースを完了しました。2400:2651:abcd:cbf0::/60 が HGW から DHCPv6 で配布されたネットワークで、2400:2651:abcd:cbf1::1/64 は RTX1200 の LAN1 に付与したアドレス(設定の ipv6 lan1 address dhcp-prefix@lan2::1:0:0:0:1/64 に該当)。
2400:2651:abcd:cb00::/56 が HGW が IPoE で配布されたネットワークで、2400:2651:abcdcb00:225:36ff:fe38:1234 が HGW が使用するアドレス。
これを見てわかる通り、IPv6 のパケットは BB光ユニットを経由せず、RTX1200 から直接HGW へ抜けている。
C:\>tracert 27.133.132.134
27.133.132.134 へのルートをトレースしています。経由するホップ数は最大 30 です
1 <1 ms <1 ms <1 ms 172.30.128.254
2 2 ms 2 ms 2 ms softbank219188247026.bbtec.net [219.188.247.26]
3 3 ms 3 ms 4 ms softbank219188244017.bbtec.net [219.188.244.17]
4 8 ms 8 ms 8 ms 10.9.203.106
5 8 ms 8 ms 7 ms tkort4-as17676.bb.sakura.ad.jp [157.17.130.129]
6 8 ms 8 ms 8 ms tkwrt301s-ort4.bb.sakura.ad.jp [157.17.131.166]
7 25 ms 25 ms 29 ms tkdrt2b-wrt301s.bb.sakura.ad.jp [157.17.131.222]
8 8 ms 9 ms 8 ms sac-tk1a-rt11-tkdrt2b-2.bb.sakura.ad.jp [157.17.136.246]
9 * * * 要求がタイムアウトしました。
10 8 ms 8 ms 9 ms 27.133.132.134
トレースを完了しました。
最後に、VPCルータ宛だけはパケットの流れが違う。Google宛の時は、192.168.3.1(BB光ユニット)へ送られていたパケットが、直接SoftBank のルータへ流れていることがわかる。
なお、今回は IPoE接続の実例として Yahoo!BB光フレッツコース(SoftBank)を使ったが、IPoE の仕様は大きく異なるものではないので、他社の契約でも使えると思う。ただし、Yahoo!BB光フレッツコースのように、IPoE接続で使っている場合でも、別途有効になる PPPoEアカウントがもらえる場合に限る。もし、PPPoEアカウントが用意されない ISP の場合は、BB .excite コネクト PPPoE というプランが 550円/月で利用できるので、こういったサービスを契約してしまえば良い。Netflix などを IPv4 over IPv6 で高速に利用したいが、同時にオンラインゲームなどで占有IPv4アドレスが必要というユーザの場合も、この構成がそのまま使える。
おまけ
IPv6 と IPv4 over IPoE IPv6 と IPv4 PPPoE で送出できるパケットのサイズをみてみる。
まずは、IPv6 の場合、
C:\>ping -l 1452 www.google.com
www.google.com [2404:6800:400a:80a::2004]に ping を送信しています 1452 バイトのデータ:
2404:6800:400a:80a::2004 からの応答: 時間 =5ms
2404:6800:400a:80a::2004 からの応答: 時間 =5ms
2404:6800:400a:80a::2004 からの応答: 時間 =5ms
2404:6800:400a:80a::2004 からの応答: 時間 =5ms
2404:6800:400a:80a::2004 の ping 統計:
パケット数: 送信 = 4、受信 = 4、損失 = 0 (0% の損失)、
ラウンド トリップの概算時間 (ミリ秒):
最小 = 5ms、最大 = 5ms、平均 = 5ms
C:\>ping -l 1453 www.google.com
www.google.com [2404:6800:400a:80a::2004]に ping を送信しています 1453 バイトのデータ:
要求がタイムアウトしました。
要求がタイムアウトしました。
要求がタイムアウトしました。
要求がタイムアウトしました。
2404:6800:400a:80a::2004 の ping 統計:
パケット数: 送信 = 4、受信 = 0、損失 = 4 (100% の損失)、IPv6 のパケットは 1,452 bytes まで。
IPv4 over IPoE IPv6(BB光ユニット経由)の場合。
C:>ping -4 -l 1432 www.google.com
www.google.com [142.250.76.132]に ping を送信しています 1432 バイトのデータ:
142.250.76.132 からの応答: バイト数 =68 (1432 を送信) 時間 =6ms TTL=117
142.250.76.132 からの応答: バイト数 =68 (1432 を送信) 時間 =6ms TTL=117
142.250.76.132 からの応答: バイト数 =68 (1432 を送信) 時間 =6ms TTL=117
142.250.76.132 からの応答: バイト数 =68 (1432 を送信) 時間 =6ms TTL=117
142.250.76.132 の ping 統計:
パケット数: 送信 = 4、受信 = 4、損失 = 0 (0% の損失)、
ラウンド トリップの概算時間 (ミリ秒):
最小 = 6ms、最大 = 6ms、平均 = 6ms
C:>ping -4 -l 1433 www.google.com
www.google.com [142.250.76.132]に ping を送信しています 1433 バイトのデータ:
要求がタイムアウトしました。
要求がタイムアウトしました。
要求がタイムアウトしました。
要求がタイムアウトしました。
142.250.76.132 の ping 統計:
パケット数: 送信 = 4、受信 = 0、損失 = 4 (100% の損失)、IPv4 のパケットは 1,432 bytes まで。20bytes がカプセリングのために使われている。
最後に、IPv4 PPPoE の場合。
C:>ping -4 -f -l 1426 27.133.132.134
27.133.132.134 に ping を送信しています 1426 バイトのデータ:
27.133.132.134 からの応答: バイト数 =1426 時間 =15ms TTL=55
27.133.132.134 からの応答: バイト数 =1426 時間 =9ms TTL=55
27.133.132.134 からの応答: バイト数 =1426 時間 =9ms TTL=55
27.133.132.134 からの応答: バイト数 =1426 時間 =9ms TTL=55
27.133.132.134 の ping 統計:
パケット数: 送信 = 4、受信 = 4、損失 = 0 (0% の損失)、
ラウンド トリップの概算時間 (ミリ秒):
最小 = 9ms、最大 = 15ms、平均 = 10ms
C:>ping -4 -f -l 1427 27.133.132.134
27.133.132.134 に ping を送信しています 1427 バイトのデータ:
パケットの断片化が必要ですが、DF が設定されています。
パケットの断片化が必要ですが、DF が設定されています。
パケットの断片化が必要ですが、DF が設定されています。
パケットの断片化が必要ですが、DF が設定されています。
27.133.132.134 の ping 統計:
パケット数: 送信 = 4、受信 = 0、損失 = 4 (100% の損失)、フレッツ光の PPPoE の仕様通り、MTU 1,426 bytes まで。
最後に、IPv4 over VPN over IPoE PPPoE の場合。
C:>ping -4 -f -l 1252 172.30.251.101
172.30.251.101 に ping を送信しています 1252 バイトのデータ:
172.30.251.101 からの応答: バイト数 =1252 時間 =9ms TTL=62
172.30.251.101 からの応答: バイト数 =1252 時間 =9ms TTL=62
172.30.251.101 からの応答: バイト数 =1252 時間 =9ms TTL=62
172.30.251.101 からの応答: バイト数 =1252 時間 =9ms TTL=62
172.30.251.101 の ping 統計:
パケット数: 送信 = 4、受信 = 4、損失 = 0 (0% の損失)、
ラウンド トリップの概算時間 (ミリ秒):
最小 = 9ms、最大 = 9ms、平均 = 9ms
C:>ping -4 -f -l 1253 172.30.251.101
172.30.251.101 に ping を送信しています 1253 バイトのデータ:
パケットの断片化が必要ですが、DF が設定されています。
パケットの断片化が必要ですが、DF が設定されています。
パケットの断片化が必要ですが、DF が設定されています。
パケットの断片化が必要ですが、DF が設定されています。
172.30.251.101 の ping 統計:
パケット数: 送信 = 4、受信 = 0、損失 = 4 (100% の損失)、1,252 bytes まで。
おまけのおまけ
どうも、BB光ユニットの挙動を確認したところ、LAN側インタフェイス(デフォルトだと 192.168.3.0/24)からのパケットであれば DHCP で払い出した IPアドレスではなくてもちゃんと NAPT/ルーティングしてくれるようなので、RTX1200 の NAPT のポートを節約する必要はなく、単純な NAT で使える。(BB光ユニットの LAN側インタフェイスに一切他の機器を繋がない構成の場合)
この場合、BB光ユニット自身のアドレス(192.168.3.1)を除いた IPアドレス(192.168.3.2～192.168.3.254)は RTX1200側で自由に使えるので、NAT の address outer として使うことでポート変換が必要なくなり(IP対IPだけ)、NAT table を節約できる。
BB光ユニットの LAN側インタフェイスの IPアドレスが 192.168.3.1、RTX1200 の LAN 3 の IPアドレスが 192.168.3.254 、LAN1 の IPアドレスが 172.31.0.254/24(兼dhcp server) ある場合の設定例は以下の通り。
ip routing on
ip route default gateway 192.168.3.1
ip lan1 address 172.31.0.254/24
ip lan3 address 192.168.3.254/24
ip lan3 nat descriptor 301
nat descriptor type 301 nat-masquerade
nat address outer 301 192.168.3.2-192.168.3.253
nat address inner 301 172.31.0.1-172.31.0.254
dhcp service server
dhcp scope 1 172.31.0.11-172.31.0.89/24これで、LAN1 に接続した端末は、DHCP で振られたアドレス(例えば、172.31.0.11/24)からパケットを投げると、RTX1200 の NAT で適当なアドレスに変換され(例えば 192.168.3.2)、BB光ユニットは自身の LAN側に 192.168.3.2 という端末が接続されているものとして NAPT、WAN側へルーティングしてくれる。
上記の設定にはフィルタ類が書かれていないので適宜、追加して欲しい。
NAPT を使おうと思うと、NATテーブル数の制約(RTX1200 は始点ホストごとに 20,000 まで。後継機の RTX1210/RTX1220 は 65,536 まで。BB光ユニットは不明)があるため、できるだけソースIPアドレスは分散させたい。BB光ユニットも今どきのハードウェアなので、それほど制約が見えるとは思わないものの、使い方によっては NATテーブルを使い切ってしまう可能性もある。
ふつうのウェブサイトの閲覧なんかでは問題ないが、社内から特定のクラウドサービスを使っていたりすると、数十台のマシンが同じ IPアドレス宛に通信する、という可能性が出てくる。
IP通信では、ソースIPアドレス、ソースIPポート、宛先IPアドレス、宛先IPポートの 4通りの組み合わせで NAPT を組んでいくので、4 つが分散していればそれほど問題はないが、宛先IPアドレスや宛先IPポートが重複するような通信が多い場合は、ソースIPアドレスとソースIPポートしか分散の要素がなくなってしまう。
これが、単純な PPPoE + NAPT の場合であれば、外部へ出ていく WAN側IPアドレスが 1つ、社内LAN は各自が IPアドレスを持っているとして NATテーブルの限界まで使えるが、BB光ユニットの配下に別の NAPTルータを設置するような今回のような構成のような 2段ルータ状態になっていると、WAN側IPアドレスと 2段目ルータの WAN側IPアドレスが 1つずつになってしまい、最大で 65,536 経路までしか同時に通信できないことになってしまう。(もちろん、宛先IPアドレスはある程度分散するので、現実的には使い切ることはないと思われる。しかし、NATテーブルは 1,800秒程度は経路を保持するので、この間は開放されないと考えると同時では発生しなくても、30分で使い切ることはありうる)
2段目ルータの WAN側IPアドレスを 250個に分散できれば、単純に 250倍程度の経路までは張れることになる。(もちろん、NAPT以外の要素での制約も出てくるので単純に 250倍にはならない)
むかしはアプリケーションは 1つのポートしか使わないようなお行儀のよいものが当たり前で、FTP のように 2つ以上のポートを使うようなアプリケーションは特殊な部類とも考えていたが、昨今のアプリケーションでは TCP/IP などのデメリットを回避するために UDP/IP を使って上のレイヤーであれこれやってたりして(SIP/RTP もそのアプリケーションの一種)、1つのアプリケーションが何十個ものセッションを同時に張りにいく、なんてことも許されるようになってきた。これによってルータが想定してた使い方をはるかに超えるセッション数が発生してしまい、NATテーブルが制限に達する、という事情が発生してくる。YAMAHA などメーカも対策していて、以前は宛先ごとにランダムに使っていたソースIPポートを、違う宛先間で共有するといった、ポートセービングIPマスカレードといった実装も行っている。
さいごに
技術的な小難しい話題でしたが、最後まで読んでいただいてありがとうございました。
よければ ↓ にある、♡ をクリックしていただけると励みになります。質問のコメントも歓迎です。
この記事が気に入ったらサポートをしてみませんか？