WPA3（Wi-Fi Protected Access 3)が正式発表

米国時間の6/25にWPA3が正式発表されました。WPA3でもWPA2以前と同様に家庭向けの「WPA3-Personal」と、企業・組織向けの「WPA3-Enterprise」が存在します。

WPA3-Personalはパスワードベースの認証のため、おそらくPSK相当のものであると思われます。WPA3-Enterpriseは802.1x認証がベースになると思われます。WPA3はセキュアになりますが、いまだソフトウェアアップデートだけで対応出来るか不透明です、さらにTLS1.3同様にソフトウェアで対応してもハードウェアが専用品でないとスループットが出ない恐れがあるため、ハードウェアレベルでの対応製品の購入が必須になってくると思われます。

また、無線LANの接続を簡易化する「Wi-Fi Easy Connect」も発表されています。

これは主にディスプレイを持たないIoTデバイス向けで、スマートフォンなどでQRコードを読み込むだけで読み込んだ機器が設定用デバイスとなり、そこに複数のIoTデバイスを登録することで無線LANへ接続させることが出来るそうです。これは非常に便利だなと思いました。

さらに、公衆無線LANにありがちなパスワードが未設定や共通キーが公開されており、盗聴のリスクが高いWiFiをセキュアにする「Wi-Fi CERTIFIED Enhanced Open」が発表されています。

この技術は無線LANの管理フレームを暗号化する802.11w(PMF)やOWE(Opportunistic Wireless Encryption(RFC8110))を使用することで、認証無しで通信の暗号化を可能にしてくれます。ただし、OWEを使用するには今まで以上にAPの負荷が増えるため、通常のPSKに比べてAPのスペックを考慮する必要があります。また、中間者攻撃には無力のため、中間者攻撃対策は別途考慮が必要です。

Cisco PIのバックアップとリストア

Cisco Prime Infrastructureのバックアップとリストアの手順を記載します。注意点としてPrime InfrastructureはOracleを搭載しているため、システムやサービスの再起動には時間を要します。バージョンアップ等の作業を実施する際は、作業時間を多めに見積もることをお勧めします。また、検証用にメモリが12G必要な最低構成をメモリが16Gほど空いている仮想サーバにデプロイしてみましたが、重くて使えませんでした。よほどリソースに余りがない限り、アプライアンス版の購入したほうが良いかなと思いました。

【バックアップファイルの作成】

バックアップファイルを作成する際は、FTPサーバを用意することでバックアップファイル作成時に自動的にFTPでアップロードされます。

CiscoPI/admin# conf t 
Enter configuration commands, one per line. End with CNTL/Z. 
CiscoPI/admin(config)# 
CiscoPI/admin(config)# repository backup-repo-180628 
CiscoPI/admin(config-Repository)# 
CiscoPI/admin(config-Repository)# url ftp://x.x.x.x
CiscoPI/admin(config-Repository)# user admin password pallain Cisco123
CiscoPI/admin(config-Repository)# 
CiscoPI/admin(config-Repository)# end 
CiscoPI/admin# show repository backup-repo-180628 
backup_area.txt 
CiscoPI/admin# 
CiscoPI/admin# backup pibackup repository backup-repo-180628 application NCS  

DO NOT press ^C while the backup is in progress 

Aborting backup with ^C may terminate the backup operation or the backup file may be corrupted 
Backup Started at : 06/26/18 15:49:28 
Stage 1 of 7: Database backup ... Database size: 20G 
-- completed at 06/26/18 15:50:36 
Stage 2 of 7: Database copy ... 
-- completed at 06/26/18 15:50:36 
Stage 3 of 7: Backing up support files ... 
-- completed at 06/26/18 15:50:36 
Stage 4 of 7: Compressing Backup ... 
-- completed at 06/26/18 15:50:38 
Stage 5 of 7: Building backup file ... 
-- completed at 06/26/18 15:51:19 
Stage 6 of 7: Encrypting backup file ... 
-- completed at 06/26/18 15:51:31 
Stage 7 of 7: Transferring backup file ... 
-- completed at 06/26/18 15:51:50 
% Backup file created is: PI-Back-180626-1549__VER3.1.0.0.132_BKSZ9G_CPU16_MEM4G_RAM23G_SWAP15G_APP_CK613141954.tar.gpg 
Total Backup duration is: 0h:2m:22s 

【バックアップファイルからのリストア】

CiscoPI/admin# restore PI-Back-180626-1549__VER3.1.0.0.132_BKSZ9G_CPU16_MEM4G_RAM23 G_SWAP15G_APP_CK613141954.tar.gpg repository backup-repo-180626 application NCS 


* NOTE * If the system console is disconnected or got cleared on session timeout 
run 'show restore log' to see the output of the last restore session. 

Restore will restart the application services. Continue? (yes/no) [yes] ? yes 

DO NOT press ^C while the restoration is in progress 
Aborting restore with a ^C may leave the system in a unrecoverable state 

Initiating restore. 
Please wait... Restore Started at 06/26/18 15:58:33 
Stage 1 of 9: Transferring backup file ... -- completed at 06/26/18 15:58:40 
Stage 2 of 9: Decrypting backup file ... -- completed at 06/26/18 15:59:01 
Stage 3 of 9: Unpacking backup file ... -- completed at 06/26/18 15:59:01 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
Estimated time for completion of the remaining stages : 06/26/2018 16:41:30 
Systems with faster disk throughput may finish earlier than the estimated time 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
Stage 4 of 9: Decompressing backup ... 
-- completed at 06/26/18 16:01:30 
Stage 5 of 9: Restoring Support Files ... 
-- completed at 06/26/18 16:01:31 
Stage 6 of 9: Restoring Database Files ... 
-- completed at 06/26/18 16:04:10 
Stage 7 of 9: Recovering Database ... 
-- completed at 06/26/18 16:05:58 
Stage 8 of 9: Updating Database Schema ... 
-- completed at 06/26/18 16:05:58 
Stage 9 of 9: Re-enabling Database Settings ... 
-- completed at 06/26/18 16:08:16 
Total Restore duration is: 00h:09m:43s 
INFO: Restore completed successfully.

Starting Prime Infrastructure... 

This may take a while (10 minutes or more) ...

Prime Infrastructure started successfully. 
Completed in 613 seconds 

今回のテストではバックアップ～リストアまで約30分弱でした。あまりデータが入っていない状態で実施したため、データ量に応じて時間を追加計上しておいたほうが良いです。ちなみにライセンス追加では再起動は不要でした、ただし反映に再ログインが必要です。

WLC HA構成(SSO)のバージョンアップ手順

HA(SSO)構成を組んだ状態でバージョンアップ作業を行ったので、作業の備忘録を残しておきます。

基本的なバージョンアップ手順はシングル構成と変わらず、プライマリ機にアップロードすると自動的にセカンダリ機に転送されます。

GUIの場合、「Download File」を押下し、各パラメータを指定します。

＃検証時の環境ではプライマリ機のアップロードに約5分ほどかかりました。

• File Type：「Code」
• Transfer Mode：「TFTP」
• IP Adress：「TFTPサーバのIP」
• File Path：「/」
• File name：「アップロードするOSファイル名」

各パラメータ投入後、右上の「Download」を押下するとプライマリ機にアップロードが開始します。アップロード完了後、セカンダリ機に転送が始まります。ここまでは通信断も起きませんでしたが、セカンダリ機に転送中はWiFiクライアント端末からのPingが不定期に重くなり、それまで4～6ms以内だったものが500ms程度になることがありました。アップロードでは明確な通信断は発生しませんでしたが、クライアントに負荷をかけることが許容されない場合は作業時間を検討する必要があります。

セカンダリ機への転送が完了後、転送が完了したメッセージが同一ページ下部に表示されるため、「Config Boot」を押下し、アップロードしたOSが「default」となっていることを確認し、両WLCを再起動をします。ここから通信断が発生します、再起動はWLC,APそれぞれ約5分程度の合計約10分です。

再起動完了後、APが再帰属して新OSを取得して再起動後、通信が復旧します。WLC5000シリーズでは6.0以降から同時に100APアップグレード可能だそうです。

結果的に明確な通信断が発生したのはWLCの再起動で約5分、その後APの再起動で約5分の10分程度でした。また、全体の作業時間はtftpによるアップロードが約5分、セカンダリ機に転送が約10分で合計約25分～程度となりました。

今回の検証環境ではAPの台数が1台でかつWLC、AP、tftpサーバが同一セグメントの環境だったため、帯域やAP台数でもう少しバッファを見込んだほうが良いと思います。

マルチエリアOSPF環境の通信迂回時の注意点

先日マルチエリアOSPF環境のルータでモジュール故障被疑が発覚したため、コストアップで経路迂回しようとしたら失敗したので備忘録として残しておきます。環境イメージは以下のとおりです、故障被疑はRT#01です。

通常のトラフィックフローは以下となります。

ここからRT#01とRT#03間のインターフェースコストを10000追加し、経路迂回を実施しました。トラフィックフローを見てみると、RT#03からの経路は迂回出来ているけどBGP Networkからの通信は迂回出来ていない。。。。

 RT#03からの発信経路

BGP Networkからの発信経路

 なんでだろうってコンフィグをよく見たらRT#01、RT#02間はArea0でRT#01、RT#03間はArea100でした。OSPF ルートの選択ルールでは、エリア内ルートがエリア間ルートより優先され、エリア間ルートが外部ルートより優先されます。そのため、今回の構成ではコスト値より同一Areaからのルートを優先してしまいます。RT#03から発信する通信はコストに従ってRT#02経由へ迂回できましたが、BGP Networkからの通信はRT#01がRT#03と同一Areaのため、コスト度外視でRT#03に向かってしまいました。

う～ん、マルチエリアはあまり経験がなく、初歩的なことでつまづいてしましました。。OSPFのマルチエリア環境ではシングルエリアとは違う迂回手順が必要なため、注意して下さい。多分RT#01でPassiveにするしかなさそうです。ちなみにPassive化のほうが該当インターフェースのシャットダウンよりダウンタイムが少なったです。

ロードバランサーのTLS1.3対応状況

ちょっと前にA10やF5のエンジニアのかたとお話しする機会があったため、TLS1.3の対応状況を伺ってみました。

基本的に両社とも同様の回答で、現在ラインナップしている機器はファームウェアアップグレードで対応予定であるとのことでした。

しかし、注意点としてSSLに関しては専用のSSLチップでオフロードしており、このチップがTLS1.3に対応していないため、ソフトウェア処理によるスループットの低下が想定されるとのことです。現在と同等のスループットを期待する場合は、暗号化チップがTLS1.3に対応した製品買い替えることを検討しなければなりません。

本内容はUTMやプロキシなど、SSLデコードを行う機器では同様のことが想定されるため、TLS1.3が正式対応される直前では機器のリプレイスを控えるなど、各社がハードウェアレベルでTLS1.3に対応する時期を抑えて顧客に提案する必要性があると感じました。

※2018/8/17追記

セイコーの担当者ともお会いしました、セイコーのロードバランサーは低価格に抑えるために必要最低限の機能搭載としているため、Office365の迂回機能やTLS1.3の対応については現行ラインナップではなく次期製品から対応予定とのことでした。

SRX ポリシー変更時のセッション断について

SRXでFWポリシーを変更する場合、許可しなければいけないポリシーを消してしまうことや、ポリシーの順番を変更する際に、許可したい通信がDenyポリシーにヒットしないか注意する必要があります。その他にも、以下のポリシー操作をすることでセッション断が発生してしまうので注意が必要です。

• src dest serviceのいずれかをシングルセルからマルチセルへ変更
• src dest serviceのいずれかをマルチセルからシングルセルへ変更

シングルセルはオブジェクトが単体の状態を指し、マルチセルは複数のオブジェクトが指定されている状態を指します。

例として以下のポリシーを変更する場合、(1)～(3)では影響の有無が異なります。

1. Src:192.168.0.0/24を削除する場合、マルチセルからシングルセル変更されるため、セッション断が発生します。

2. Dest:133.243.238.163を削除する場合、マルチセルから変更されないため、セッション断は起きません。

3. Serviceにプロトコルを追加する場合、シングルセルからマルチセルに変更されるため、セッション断が発生します。

MTUの設計

最近MTUの設計方法をド忘れしていたので、備忘録を残しておきます。

MTUとは1フレームで送信できるデータの最大値を示す伝送単位であり、一般的に使われるイーサネットであればイーサネットフレームの最大値である1518byteからEthernetヘッダ ( 14byte ) と FCS ( 4byte ) は除くため、IPとして通信できるサイズは1500byteとなります。

基本的にはこのMTUサイズが大きければ大きいほど、一度に送信できるデータ量が増えるため、（間の経路でフラグメントを考慮しなければ）通信の効率化が見込めます。そのため、間の経路でPPPoEやカプセル化などのヘッダ追加がないのであれば、実際に機器に設定するMTUも1500にしておけば問題ありません。実際にはローカル環境でない限り1500にすることはあまり無いと思います。その理由はMTUの最適値が間の経路を含めた最小値になるためです。MTUより大きなサイズのパケットがくるとフラグメント化して送信する必要があり、フラグメントの処理はハードウェア処理ではなくソフトウェア処理になってしまい、断片化したパケットを元に戻すのにも処理が必要で負荷が高くなるためです。

例えばGreヘッダは24byteの構成要素があるため、MTUの計算は-24しなければならず1476byteとなります。つまり実際に一度に送れるデータ量が1456byteです。

また、MTUサイズはフラグメントを避けるために小さくすれば良いか？と問われると答えはそうではありません、フラグメントを禁止したパケットがドロップしてしまうためです。このドロップを防ぐためにはいくつかの方法が存在します。

「mtu path discovery」という機能を使えばパケットサイズが超過していた場合に、フラグメントせずに済むサイズで再送するように要求を行うことが出来ます。ただし、mtu path discovery機能はICMPを使用するため、ルータのACLやFWでICMPが全て無効になっていると使うことが出来ません。また、通信を行う相手側（サーバ等）も対応している必要があるため、この機能だけで救えない場合も存在します。

「crypto ipsec df-bit」コマンドを使用すれば強制的にdf-bitを上書きすることも可能です。しかし、各パケットがプロセス レベルで再アセンブルされるため、高いデータ レートでパフォーマンスに大きな影響が生じます。プロセススイッチングによる通信速度低下が起こるうえに、再アセンブル キューが満杯になるとフラグメントが強制的に廃棄されることがあります。また、SSLなどの通信がフラグメント禁止にしているのはハッシュ値が変わることを防ぐためでもあります。これを強制的にフラグメントすることで想定外の挙動になる可能性があります。

新たな公開DNSサーバ「1.1.1.1」

APNICとCloudflareが無料の公開DNSサーバの提供を始めました。

このサービスのメリットとしてユーザーのIPアドレスを記録せず、これを証明するためにKPMGによる監査を毎年行うことを名言しています。これは昨今のセキュリティを重視する流れに沿っていて良いと思います。

さらに、公式ページによれば他の公開DNSサーバより高速だとうたっており、一時期流行ったインターネットを高速化するためにDNSサーバのIPを8.8.8.8に変更する手法も、今後は1.1.1.1に変更してみる流れになるかもしれません。

個人的にはお客さんの環境がインターネットへ接続できているかの確認のために、8.8.8.8へpingを打ってもらって切り分けすることがあるので、今後は1.1.1.1に打ってもらうことがあるかもしれません。

SRX ClustrerIDの変更方法

SRXでHA構成を組む場合、以下のコマンドでClusterIDを指定する必要があります。

root> set chassis cluster cluster-id 1 node 0 reboot

root> set chassis cluster cluster-id 1 node 1 reboot

 ClusterIDはHAを組む機器同士で同一の値である必要があり、仮想IPに使用する仮想MACアドレスのベースになります。そのため、VRIDと同様に同一ネットワーク内に同一ClusterIDでHA構成を組んだSRXが存在することは許容されません。SRXの場合、以下の構成では仮想IPが別の値でもUntrustセグメントでMACアドレスが重複します。

ClusterIDの変更方法は、HA構成を組む際に使用した上記コマンドと同一であり、HA構成を組んだままClusterIDを変更することが出来ます。ただし、ClusterIDの変更には再起動が必要なため注意してください。

複数セグメントでのVRID重複問題

VRRPの標準仕様では仮想IPアドレスに対する仮想MACアドレスを使用します。この仮想MACアドレスはVRIDから作られるため、VRIDが同一だとセグメントが違っていても同じMacアドレスが生成されてしまいます。この仕様は下記のようにL2SW等がVLAN毎にMacアドレスを学習してくれれば通常問題ありません。

しかし、以下のようにVlan単位でMacアドレスを学習できない場合は複数ポートに同一Macアドレスが見えるため、仮想Macアドレス宛のフレームをどのポートに転送するのかはスイッチ次第となり、動作が不安定となります。

では設定を変更して仮想IPのMacアドレスを仮想Macではなく物理Macアドレスを使用すれば良いか？と言われるとそうとは言い切れません。物理Macアドレスを使用するとRFCに準拠しなくなり、パケットロスにも弱くなってしまいます。また、VRRPの系切り替わり時にバッティングログも出てしまいます。昔NECのClusterPROで冗長化していたサーバも物理Macアドレスを使用していたので、よくNW機器にバッティングログが出ていました。

結論としては適切なVLAN設計がされているネットワークではセグメントが分かれていればVRIDが被っていても特に問題はありません。しかし客先ネットワークの一部しか構成を把握できないような案件では、一見セグメントが違う場合もVRIDはユニークなものにしたほうが良いかもしれません。間に何が挟まってるかわからないので。。。