また NEC IX では BVI (Bridge Virtual Interface) を設定する必要があるため、VLAN 20 (Management VLAN) だけは untagged で通し、VLAN 10・30・40 は tagged で通す構成にしています。
準備期間では VXLAN や GRE も候補として挙がりましたが、VXLAN は Juniper EX シリーズでの設定検証コストが高く、GRE は MTU のオーバーヘッドがさらに大きくなること、そして大会本番に向けてなるべくトラブルの種を少なくしたいという判断から EtherIP を選択しました。
3fff:1:1:2003::/64 dev wlan0 proto kernel metric 256 expires 2591976sec pref medium
3fff:1:1:2006::/64 dev wlan0 proto kernel metric 256 expires 2591819sec pref medium
fe80::/64 dev wlan0 proto kernel metric 256 pref medium
default via fe80::34ef dev wlan0 proto ra metric 1024 expires 1776sec hoplimit 64 pref medium
default via fe80:34e7 dev wlan0 proto ra metric 1024 expires 1619sec hoplimit 64 pref medium
各ルーターでIC-01向けに疎通を確認して(RTXでは ip keepalive)、ICMP Replyが3回連続返ってこなかった場合にdefault-lifetimeとpreferred_lifetimeを0としたRAを広告することにより(RTXではLuaスクリプトにより実現)正常に片系にトラフィックが寄ることを確認しました。これにより冗長性は確保されています。
なお、Source Addressの選択についてはRFC6724 Default Address Selection for Internet Protocol Version 6 (IPv6) の5. Source Address Selectionに言及がありますが、Gatewayに紐づいたPrefixを使用するといったルールは存在しません。
また、この問題はRFC8028 First-Hop Router Selection by Hosts in a Multi-Prefix Networkの3.2で言及されています。
A host SHOULD select default routers for each prefix it is assigned an address in.
技術的にはIEEE802.1X/EAP/RADIUSを用いたシンプルなものとなっています。技術要素及び運用に関してはRFC7593 - The eduroam Architecture for Network Roaming に記載があるのでご覧ください。基本的な流れは、まず利用者がアクセスポイント(AP)に接続するとIEEE802.1Xの仕組みで認証が開始されます。次に、利用者の端末と所属機関の認証サーバー間でEAPを用いた認証情報のやり取りが行われ、その通信はRADIUSプロトコルによって安全に中継されます。最終的に認証が成功すると、APが通信を許可し、利用者はネットワークに接続できるようになります。
eduroam/OpenRoamingの構築例としてInternet Week ショーケース(IWSC) in 奈良の例を紹介します。IWSC会場、京都大学岡部研、Ｌｏｃａｌ２４の3拠点が存在し、RADIUSトラフィックはRadSecにより会場のMeraki MR44からインターネットを経由して京都大学岡部研へ運ばれます。そこからＬｏｃａｌ２４へRADIUSで接続され、eduroam/OpenRoamingのネットワークへと抜けていきます。
認証完了後、ユーザートラフィックは通常通りISPを経由して抜けていきます。
構築例
その他注意事項
その他にeduroam/OpenRoamingを吹く際に気を付けるべきことを紹介します。まず、RADIUSに関してですが、CityroamではRadSec(RADIUS over TLS)の使用が推奨されています。RadSecは、RADIUSをTLSで暗号化して通信する仕組みです。従来のRADIUSがUDP上で共有秘密鍵のみに頼って通信を保護していたのに対し、RadSecはTCP上で動作し、サーバー証明書を用いて通信経路全体を暗号化します。これにより、ユーザーの認証情報などが含まれるRADIUSメッセージがネットワーク上で盗聴されたり改ざんされたりするのを防ぎます。RadSecの利用にはAPとRADIUS Proxyで相互に証明書を検証する必要があるため、互いにCAの証明書を登録する必要があります。そのため、IdPとのやり取りも必要となりますが、RADIUSの欠点を補う強力なソリューションです(RADIUSの問題については後述します)。CityroamではRADIUSは段階的に廃止していく方針が示されています。
RSA certificates (so named after the key algorithm of the key material in the certificate) have long been the standard for certificates across the world. However, as key sizes (below) grow, so does the certificate size. As the certificate sizes increases, the chances of RADIUS packets being fragmented increase, which in turn causes issues with some firewalls performing packet or SSL/TLS inspection and UDP fragment DDoS protection (Microsoft Azure cloud services for example will throw away UDP packets when packet fragments do not arrive in the specific order that they should be reassembled in).
The vast majority of modern devices and operating systems support ECC certificates (also known as ECDSA certificates). ECC certificates are based on elliptic curve cryptography (hence the name), which uses maths behind defining specific curves to generate keys, which in turn are a lot smaller (but not less secure than large RSA keys) and are less likely to suffer from fragmentation. If your users are all using modern devices (Android 8, Windows 8, iOS 9 and above), you probably can/should change your server certificate to one using ECC, even if the root certificate is an RSA certificate.
まずはネットワークがどのような構成になっているか確認します。
$ brctl show コマンドによりブリッジとそのブリッジに取り付けられたインターフェースを表示することができます。
$ brctl show
bridge name bridge id STP enabled interfaces
virbr0 XXXX.YYYYYYYYYYYY yes vnet3
systemd-networkdによって管理されている場合はvirbr0という仮想ブリッジが表示されていると思います。ここではvnet3というタップデバイスが接続されていることがわかります。インターフェースの詳細を確認するには$ ip link show master virbr0から確認することができます。
