前段
PHP Conference Japan 2023が 10/08 に大田区産業プラザPiOで行われたわけですが、開会直後に提供している無線LANがいきなり不安定になってしまい、そのまま一部の部屋以外で提供できない状態になってしまった。
この記事では、なぜそのようなことが発生してしまったか?という点に関して解説しようと思う。
結論
会場側設備として入っているNAPT-BOXが YAMAHA RTX1200 という 15年前*1に発売されたルータで、来場者を捌けるだけのNAPTセッションテーブル*2が備わっておらず、NAPTテーブル溢れ*3を起こしてしまった。
事前知識
NAPT
Network Address Port Translation
1つのグローバルIPアドレスを複数のホストで共有するための仕組み。この機能により1つのグローバルIPアドレスを複数のクライアント(コンピュータやスマートフォン)から利用できるようになる。一般家庭にある「無線LANルーター」や「ブロードバンドルーター」、「HGW*4」などにもこの機能が搭載されている。
詳しい仕組みの解説はこちらのWebサイトにて説明されているので省略します。 NAPTとは|「分かりそう」で「分からない」でも「分かった」気になれるIT用語辞典
NAPTテーブル
上記NAPTの動作を行う際に、グローバルIPとプライベートIPの紐付けを行う必要があるが、その管理台帳のことをNAPTテーブルという。 一般的にこのNAPTテーブルは機種によって上限が決まっており、枯渇してしまったときの動作も機種によって異なる。
TCPの場合はセッション終了を表す FIN シグナルを元に通信が終わり次第順次開放されるが、UDPの場合はセッションという概念が存在しなため、最後にパケットが流れてから一定時間後に開放するという仕組みになっている。
昨今QUICといったTCPで通信すべき内容をオレオレ実装の制御によってUDPでできるようにするプロトコルは、このNAPTテーブルを圧迫するこういった問題があり、大規模ネットワーク構築においてとても扱いにくい仕組みである。対策としては UDP のNATセッションタイマー*5を15秒といった非常に短い時間に設定するといった対応が必要となる。
なお、一般的な業務用アクセスルーターのNAPTセッション数の上限は以下の通りである。
メーカー | 機種 | NAPTテーブル数 |
---|---|---|
NEC | IX2105 | 65,535 |
NEC | IX2106 | 250,000 |
NEC | IX2107 | 250,000 |
NEC | IX2215 | 250,000 |
NEC | IX2235 | 250,000 |
NEC | IX2310 | 250,000 |
NEC | IX3110 | 250,000 |
NEC | IX3315 | 500,000 |
YAMAHA | RTX1100 | 4,096 |
YAMAHA | RTX830 | 65,534 |
YAMAHA | RTX810 | 10,000 |
YAMAHA | RTX1200 | 20,000 |
YAMAHA | RTX1210 | 65,534 |
YAMAHA | RTX1300 | 250,000 |
YAMAHA | RTX3000 | 40,000 |
YAMAHA | RTX3500 | 65,534 |
YAMAHA | NVR500 | 4,096 |
YAMAHA | NVR510 | 65,534 |
注1) いずれも、2023年12月現在での最新ファームウエアを適応した場合の最大NAPTテーブル数
注2) 特にNEC UNIVERGE IXにおいて、ファームウエアバージョンが ver.9.5 以下の場合、65,535 となります
注3) 家庭用ルーター*6 のNAPTセッション数上限は一般的に 2,000~10,000 程度となります
Tips: YAMAHA RTX シリーズでコンソールポートが RJ45 の機材は 65,534 、UNIVERGE IXは概ね 250,000 とおぼえておけば良い。また、業務用ルーターにおけるセッション数の上限は原則仕様書に記載されているので、このような使い方をする際はぜひ調べてほしい。*7
なぜ発生してしまったか?
構成の変更
大田区産業プラザPiOに常設されているインターネット回線は数年前に アルテリア・ネットワークス株式会社の ファストギガビットアクセス の 下り1Gbps/上り200Mbps プランに変更され、それ以降 PHP Conference や PyConなどの Conbuが関わったイベントでは フレッツ光 を利用した構成から 会場回線を利用した構成へと変更してきた。
今までは以下のような「会場回線を利用するが、会場からのトラヒックはトンネルを経由してVPS等で捌く」という構成を行っていた。
しかし、この構成ではVPSの用意を始めとした「向こう側」の整備に時間/お金を始めとするコストが多くかかるという問題があるため、今回の PHP Conference Japan 2023 では「無線LAN構築の省力化」を行うことを目的として、以下のような思想で構築を行った。
- VPSやクラウドなどの整備に時間がかかる構築を行わない
- スイッチの設定は最小限度として、基本的に行わない
- 無線LAN APはクラウドサービスに対応した機材(Aruba Instant On)を利用して、監視/設定はクラウドサービスに任せる
そのため、以下のような構成となった。
事前に行ったNAPTテーブル節約手法
- DNS は UDP を利用するプロトコルであるため、自前でキャッシュサーバを用意することで、インターネットへ向けて出ていくNAPTセッション数の節約を行った。
- UDP通信はNAPTセッションタイマーが切れるまで維持されてしまうため、UDPのNAPTセッションタイマーを自前で用意したルーターにて 10秒程度に設定していた。ただし、この手段では上位にある会場ルーターのNAPTセッション数が節約できるわけではなく、無意味であった。
QUICが猛威を振るう
QUICとは、本来TCPで通信を行うべきHTTPSの通信をお気持ち実装のUDPで通すトンデモ通信規格*8である。
PiOに設置されているRTX1200のNAPTセッションタイマーはおそらくデフォルトの値である「900秒 (15分)」が設定されていると思われれ、誰かがGoogleやTwitterへアクセスするたびに RTX1200 のNAPTテーブルが利用される。Webサイト 1ページあたりのデータ取得には約50~100セッションを利用する。その通信のうち、10%がQUICだった場合は20セッションが使われることになる。
RTX1200のセッション数は 20,000 であるため、 1,000ページほどしか開けないのである。 例えば、100人のユーザがいる場合、一人あたり15分間に10回ほどGoogleなどのQUICを利用しているWebサイトを開くだけで枯渇してしまうのである。
最後には、IPは取得できるし、(キャッシュに乗っている)DNSレコードの解決もできるけどインターネットに出ていけないネットワークとなってしまった。
解決方法
自分たちで用意していたルータにて ”UDPの通信をすべて遮断” することによって、1F大展示場のみで無線LANの提供を再開した。 閉会後の撤収作業を迅速に行えるようにするために、最低限の機材のみを残して前日中に予備機材を撤収していたため、UDPの遮断を行うために利用できるルータは2台だけとなっていたため、無線LANの提供を行う箇所が1F大展示場のみとなってしまった。(予備が1台あれば、2F小展示場でも提供が可能であった。)
その後は、会場ルーターのNAPTセッション数が溢れることなく、なんとか閉会まで無線LANの提供を続けることができた。
反省点
- 会場ルーターの性能を過信してはならない。
- 大規模提供するネットワークでQUICの振る舞いは悪であり、UDPは遮断するか、耐えることができる構成を用意する必要がある。
- 予備機材をすべて持ち帰るのはよくない。
余談
回線の調達に関して
個別に回線を調達する場合は、トラヒックを流すことができ、自前で用意したルーターを自由に使える回線であることが必須要件となる。 この要件に該当する回線の選択肢は以下の通りである。
RFC云々の話
本来は、UDPのタイムアウトに関してはRFCによって以下の項目を守ることを求められる。
- (RFC4787)https://datatracker.ietf.org/doc/html/rfc4787 UDPのタイムアウトは 120秒以上である必要があり、300秒以上が推奨される
- (RFC6888)https://datatracker.ietf.org/doc/html/rfc6888 TCPを除くポートの再利用禁止時間として 120秒 を確保する必要がある
参考資料
https://www.janog.gr.jp/meeting/janog48/wp-content/uploads/2021/07/janog48-lt4-kawakami.pdf
FAQ
Twitterやmastodon等でエゴサして見つけた疑問点に回答します。
使えるポート数は TCP/UDP でそれぞれ 65536 個が最大ではないか?
ポートセービングNATという仕組みによって、最大で 25万セッションなどの 65536 個を超えるセッションの利用が可能となっています。
これは、map-e や DS-Lite などの 4over6 方式、プライベートIPが配布されるCATVなどにおけるキャリアグレードNATなど、限られたポート資源を有効活用する必要がある環境のために開発された仕組みとなります。
なお、複数通信でポートの共有をするためオンラインゲームのプレイ等に支障が出る可能性はありますが、イベント会場でオンラインゲームを行う人はいない*10と思いますので、考慮外の事項です。
IPv6 でも 動的フィルタを構成する際に同じ問題が起こるのでは?
はい。発生しうる現象と考えられます。
IPv6で発生してしまった場合は、動的フィルタのレベルを下げることで対応が可能になる可能性があります。たとえば、「送信先と送信元のIPアドレスとポート番号のセットでフィルタ」をする設定から、「送信元と送信先のIPアドレスだけで動的フィルタを実施する設定」に変えるなどがあります。 この変更をすることによって、セキュリティレベルは下がりますが、以下に例示するような通信が全て1つのフィルタとして動作できるようになり、動的フィルタの制御テーブルを大幅に節約することが出来ます。
- 2001:2:3:4::1:4354 → 200a:b:c:d::1:443/upd
- 2001:2:3:4::1:6484 → 200a:b:c:d::1:443/upd
- 2001:2:3:4::1:7484 → 200a:b:c:d::1:443/upd
- 2001:2:3:4::1:4445 → 200a:b:c:d::1:443/tcp
- 2001:2:3:4::1:7543 → 200a:b:c:d::1:80/tcp
UDPをすべて遮断するとか力ずく過ぎませんか?
はい。そのとおりだと思います。
しかし、この制限環境下で他の方法を思いつくことが出来ませんでした。より良い方法が思いついた方は、この記事にコメントしていただければと思います。
フレッツを引けばよくね?
はい。そのとおりだと思います。
ただし、今回のテーマは「会場無線LAN設営の省力化」です。また、PiOの構内配線はマルチプルVLANが設定されており、部屋をまたいだ通信ができない*11環境です。コストの関係や会場設備の都合上*12すべての部屋にフレッツを引くことは出ません。また、複数階にまたがってイベントを行っているため、部屋間にLANケーブルを引き回すものあまり現実的では有りません。*13
*1:2008年10月発売
*2:Network Address Port Translation Session Table, プライベートIPとグローバルIPのポート変換の紐付けを保存しておく台帳
*3:NAPTの管理台帳がなりなくなること
*5:最終通信から通信が終了したと判断してセッションを終了する仕組み
*6:例: NEC Aterm, BUFFALO Airstation 等
*7:FortiGateでは「ファイアウォール同時セッション」と呼ぶ
*8:15年前の機材といえど、現在の一般的な家庭向けルータよりはRTX1200は高性能である。QUICはルーターのNAPT機能の性能についてあまり考慮されていない。
*9:工事費/運用費の合計が10万を簡単に超える可能性があり、コスト面でおすすめできない
*10:カンファレンス会場では一般的に、Webサイトへのアクセスおよびメールの送受信程度の利用を想定しています
*11:セキュリティ仕様でありここを変更してもらうことは出来ない
*12:フレッツを引くための配管が備わっていない部屋もある
*13:防火扉にまたがって配線を行う場合、防火扉動作時に扉が必ず閉まる形にする必要がある。これを守らない場合、消防に怒られる