Meraki vMX (Virtual MX)のSpoke設定時はFull Tunnelをサポートしていない (2022年05月時点)

Meraki

仮想アプライアンスであるMeraki vMX (Virtual MX)は、Spoke設定時に他のMXシリーズに対してFull Tunnelの指定ができません。
表現を変えると、Meraki vMX (Virtual MX)はSpoke設定時にSplit Tunnelでのみ動作します。

補足ですが、Full Tunnelとはサービス系の全ての通信が、対向のAuto VPN Peer経由となるようにDefault Routeを向けるのを指します。

Meraki vMXでは他のMXに対するFull Tunnelはサポートされない

勘違いしないように強調しますが、あくまでも仮想アプライアンスのvMX (Virtual MX)から他のMXシリーズに対してのFull Tunnelの指定が出来ないだけです。

物理アプライアンスのMXからは、仮想アプライアンスのvMX (Virtual MX)に設定上はFull Tunnelを張れます。ただし、通常のvMX (Virtual MX)は送信元NATできないため、Meraki vMX (Virtual MX)経由でのInternetへの接続が行えず、わざわざMXからvMX (Virtual MX)に対してFull Tunnelを張れるように設計する意義は薄いと考えられます。この話は、例外的な考慮点も含めると本題から脱線するので本記事内では掘り下げません。

機能のサポート可否の話をした際に、非対応だと問題視する方がいらっしゃるかもしれません。

ですが、そもそもvMX (Virtual MX)でFull Tunnelを張る必要があるでしょうか。

Public Cloud基盤上の仮想アプライアンスのvMX (Virtual MX)は、Internetに直接的に面しているのが基本であり、vMX (Virtual MX)はHubとなるのがBest Practicesに準ずる構成です。更には、Spokeの設定時はDC-DC Failover構成による冗長化を行えないため、一般的にEnterprise環境ではvMX (Virtual MX)をHubとして設計せざるを得ません。
そのため、Spokeに設定した上で他拠点宛にFull Tunnelをわざわざ張る意義は基本的にないと考えられます。仮にvMX (Virtual MX)でFull Tunnelが今後サポートされても、Best Practicesから逸脱した特殊な構成になると、それこそリスクが高くなります。
よって、製品特性を見極めて顧客環境に適切な設計で導入しましょう。

Meraki vMX (Virtual MX)のFull Tunnelのサポート可否の情報は、2022年05月頃にサポートの方に確認しております。

2022-05-15

Meraki DashboardのShardの意味合い

Meraki

Meraki Dashboardには Shard と呼ばれる用語があります。
Meraki DashboardのURLは https://nXXX.meraki.com/ のようなフォーマットになっておりますが、nXXX の部分が Shard の情報となります。

Shard は破片のような意味合いがあるようですが、Meraki Dashboard上での意味合いは収容先テナント (Node)のイメージが適切だと思われます。

ejje.weblio.jp

Organizationの収容先の観点

Organizationによって収容先のShardが異なる可能性があります。例として、筆者がテスト用に作成したOrganizationのShardは下記のようになっています。

例1: https://n212.meraki.com/

例1: n212 のShard
例2: https://n354.meraki.com/
例2: n354 のShard

Shardと影響範囲

Organizationによって収容先のShardが異なるため、Meraki Cloud側に障害があった場合に影響を受けるShardが変わる可能性があります。そのため、Meraki Communityなどで障害の状況を確認したいような場合は、収容先のShardの情報を付け加えるのが好ましいと想定されます。ただし、そのようなシナリオではトラブルシューティングでMeraki Cloud被疑である情報を持ったうえで、サポートに問い合わせるのが好ましいです。

Meraki Dashboard APIとShard

Meraki Dashboard APIのBase URLは https://api.meraki.com/api/v1 になっており明示的なShardの指定は不要です。
古い情報ではShardを直接指定しているパターンも見かけます。

documentation.meraki.com

The API version must be specified in the URL:

https://api.meraki.com/api/v1/<resource>

developer.cisco.com

Every API request will begin with the following base URI.

https://api.meraki.com/api/v1

参考情報

Network from the cloud with Cisco Meraki
https://www.cisco.com/c/dam/m/sl_si/events/2016/cisco_dan_inovativnih_resitev/pdf/cisco-dan-odprtih-vrat-meraki.pdf
該当スライド: 9スライド目
- Customers are partitioned across multiple ‘shards’ (geo and host provider redundant servers)
- Master shard demultiplexes and redirects network admin to their shard
- Shards form a mesh network, enabling efficient routing of management traffic
- Each shard capable of supporting up to ~10000 Meraki devices and 00’s of 000’s of client endpoints. Capacity to hold >1 year of network statistics

2022-05-14

BIG-IP Forward Proxy構成のBASIC認証 (LocalDB Auth版)

BIG-IP

BIG-IP Forward Proxy構成でのBASIC認証の設定例を紹介します。 Forward Proxy構成では、SSLOの使用有無によって適用方法が異なる点に注意が必要です。

認証の連携先は、BIG-IP自身が内部的に保持しているLocal DBを使用します。

BASIC認証 (LocalDB Auth)の認証フロー (Per-Session Policy)

対象バージョンの情報
設定の流れ
設定手順

対象バージョンの情報

本記事に記載の情報は、下記のバージョンで調査を行っております。

F5 BIG-IP Virtual Edition Version 16.1.2
BIG-IPのモジュールは、LTM, APM, SSLOを有効化しております。
SSL Orchestrator Package Version 16.1.0
SSLOはiApps LXのパッケージとして提供されているため、個別のバージョン情報があります。

設定の流れ

Local DBの設定を先に行い、BASIC認証の認証フロー (Per-Session Policy)を作成する際にLocal DBを認証連携先として登録します。そして、認証フロー (Per-Session Policy)をVirtual Serverに適用します。

最後のVirtual Serverへの認証フローの適用は下記の2種類のパターンがあります。

SSLOを使用している場合 (SSLO実装)は、SSLOのGuided Configurationから認証フローの紐付けを行います。
SSLOのGuided ConfigurationからHTTP Forward Proxy向けVirtual Serverに間接的に紐付けが行われます。
SSLOを使用していない場合 (標準実装)は、HTTP Forward Proxy向けVirtual Serverに直接紐付けを行います。

設定手順

Local User DB Instanceの作成

メニュー: Access > Authentication > Local User DB > Instances に移動します。

メニュー: Access > Authentication > Local User DB > Instances
Create New Instance... ボタンを押下して、任意のパラメータでLocal User DBのInstanceを作成します。
本記事では下記のパラメータを指定しています。

設定項目設定値備考

Name LocalUserDB 任意の名称で Local User DBのInstanceを作成します。

Create New Instance... ボタン

Create New Local User DB Instance

設定項目	設定値	備考
Name	LocalUserDB	任意の名称で Local User DBのInstanceを作成します。

Local Userの作成

メニュー: Access > Authentication > Local User DB > Users に移動します。

メニュー: Access > Authentication > Local User DB > Users

Create New User... ボタンを押下して、任意のパラメータでLocal Userを作成します。
本記事では下記のパラメータを指定しています。

設定項目	設定値	備考
User Name	testuser	任意のLocal User名で作成します。
Password / Confirm Password	PASSWORD	任意のPasswordを指定します。筆者は検証環境であったので PASSWORD の文字列を指定しています。
Instance	/Common/LocalUserDB	先ほど作成していたLocal User DBのInstanceを指定します。

BASIC認証のPer-Session Policyの作成

メニュー: Access > Profiles / Policies > Access Profiles (Per-Session Policies) に移動して、Create... ボタンを押下して下記のパラメータを参考にAccess Profile (Per-Session Policy)を作成します。

設定項目	設定値	備考
Name	BASIC_Auth	任意の名称で作成します。
Profile Type	SWG-Explicit	L3 Explicit Forward Proxy構成のため `SWG-Explicit` を指定しています。
Languages (Accepted Languages)	English (en)	任意の言語を指定します。
Default Language	English (en)	任意の言語を指定します。

Access Profiles (Per-Session Policies) と Per-Request Policies と似たような名前なので、設定対象を間違えないように注意してください。

メニュー: Access > Profiles / Policies > Access Profiles (Per-Session Policies) の拡大画面

Access Profiles (Per-Session Policies) の設定箇所 (1/2)

Access Profiles (Per-Session Policies) の設定箇所 (2/2)

メニュー: Access > Profiles / Policies > Access Profiles (Per-Session Policies) に移動して、先ほど作成したAccess Profile (Per-Session Policy)を Edit... します。
Visual Policy Editorの画面が開かれるため、この後は認証フローを編集します。

Access Profile (Per-Session Policy) の編集

Visual Policy EditorでAccess Profiles (Per-Session Policies)`の編集

BASIC認証のAccess Profiles (Per-Session Policies)の全容

BASIC認証のPer-Session Policyの全容は下記の画面の通りとなります。順を追ってVisual Policy Editorの各Itemの設定を示していきます。

Access Profiles (Per-Session Policies)の初期状態

Access Profiles (Per-Session Policies)の初期状態は下記の画面のようになっています。

HTTP 407 ResponseのItemの設定

HTTP 407 Response のItemは下記のパラメータで作成しています。

設定項目	設定値	備考
Name	HTTP 407 Response
Basic Auth Realm		Realmは指定が必須ではないため、この例では省略しています。
HTTP Auth Level	basic	BASIC認証を指定します。
Language	en	言語設定は適宜指定します。

LocalDB AuthのItemの設定

LocalDB Auth のItemは下記のパラメータで作成しています。

設定項目	設定値	備考
Name	LocalDB Auth
LocalDB Instance	/Common/LocalUserDB	事前に作成していたLocal User DBのInstanceを指定します。

Ending (Allow, Deny)の設定

Local User DBによる認証成功時に許可を行いたいため、 LocalDB Auth のItemの Successful の分岐に対応するEnding (Allow, Deny)を Allow に指定します。

Apply Access Policyの実行

Visual Policy Editorでの設定が完了したら、画面の左上にある Apply Access Policy を押下します。

Per-Session Policyの適用 (2パターンあり)

SSLOを使用している場合 (SSLO実装) と SSLOを指定しない場合 (標準実装) の2パターンあるので適切な手順を参照してください。

↓↓↓↓ ここからが SSLOを使用している場合 (SSLO実装) です。 ↓↓↓↓

SSLOを使用している場合 (SSLO実装)

筆者は下記の記事をベースに作成した設定に紐付けております。

myhomenwlab.hatenablog.com

SSLOで設定をデプロイし直すと、バージョンや設定状況に応じて既存設定が上書きされる可能性があります。設定が上書きされるのを忌避する場合は、SSLOを指定しない場合 (標準実装) の手順を参考にしてください。

設定の同期

冗長構成の場合はSSLOのGuided Configurationの設定を始める前に、設定の同期漏れによる設定崩壊を避けるために事前にConfigSyncをしてください。

SSLOの設定変更対象への移動

メニュー: SSL Orchestrator > Configuration の Topologies タブより、設定変更対象を開きます。

Interception RuleのAccess Profileの指定

Interception Rule の設定画面を開きます。

Interception Ruleの設定画面
Proxy Server Settings セクションのAccess Profileの設定に、今回作成したAccess Profile (Per-Session Policy)を指定します。

Access Profileの指定

SSLOの設定変更後のデプロイ

Summary の画面を開いて、Preview Merge Config もしくは Deploy の適切な方を選んでデプロイします。

SSLOの設定変更後のデプロイ

↑↑↑↑ ここまでが SSLOを使用している場合 (SSLO実装) です。 ↑↑↑↑

↓↓↓↓ ここからが SSLOを指定しない場合 (標準実装) です。 ↓↓↓↓

SSLOを指定しない場合 (標準実装)

HTTP Forward Proxy向けのVirtual Serverに適用します。
筆者は下記の記事をベースに作成した設定に紐付けております。

myhomenwlab.hatenablog.com

設定対象のHTTP Forward Proxy向けVirtual Serverに移動

設定対象のHTTP Forward Proxy向けVirtual Serverに移動します。
筆者の環境の下記の画面キャプチャでは、Service Port が 8080 で受け付けているVirtual Serverが設定対象になります。

Access Profileの指定

Access Policy のセクションから Access Profile の設定に、今回作成したAccess Profile (Per-Session Policy)を指定します。

↑↑↑↑ ここまでが SSLOを指定しない場合 (標準実装) です。 ↑↑↑↑

ConfigSync (冗長構成の場合)

冗長構成の場合はConfigSyncで設定変更後の同期を行ってください。

疎通確認

curl コマンドを用いる場合は、下記を例に引数を環境に応じて調整してください。

curl --proxy ADDRESS:PORT --proxy-user 'testuser:PASSWORD' http://www.example.com

2022-05-13

CML2でNodeのCPUリソースを制限する

CML2ではNodeに対してCPUリソースの制限が可能です。
疎通確認専用のような用途でリソース割り当てが少なくてもよい検証用NodeにCPUリソースの制限をかけるのに活用できます。

設定方法

Workbench (Lab)から設定対象Nodeを選択して SIMULATE タブを開き、CPU Limit の設定を 20 % から 100 % の範囲で制限できます。
値を変更した際は、EnterキーやApplyボタンで設定を確定するのを忘れないようにしてください。また、一度起動してしまうと、WIPE NODEで設定情報を消さない限り、CPU Limit の設定変更ができない点に留意してください。

下記の画面キャプチャは CPU Limit の下限と上限の確認を行った際のものです。

Workbench (Lab)ではなく大元のNode定義ファイル (Node Definitions)自体への設定も可能ではありますが、CML2のイメージ (Refplat ISO)に含まれているNodeは読み取り専用になっており直接の変更はできないようでした。

Plug and Play ConnectでCisco SD-WAN関連のSoftware Deviceを追加するためのBase PIDの情報

Cisco SD-WAN

Plug and Play ConnectのPortal画面にて、Cisco SD-WAN関連のSoftware Deviceを追加するためのBase PIDの情報をメモします。

製品シリーズ	Base PID
vEdge Cloud	VEDGE-CLOUD-DNA
ISRv	ISRV
CSR 1000V	CSR1KV
Catalyst 8000V	C8000V

何文字か入力してマッチしているBase PIDがあると、候補がポップアップして表示されます。

Software Deviceの一連の追加手順自体は、下記のCisco Communityの記事が参考になります。

community.cisco.com

2022-05-13

Cisco IOS-XE SD-WAN (cEdge)でCLIからルートCA証明書の取り込みを行う

Cisco SD-WAN

Cisco IOS-XE SD-WAN (cEdge)でCLIからルートCA証明書の取り込みを行う方法を紹介します。

一般的なルートCA証明書の取り込み手順は、File ServerにルートCA証明書を配置してCisco IOS-XE SD-WANから copy コマンドで取得する手順になると思われます。しかしながら、障害対応での筐体交換や検証のような場合はCLIから貼り付けれた方がFile Serverのセットアップが不要になる利点があります。

CLIからは tclsh コマンドでルートCA証明書の取り込みを行います。
注意点ですが、Cisco IOS XEにはAutonomous ModeとController Modeが存在しますが、Controller Modeでは tclsh コマンドが隠しコマンドとなっているため一時的に有効化します。

隠しコマンドの一時的な有効化の手順が手間であるのならば、Controller Modeに変換する前に、Autonomous Modeの状態で tclsh コマンドを利用して取り込む方法もあります。

本手順はCML2上のCSR 1000VとCatalyst 8000Vで確認しております。

Controller Modeで隠しコマンド (tclsh含む)を有効化
ルートCA証明書の取り込み
Controller Modeで隠しコマンド (tclsh含む)を無効化
関連ドキュメント

Controller Modeで隠しコマンド (tclsh含む)を有効化

tclsh コマンドを使用するために、一時的に隠しコマンドを有効化します。後ほどの手順で無効化し直します。

config-transaction

service internal

commit

end

debug platform software sdwan unlock-ios-cl

ルートCA証明書の取り込み

ルートCA証明書を実際に取り込みます。
-----BEGIN CERTIFICATE----- から -----END CERTIFICATE----- はルートCA証明書の情報となるため、書き換えて使用してください。

tclsh
puts [open "bootflash:ROOTCA.pem" w+] {
-----BEGIN CERTIFICATE-----
MIIDBTCCAe2gAwIBAgIUBoY/fDZ42wHpr9fBVAjSfidDJJkwDQYJKoZIhvcNAQEL
BQAwEjEQMA4GA1UEAwwHdm1hbmFnZTAeFw0yMjA1MTAwODEyNTZaFw0zMjAyMDcw
ODEyNTZaMBIxEDAOBgNVBAMMB3ZtYW5hZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IB
DwAwggEKAoIBAQC327Dt8wX6DcrT5q54kFYRSYJDFnS1P8C3XS36sFKFiXchP2JF
i8DF8y3G+XeYzKjoJL/iX1j/jsqYNOmi0NWiM6PlJERdzGcoBo1RBbvF+AvDgweF
gdOvCIj/fLHeHAAO0ru7hEe3UuN60bafFpzO7/qiUtbeOmc/LgYPtBm/tBS0k/pO
eR9tWEq51rqinGBvaJw7ijuhjfNUEaZVSBPQU24t8JFRWEUvSXaHFSHZwww7z4Hi
OXW3Uiyqa6fVU3EovZwz5S+7EZk8ScHv+MWSPqvyNOwO9WdWSvEbg+gVDIsUf6c0
NJcUYEPDRMzvpeezxFGo1OiiTPVDNUREPUCJAgMBAAGjUzBRMB0GA1UdDgQWBBTo
sNRoXUpS98VjQwKkL/r2resgOzAfBgNVHSMEGDAWgBTosNRoXUpS98VjQwKkL/r2
resgOzAPBgNVHRMBAf8EBTADAQH/MA0GCSqGSIb3DQEBCwUAA4IBAQB1hE9sJuO0
szltljhAxgyaGbPlGNRZ32lETqRZbSFlhFfP2qckmcSUnVLQKTyTGTLNg3bUjh2x
0Tf0jjN5+GtZFVVXQ35MS2NaUnSqhpSJFSP0k18+MtQn22UHzLqKijiH/ikRo1Gx
HVuCzkf/pf26pDbz9fgU/eYhFKEhIED2jQRdkeffa4voSjIKWQKU9rVLpgn10kmB
Cerw2oI7tj1PV6y0ER0N8USuCWCeOuEDI7rwKZ37oxtS/Gu8DC+rSQKBAPhUzTwf
S/vUF5ZDiDCKIKm/KbN67hJ5e8oPhEgdOhbFeXFJDqIJiDUxZMgHZl4Sw4fAhUD2
3hHDVXXtb0vE
-----END CERTIFICATE-----
}
exit


more bootflash:ROOTCA.pem

Controller Modeで隠しコマンド (tclsh含む)を無効化

日常的な運用で隠しコマンドを常用すべきではないため、無効化の状態に戻しておきます。

no debug platform software sdwan unlock-ios-cl

config-transaction

no service internal

commit

end

個人での検証用途でCisco Duo Securityを1 Userからライセンス購入する

Duo Security

Cisco Duo SecurityのDashboard上では最小でも10 Userからの契約となりますが、1 Userから年間ライセンスを購入する選択肢もあります。
補足ですが、Duo SecurityのDashboard上では最小10 Userにはなりますが月単位での契約が可能な利点があります。

筆者は個人での検証目的のため安全堂から DUO-MFA 1-999 を1 User分だけまず購入しました。

DUO-MFA 1-999
www.anzendo.jp
DUO-ACCESS 1-999
www.anzendo.jp
DUO-BEYOND 1-999
www.anzendo.jp

検証目的でも権限の切り替えのために複数Userが必要になる可能性があるため、最初から必要数分の購入検討するのが好ましいと想定されます。
さらにエディションの混在は不可のため、Trialで必要な機能を確認しつつ購入対象を選ぶのがオススメです。

ちなみに、年間ライセンスの個人購入が完了した際のDashboardのBilling画面は下記のような表示となりました。

Duo AccessのTrial期間が残ってる状態で、Duo MFAの年間ライセンスが紐付いた場合の画面のため、ライセンスの購入状況に応じて表示内容が変わる可能性があります。