Meraki MXではDC-DC Failover構成を除いて原則的にAuto VPN Peerに対するTrackingを行いません。 そのため、Full Tunnelを張る設定になっている場合は、対向のHubがダウンしてもルートが切り替わりません。
Full Tunnelを設定した状態で障害性を求めるのであれば、Hubの拠点のMXはWarm-Spareを組むか、DC-DC Failover構成にする必要があります。
Meraki MXのActive-Active Routed Mode MX Scalingでは冗長性を保ったままAuto VPNには参加できない
Meraki MXにはActive-Active Routed Mode MX Scalingと呼ばれる展開方式があります。
ドキュメント上ではActive-Active Routed Mode MX Scaling (Outbound Only)と表現されており、Outbound Only の文言が目につきます。
Outbound Onlyの意味は明記されていませんが、冗長性を保った状態でのAuto VPN経由の通信が実質的に行えないためだと推察できます。
理由は、Meraki MXのRouted Modeでは同一のサブネットを複数のNetworkでAuto VPNへ参加させられないのが要因です。
そのため、Meraki MXを象徴するAuto VPNを使えずに、Internet接続専用RouterのようなOutbound Onlyの導入の仕方にせざるを得ません。
なお、Routed ModeのAuto VPNにおける同一サブネットのAuto VPNへの広報の制約は、下記の記事で個別に取り扱っています。
MerakiのFirewall Informationには、Meraki Cloudに関わる通信しかリストされていない
Meraki Dashboardでは Firewall Information にてMeraki Cloudに関する通信要件を表示できます。
ここで重要な点は、Meraki Cloudに関する通信しかリストされない点です。 そのため、Meraki MXではAuto VPNトンネルの形成に関わる通信や、Health Check系のモニタリング通信はリストされていません。
筆者は実案件にて危うく見逃しそうになった通信要件があるため、Meraki MXに関わる通信要件を補足情報して紹介します。
Meraki MXに関わる通信要件の補足情報
Auto VPNトンネルの形成に使用する通信要件
Auto VPNトンネルに関わる通信要件の情報は、下記のDocの IPsec tunneling が該当します。
Ports used to contact the VPN registry:
- Source UDP port range 32768-61000
- Destination UDP port 9350 or UDP port 9351
Ports used for IPsec tunneling:
- Source UDP port range 32768-61000
- Destination UDP port range 32768-61000
VPN registry と IPsec tunneling の記載がありますが、VPN registry に関してはFirewall Informationに予め表示されていたので個別の対処は不要でした。
また、IPsec tunneling の通信要件を表で表すと下記のようになります。
| Protocol | Source Address | Source Port | Destination Address | Destination Port |
|---|---|---|---|---|
| UDP | Meraki MX | 32768-61000 | Auto VPN Peer | 32768-61000 |
Meraki MXのAuto VPNは動的IPアドレスでもトンネルを形成できるため、各拠点のMeraki MXが動的IPアドレスの場合は宛先アドレスは Any にせざるを得ません。 もし厳密な制御が必要となる場合は、固定グローバルIPアドレスの契約の検討が必要になってきます。
Health Check系のモニタリング通信に関する通信要件
Meraki MXはUplinkからInternet側への疎通状況を確認するためにモニタリング通信を行っております。
Meraki MXが標準で行うモニタリング通信
Meraki MXは標準でDNS Query, ICMP, HTTP GETのモニタリング通信を行います。
Connectivity Tests
The MX runs tests to determine uplink status:DNS test
- Query the DNS servers (primary or secondary) configured on the internet interface for the following hosts:
meraki.com google.com yahoo.comInternet test
- Pings to either 209.206.55.10 or 8.8.8.8. One ping per second.
- Uses a round-robin technique to send an HTTP GET to http://meraki.com or http://canireachthe.net. An HTTP response of any kind will result in a success.
ARP test
ARP test はセグメントを超えないため、基本的には通信要件の対象から除外します。
DNS Query (DNS test)によるモニタリング通信は、Meraki MX本体のDNS Serverの設定に依存します。
Local Status PageもしくはMeraki Dashboard上で設定値を確認してください。
Uplinkの設定がDHCPによるアドレス取得の場合は、Meraki Dashboard上から動的に取得しているDNS Serverの情報を確認できます。
Uplink statisticsのICMP通信
Meraki MXが標準で行うモニタリング通信とは別に、ユーザーが個別に指定が可能な設定も存在します。
メニュー: Security & SD-WAN > SD-WAN & traffic shaping の設定項目: Uplink statistics で指定した宛先に対してICMPの通信を行います。
デフォルトでは 8.8.8.8 でGoogle Public DNSが宛先に指定されています。
Uplink Statistics
Clicking the Add Your Destination option allows you to add a custom destination for the MX to continually test ICMP connectivity for monitoring latency and packet loss.
モニタリング通信の通信要件の整理
モニタリング通信の通信要件を表で表すと下記のようになります。
| Protocol | Source | Destination | 備考 |
|---|---|---|---|
| DNS | Meraki MX | DNS Serveの指定先 | DNS test の通信要件です。Meraki MX本体の設定に依存します。 |
| ICMP | Meraki MX | 209.206.55.10 | Internet test の通信要件です。 |
| ICMP | Meraki MX | 8.8.8.8 | Internet test の通信要件です。 |
| HTTP | Meraki MX | meraki.com | Internet test の通信要件です。 |
| HTTP | Meraki MX | canireachthe.net | Internet test の通信要件です。 |
| ICMP | Meraki MX | Uplink statisticsの指定先 | Uplink statisticsの設定に依存します。デフォルトでは 8.8.8.8 となります。 |
FQDN宛に対しての通信もあるため、FirewallがFQDN宛の通信をトラッキング出来ない場合は Any での許可が想定されます。
備考
この他にも使用する機能によってはFirewall Informationにリストされていない可能性があります。 また、本記事ではMeraki MXに関して取り上げましたが、他のシリーズにおいても通信要件の漏れがないように実際にFirewallを挟み込んで実機確認を行うと、より安全に顧客環境にリリースできると考えられます。
関連記事
Azure版のMeraki vMXでClient VPNを動作させるにはAZをNoneにする必要がある (2022年04月時点)
Azure版のMeraki vMXでは、冗長性構成にするためにAvailability ZoneをNone以外に指定してしまうとClient VPNが動作しなくなります。
情報源
情報源はMeraki Communityとなります。
本挙動の背景には、Meraki vMXの zone (Availability Zone) に指定した値によって、デプロイ後のPublic IPのSKUがBasicもしくはStatndardに変化する点が関わってきます。
コミュニティの情報から事象を要約すると下記のようになります。
zone(Availability Zone)をNoneにすると、Public IPのSKUがBasicとなりClient VPNが動作します。zone(Availability Zone)を1, 2, 3のいずれかにすると、SKUがStandardとなりClient VPNが動作しなくなります。
実際の設定画面
zone (Availability Zone) に 1 (None以外) を指定時
zone (Availability Zone) に 1 (None以外) を指定して、Public IPのSKUがStandardになるのを確認した際の画面です。
zone (Availability Zone) に None を指定時
zone (Availability Zone) に None を指定して、Public IPのSKUがBasicになるのを確認した際の画面です。
設計への影響
Client VPNを動作させるには zone (Availability Zone) を None に指定する必要があるため、AZ障害に対する耐障害性がなくなります。
Enterprise環境では一般的には冗長性が求められるため、提案時に本事象がある点を見逃すと後々大きな問題になりかねないため注意してください。
サポートへの問い合わせ情報
本情報の正確性を確かめるために筆者は実機で事象を再現させて、2022年04月頃にサポートに問い合わせを行いました。
その際に本事象がBugなのか仕様なのかを問い合わせましたが、本事象は未確定 (未定義)の旨を回答を得ております。
よって、本事象は未確定 (未定義)のためBugでもないし。未確定 (未定義)のため仕様でもないようです。
また、筆者が確認する限りでは、公式DocにもFirmwareのRelease Notesにも本事象の記載がないため事前には気づきにくいです。
ちなみに筆者の場合は、ドキュメントに未記載の事象でハマって痛い目を見た経験があるので、 Meraki Communityで情報を漁っていて本件に気が付きました。
関連ドキュメント
最新情報が記載される可能性があるドキュメントは下記になります。
BIG-IP Forward Proxy案件における人員調達の難しさ
BIG-IP Forward Proxy案件における人員調達について、エンジニアの立場として携わった有識者の観点で話をします。
BIG-IP Forward Proxy案件の全般的な内容は下記の記事で個別に扱っております。
- 案件の想定
- BIG-IP Forward Proxyエンジニアに求められるレベル
- BIG-IP Forward Proxyエンジニアの希少性
- 採用活動
- 認定パートナー
- 社内でのBIG-IP Forward Proxyエンジニアの育成
- プロフェッショナル サービス
- 最後に
案件の想定
既存がProxySG (Bluecoat)であり、BIG-IP Forward Proxyの乗り換えを行う想定とします。
ProxySG (Bluecoat)の保守費が高騰していて維持コストが高くなってきているため、他社への乗り換え需要があるのが理由です。
そして、ProxySG (Bluecoat)からの既存踏襲での移行難易度がとても高いためです。
BIG-IP Forward Proxyエンジニアに求められるレベル
BIG-IP Forward Proxyエンジニアは幅広いスキル幅を求められるため、
案件を遂行しきるためには国内トップクラスのようなスキルを持つエンジニアが求められます。
その上で、BIG-IP Forward Proxyに対する個別の知識も必要になるため、並大抵のエンジニアは務まらないのが現実です。
NW業界の最高峰の資格のひとつにCisco資格のCCIEがありますが、 iRulesによるコード拡張の限りを尽くしたBIG-IP Forward ProxyにはCCIEホルダーでされレビューするのも困難なほどの難易度になります。
NW機器のBIG-IPとCisco資格のCCIEはメーカーが異なるので単純に比較するものではありませんが、 高度な資格を持つエンジニアであっても、BIG-IP Forward Proxyを簡単に理解できないのが争点です。
ここまでの話を整理すると、簡単に人員調達と言っても求められるレベル感が高すぎるため、要件を満たす人材が居ない可能性すらあります。 人員の調達が困難であれば案件遂行に大きく悪影響を及ぼすため、請負の場合は完成責任を問われるリスクが高くなります。
BIG-IP Forward Proxyエンジニアの希少性
まずProxySG (Bluecoat)の乗り換え先としてBIG-IP Forward Proxyが注目されてきたのは2020年頃になると思われます。筆者が実案件で携わったのもその時期となります。
そして、筆者が知る限りでは2020年と2021年のWebinarが、世にBIG-IPがForward Proxy構成も行えると知らしめたものだと見受けております。
また、筆者が実案件でF5認定パートナーの方々と会話したことがありますが、「BIG-IPのProxy案件の話」と予め伝わっていたらしく。 BIG-IPでProxyと言えばReverse Proxyのような前提をエキスパートの方々が持っている中で。 筆者がForward Proxy構成の話をしていると、「Reverse ProxyとForward Proxyを履き違えている」レベルの低い人だと思われるほどに、 BIG-IPのエキスパートの方々からもForward Proxy構成の認知度が低かったです。
そのため、BIG-IP Forward Proxyエンジニアの絶対数は少ないと見受けております。
そうなってくると、BIG-IP Forward Proxyエンジニアにはスキルの希少性に付加価値がつくため、採用活動における優位性はエンジニア側にあります。
更にはBIG-IP Forward Proxyを扱うエンジニアは幅広いスキル幅が必要にならざるを得ないため、どのような案件にも対応できる柔軟性が生まれやすくなり、 特定製品の案件にだけ絞って職探しをする必要がありません。 そのため、同等の給与や報酬が得られる案件が複数あるのであれば、わざわざリスクの高い方を選ぶ必要性がなくなるため、採用の難しさに繋がってしまいます。
BIG-IP Forward Proxyエンジニアの採用活動は、国内有数レベルのエンジニア採用と同義にも等しいため給与や報酬を渋るのであれば採用機会すら失われる可能性があります。
また、BIG-IP Forward Proxyの有識者の観点で言わせてもらいますが、 超絶的な難易度を誇るBIG-IP Forward Proxy案件は有識者ほど避けやすくなります。 難易度に比例して負担やリスクが高くなり割に合わないからです。
そして、難易度が高いあまりに有識者ほど簡単にできるとは言わなくなります。 表現を変えると、「我々にはBIG-IP Forward Proxy案件の実績やナレッジがあります。」と言ったような 宣伝文句を簡単に謡ってしまう人は有識者ではないとも受け取れます。
採用側はBIG-IP Forward Proxyの有識者を求めるものの、 有識者側ほどリスクの高い案件に関わりたくない傾向になってしまうと、需要と供給が歪な関係性となり更に希少性が際立ってしまいます。
採用活動
採用活動において、BIG-IP Forward Proxyエンジニアを狙って採用するのは難しくなります。 まずBIG-IP自体は様々なモジュールにより様々な構成に対応できるため、Forward Proxy構成の知見を持つエンジニアの特定が難しいからです。
例えば、転職サイトの業務経歴書内に製品の経験として「BIG-IP」と記載してあっても、 それはLoad Balancer構成の経験かもしれませんし、SSL-VPN構成の経験かもしれません。何なら他の構成かもしれません。 そのため、実際に当人に話を伺ってみないと判断がつかない場合が多いと考えられます。
実際、筆者の場合は「増員しようにも有識者のレベル感の判断がつかない。」旨を言われて採用活動が打ち切られました。 またその際に、「体制上の人数は決まっているから、どうしても採用するとなると既存メンバーと入れ替えになるがいいのか。」と、 利益優先な社内政治で既存メンバーを人質に取られて採用活動を断念せざるを得なかったです。
更に先ほどと同様に、BIG-IP Forward Proxyの有識者の観点で言わせてもらいますが、 BIG-IP Forward Proxyエンジニアを狙い撃ちにした採用活動をしてる時点で、 上述の内容を加味したプロジェクト運用がされていないと判断できるため有識者ほど避けやすくなります。 「飛んで火に入る夏の虫」もとい「炎上案件に飛び入るエンジニア」に自ら積極的になろうとする有識者が居るかを考えてみてください。
認定パートナー
BIG-IPの知見を持つエンジニアが多数在籍しているのがF5社が認定したパートナーとなります。 そのため、先の見えにくい採用活動を行うよりかは認定パートナーに依頼を行うのが確実性が高いです。
ですが、ベテランのBIG-IPエンジニアほどForward Proxy構成の難しさは理解されていると考えらるため、 引き受けるにあたって厳しい条件が提示される可能性が高くなります。
実際、筆者がBIG-IP Forward Proxy案件の相談を受けた際は、
どうしても引き受けるしかないなら厳しい条件を顧客に提示する旨をアドバイスして釘を刺しました。
そのため、有識者が存在する会社に依頼するなら厳しい条件が突きつけられるのを覚悟すべきです。
社内でのBIG-IP Forward Proxyエンジニアの育成
ここまでで社外からの人員調達が如何に難しいかを解説しました。 よって最終的には、社内でBIG-IP Forward Proxyエンジニアを育成する土壌を形成するしか選択肢がなくなってきます。
しかしながら、そもそも超絶難易度を誇るが故に既存社員での対応が難しく、有識者の調達が必要になっていた中でそれを既存の社員に強いると離職の原因となりかねません。
また、コード拡張をして独自性が強くなっていると、既存メンバーが離職する際の引継ぎが困難になります。 そのような状況になっていると、数少ない有識者が一人また一人と離職していきプロジェクトが破綻しかねません。
そのため、10人や20人のような多数のメンバーで負荷を軽減していくような体制にしないと、運用フェーズで担当者を擁立できずに詰みます。
実際、筆者も超絶的な難易度に対して十分な体制になっていなかったため、何度も論拠を元にして増員の掛け合いなどを行いました。
しかしながら、上述しているように人員調達が難しく運用フェーズに入っても後任の担当者を擁立できずに属人化が発生している実例があります。
プロフェッショナル サービス
メーカーはBIG-IP Forward Proxyに関して勿論詳しいため、コスト度外視でも完成責任を果たさざるを得ないのであれば、 顧客に対してプロフェッショナル サービスを使用する合意を取っておくべきです。
また、コード拡張を使用すると保守サービスの範疇外となる可能性があるため、 運用中のリスクを低減するためにもプロフェッショナル サービスの検討はすべきです。
採用や育成は不確実性が伴うため、有識者によるサービスを受けられるプロフェッショナル サービスの契約はとても価値があります。
繰り返すように言いますが、BIG-IP Forward Proxy案件においてプロフェッショナル サービスは必須級の扱いです。契約しないのがリスクとすら言えます。
最後に
本記事はBIG-IP Forward Proxy案件のリスクを限りなく低減するための観点でまとめております。
ProxySG (Bluecoat)から既存踏襲で移行を行おうとすると、コード拡張でこねくり回さざるを得なくなるためBIG-IP Forward Proxyは超絶的な難易度を誇ります。
そして、その超絶難易度の中で如何にして案件を遂行していくかが重要となります。
筆者が技術面以外で苦労したのが本記事のテーマでもある人員調達でした。
超絶的な難易度な故に理解を放棄されて、増員が必要だとすら思われない状態からスタートして。
その上で更に「たかがネットワーク機器に何人も専任の人員を用意できない。」旨の理由で利益優先で増員が阻止され続けられました。
そのため、筆者は社内政治的な難しさも加味して超絶的な難易度と表現しております。
本記事の内容を教訓として、BIG-IP Forward Proxy案件を担当される際は、似たような事態にならないように注意してください。
Meraki MX (Routed Mode)のWarm-Spare構成時の筐体障害交換の一例
Meraki MX (Routed Mode)のWarm-Spare構成時の筐体障害交換の手順をまとめました。 なお、本手順はあくまでも一例となります。環境や交換方法の指針によって手順の変更が必要になる可能性があります。
ドキュメントには該当するトピックがないため、筆者が個人的にまとめた内容となります。該当のドキュメントがない点は、2021年12月頃にサポートに問い合わせて確認しております。
作業手順は安全性が高い手順に寄せるようにしましたが、シンプルな手順と複雑な手順がある場合は、複雑化による作業ミスを避けるためにシンプルな方を採択しております。
また、その他の理由として、Meraki MXは間接リンク障害が約300秒 (5分)であり、1秒のサービス断も許されないような環境にはそもそも向いていないため、 サービス断時間より作業ミスによる二次被害のリスクを重いと筆者は判断しました。
本作業では筐体交換に伴ってサービス断が発生する可能性があるため、片肺運用の継続時間よりサービス断時間を気にされる場合はメンテナンス時間を適宜設けてください。
想定シナリオ
Meraki MXをRouted ModeのWarm-Spare構成にて、Primary MXに障害が発生して筐体交換を行うシナリオを想定しています。
VIP (Virtual IP)は未使用の想定です。VIPを使用している場合は、物理的な交換タイミングでDual Activeになった際に、VIPの奪い合いが発生してフラップする可能性があります。
なお、VIPの未使用時であってもDual Activeとなると、仕様上はサービス影響が発生する可能性があります。代替機にはIPアドレス情報などの事前設定はしていない想定です。
代替機はPrimary MXだけでなくSecondary MXの代替にもなり得るためです。代替機は予めInventoryに登録してある状態を想定しています。
検証時の情報
本手順はMX64 (Version: MX 16.16)で検証しております。 筆者はあくまでも個人であり、MX64は2台しか所持していないため、障害機と代替機は同一のデバイスになっております。 また、検証時はInternet回線は各MXに1回線の収容で行いました。図上では考慮漏れを防ぐために各MXに2回線の収容想定のイメージ図にしております。
手順
正常時の状態
まず前提となる構成を正常時の状態を示します。
障害発生時の状態
本記事ではPrimary MXに障害が発生したと想定しております。
作業対象に誤りがないか正確に確認してください。
障害対象の電源をオフ
障害対象のMXの電源をオフにして不意な再起動のループやInterfaceのフラップが起きないようにします。 後の作業で代替機の作業電源を確保する意味合いも含んでいます。
代替機に電源を接続
故障機が使用していた電源を流用して代替機を立ち上げます。
代替機のLocal Status Pageで初期設定
作業端末から代替機のLocal Status Pageへアクセスを行います。作業端末でURL: http://mx.meraki.com/ を開きます。
MXのLocal Status Pageへの接続 Configure タブを開きます。Meraki Cloudへの接続前後で資格情報が異なります。
本段階ではMeraki Cloudへの接続前 (Before)の想定になります。
資格情報の入力画面 Parameter Sheetなどの設定情報の控えを元にして、Uplinkの設定を行います。
Local Status PageのUplink configuration
Dashboardで機器を交換
Meraki Dashboardで機器の交換を行います。詳細な手順を解説してきます。
障害機の画面へ移動
障害機の画面へ移動します。
本記事ではPrimary MXが障害機として想定しているため、メニュー: Security & SD-WAN > Appliance status に移動します。
作業対象 (障害機)の確認
障害機が作業対象になっているか確認してください。
障害機をNetworkから削除
障害機の画面で Remove appliance form network... ボタンを押下して、障害機をNetworkから削除します。
Networkから障害機を削除すると、MXが1台しかNetworkに存在していないためWarm-Spareを組んでいない状態になります。
代替機でWarm-Spareの組み直し
Configure warm spareボタンを押下して、交換機でWarm-Spareを組みなおします。
代替機でWarm-Spareの組み直し (1/2) Parameter Sheetなどの設定情報の控えを元にして、Warm-Spareを設定し直してください。
代替機でWarm-Spareの組み直し (2/2)
代替機の追加後の状態
代替機の追加後は、本来SpareだったMXがPrimaryとなり、後から追加した代替機がSpareとなります。
この段階ではPrimaryとSpareの役割は入れ替えないでください。入れ替えてしまうと後の作業でサービス断が長引く可能性があります。
故障機をラックから取り外して代替機と交換
故障機をラックから取り外して代替機と交換します。
ケーブル結線における注意点ですが、Uplink側とLAN側の結線順序のよってサービス影響の観点が異なるため留意してください。
代替機の結線順序
環境に応じて、Uplink側とLAN側のどちらから作業するかを決めてください。
Uplink側からケーブルを繋ぐと、設定が同期された時点でDual Masterになります。
LAN側からケーブルを繋ぐと、DHCPで不意にアドレスが払い出される可能性があります。
設定の同期前 (初期化状態)ではDHCP Serverが動作しているため、先にUplinkを繋がないと意図しないアドレスが払い出されてしまう可能性があります。
代替機のFirmware Upgrade
代替機がNetworkのFirmware Versionと一致していない場合は、設定の同期後にFirmware Upgradeが走り再起動が発生します。
LEDの点灯・点滅の状態を物理的にも目視してFirmware Upgradeの進行状態を確認してください。
予備機がSpareの状態だと再起動が発生しても、基本的にはサービス影響が発生しないため、この段階まではPrimaryとSpareを入れ替えない手順にしています。
LEDの情報に関しては、下記のDocから該当モデルの Installation Guide を参照してください。
故障機と代替機の交換後
この時点で、故障機と代替機の交換後は済みましたが、正常時と比べるとPrimaryとSpareが変化している点に留意してください。
PrimaryとSpareの入れ替え
PrimaryとSpareの状態を入れ替えます。
Dashboard上では入れ替えマークのボタンを押下します。
交換の完了後
交換の完了後は、疎通確認などをして動作に問題がないか適宜確認してください。
Meraki DashboardのAdministratorアカウント (Non-SAML User)は必ず1つは残す必要がある
概要
Meraki DashboardのAdministratorアカウント (Non-SAML User)は、必ず1つは残す必要があります。
2022年04月頃にサポートに仕様の確認を行った情報となります。
注意点
SAMLによるSSO (Single Sign-On)を設定していて、管理者権限を持つSAML Userが居たとしても、必ず1つはAdministratorアカウント (Non-SAML User)を残す必要があります。
本仕様が影響するシナリオ
実務だとAdministratorアカウントを社員の個人メール アドレスに紐付けてしまうと、退職や人事異動などの影響を受ける可能性があるため、 メーリング リストをAdministratorアカウントとして登録するのが想定されます。 ですが、MFAでGoogle Authenticatorを有効化すると個人の端末に紐付ける必要が出てきてしまい、運用上の問題になる可能性があります。
そのため、複数の社員のメール アドレスに管理者の権限を付与しておいて、人事異動の季節などに定期的に見直す方法が検討候補に入る可能性があります。 しかしながら、同一のメール アドレスであるMeraki Dashboardのアカウントが既に存在すると、SAMLによるSSOが出来なくなります。 そうなってしまうと、社員によってログイン方法が異なるためユーザビリティが低下してしまいます。
上述の点を改めてまとめると、 全てのアカウントの管理を認証系の製品 (例: Duo Security)で統一したいものの、 Administratorアカウント (Non-SAML User)は必ず残す必要があり、 プロジェクトの中から代表となる社員をAdministratorアカウント (Non-SAML User)にしてしまうと、その社員だけSSOが出来なくなるジレンマが起きます。
