VMware Workstation PlayerからESXiに移行する

何をするか

VMware Workstation Player上で動かしている仮想マシンのイメージファイルをESXiで使えるように変換して使用する。

qemuマシン側

VMware Workstationフォルダにovftool.exeがあることを確認する
・ディレクトリ
C:\Program Files (x86)\VMware\VMware Workstation\OVFTool

変換前のvmxファイルと変換後のovfファイル名を指定する
C:\Program Files (x86)\VMware\VMware Workstation\OVFTool>ovftool.exe D:\VM\kali-linux-2023.3-vmware-amd64.vmwarevm\kali-linux-2023.3-vmware-amd64.vmx C:\Users\xxx\Desktop\tmp\20231104\kali-linux.ovf

Versa SD-WANルータ ZTP

■VersaZTP
・デバイスのZTP情報

 -デバイスアクティベーションのための初期ZTP接続情報を作成するために使用し、ローカルアクティベーションデバイスをCPEデバイスに接続することができます。

 -このテンプレートから作成されたデバイスのZTPコンフィギュレーションは、アクティベーション専用です-Temporary Configuration

・アクティベーションメールとトークン

 -デバイステンプレートがZTP対応テンプレートとして構成されている必要があります。

 -電子メールを生成するためにVersa DirectorのSMTP設定が必要です。

 -またはZTPトークンを生成し、CPEへのローカルWebブラウザーの接続で使用することができます。

 -ZTP情報を取得するデバイスを選択 URLベースのZTP情報アイコンをクリック

・ZTP URL

アクティベーション情報をトークン文字列にエンコードしたURLを含む 接続機器のウェブブラウザに直接貼り付け可能

・URLアクティベーション

 -DHCP対応デバイスをCPEデバイスのイーサネットポート2またはイーサネットポート4に接続する デバイスがIPアドレスを受信し、CPEと通信できることを確認する
→ifconfigでCPEからIP取得出来てること、CPE LAN IPにping通ることを確認

・ブラウザアクティベーション

電子メールのリンクをクリックするか、ブラウザのアドレスバーにトークンのURLを貼り付けてください。

・コンフィギュレーション情報

ブランチ構成情報がデバイスに存在する(URLトークンから抽出される)

・起動状況

アクティベーションが完了すると、デバイスが再起動し、SD-WANに参加します。

・ステージングスクリプトによるFlexVNF CPEのアクティベーション

/opts/versa/scripts ディレクトリにあるスクリプトは sudo パーミッションが必要です。

すべてのスクリプトオプションが表示されるわけではありません。オプションは ./staging.py –helpコマンドを実行することで見つけることができます。
デバイスは自動的に再起動し、SD-WANに追加されます。
 1)スクリプト名
 2)コントローラで必要とされるローカル認証情報
 3) コントローラーに要求されるリモート認証の認証情報
 4) コントローラのデバイステンプレートに設定されているデバイスのシリアル番号
 5)コントローラIPアドレス
 6)プロバイダに接続されたWANインターフェース(コントローラ側ポート)
 7)CPEデバイスのWANインターフェースアドレス
 8)サービスプロバイダー側WANポートのゲートウェイアドレス

Azure AD ハイブリッドAD joinとSSOの実装

■目的
AADjoinデバイス、HybridADjoinデバイスにてsSSO(シームレスSSO)を有効にする
※社外NWからの接続はAzureADユーザでログイン時のみsSSO有効化

■必要設定
ユーザプロビジョニング等の初期設定は実装済の想定

・AADC
 -デバイスオプションにてHybrid AD join有効化
 -同期オプションにてデバイスのをjoin有効化
 -ユーザサインインオプションにてSSO有効化
・GPO(端末のインターネットオプション設定でも可)
 -MSwebサイト、AAD関連サイトをイントラネット判定
 -イントラゾーンサイの自動ログオンを有効化
・FW設定
 -AADC→オンプレAD
 -AADC→AAD
 -クライアント→AAD
※プロキシ環境の場合は、イントラゾーン登録Webサイトのみ許可
 
■FWルール設定詳細
・AADC→オンプレAD
・AADC→AAD
https://learn.microsoft.com/ja-jp/azure/active-directory/hybrid/reference-connect-ports

・クライアント→AAD
https://learn.microsoft.com/ja-jp/azure/active-directory/devices/howto-hybrid-azure-ad-join

https://learn.microsoft.com/ja-jp/azure/active-directory/hybrid/tshoot-connect-connectivity

■イントラ判定
https://learn.microsoft.com/ja-jp/azure/active-directory/devices/howto-hybrid-join-downlevel

ここに記載のURLに加えてonmicrosoft等のSWGベンダー指定のバイパス除外ドメインも?
これらはプロキシバイパスされる

Azure ADの種類

■Azure ADとは
クラウドベースのディレクトリサービス
オンプレミスADとの連携が取れるのが特徴

■Azure ADを利用するケース
・Azure AD registered:AADにユーザが登録されている、端末はドメイン参加していない
・Azure AD joined:AADにユーザが登録されている、端末はドメイン参加している
・Hybrid Azure AD joined:AAD/オンプレADに共通のユーザが登録されている、端末は両方のドメインに参加している

■各ケースの特徴
・Azure AD registered
-○メリット
IDaaSとしてAzure AD使うだけなので、端末がドメイン参加する形ではなく端末側設定が不要
Windows以外のデバイスでも利用可能

-●デメリット
オンプレミス側のユーザ管理は別途AD等(ディレクトリサービス)が必要となる
※ユーザ情報自体はオンプレADからプロビジョニング可能

個人利用等でオンプレにADが必要ない場合はこれでも十分

・Azure AD joined
-○メリット
オンプレADを持たない企業でもディレクトリサービスとして利用できる
SSOができる(クラウドサービスのみ)

-●デメリット
インターネット接続がない環境では利用不可
オンプレAD等と併用する場合はIDが二重管理になる

オンプレにADが無くディレクトリサービスを利用したい場合はこの選択肢おあり

・Hybrid Azure AD joined
-○メリット
オンプレADのユーザでAzure ADの機能も使えるようになる
SSOができる(クラウドサービス/オンプレリソース両方)

-●デメリット
オンプレおよびAzure AD Connect + 各種設定が必要

環境構築の手間はあるが、利便性では圧倒的にこれ

RIPv2の自動経路集約(Auto Summary)について

RIPv2の動作検証をしていた際に想定と違う動作をしたため
その時に調べた内容や検証した内容についてのメモです。

概要

RIPv2はデフォルトで自動経路集約(Auto Summary)が有効になっているが、
ある条件の経路については集約されなかった。

ざっくり構成図

各機器Config

router1

router2#sh run
interface GigabitEthernet0
ip address 172.16.1.1 255.255.255.0

interface Vlan11
ip address 10.1.1.254 255.255.255.0
!
interface Vlan12
ip address 10.1.2.254 255.255.255.0
!
interface Vlan172
ip address 172.16.2.254 255.255.255.0
!
interface Vlan173
ip address 172.16.3.254 255.255.255.0
!
interface Vlan191
ip address 192.168.1.254 255.255.255.240

router rip
version 2
redistribute connected
network 172.16.0.0

router2

router2#sh run
interface GigabitEthernet0
ip address 172.16.1.2 255.255.255.0

router rip
version 2
network 172.16.0.0

各機器ルーティングテーブル

router1

router1#sh ip route
10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks
C 10.1.1.0/24 is directly connected, Vlan11
L 10.1.1.254/32 is directly connected, Vlan11
C 10.1.2.0/24 is directly connected, Vlan12
L 10.1.2.254/32 is directly connected, Vlan12
172.16.0.0/16 is variably subnetted, 6 subnets, 2 masks
C 172.16.1.0/24 is directly connected, GigabitEthernet0
L 172.16.1.1/32 is directly connected, GigabitEthernet0
C 172.16.2.0/24 is directly connected, Vlan172
L 172.16.2.254/32 is directly connected, Vlan172
C 172.16.3.0/24 is directly connected, Vlan173
L 172.16.3.254/32 is directly connected, Vlan173
192.168.1.0/24 is variably subnetted, 2 subnets, 2 masks
C 192.168.1.240/28 is directly connected, Vlan191
L 192.168.1.254/32 is directly connected, Vlan191

router2

router2#sh ip route
R 10.0.0.0/8 [120/1] via 172.16.1.1, 00:00:04, GigabitEthernet0
172.16.0.0/16 is variably subnetted, 4 subnets, 2 masks
C 172.16.1.0/24 is directly connected, GigabitEthernet0
L 172.16.1.2/32 is directly connected, GigabitEthernet0
R 172.16.2.0/24 [120/1] via 172.16.1.1, 00:00:04, GigabitEthernet0
R 172.16.3.0/24 [120/1] via 172.16.1.1, 00:00:04, GigabitEthernet0
R 192.168.1.0/24 [120/1] via 172.16.1.1, 00:00:04, GigabitEthernet0

10.x.x.xと192.168.1.xについては経路集約されているが、
172.16.2.0と172.16.3.0は経路集約がされなかった。
この動作についてはCiscoのドキュメントにて説明されている
https://www.cisco.com/c/dam/global/ja_jp/td/docs/ios-xml/ios/iproute_rip/configuration/xe-16/irr-xe-16-book.pdf

RIP Version 2 は、デフォルトで自動ルート集約をサポートしています。クラスフル ネットワーク
境界を越えるとき、サブプレフィックスはクラスフル ネットワーク境界に集約されます。

クラスレス、クラスフルとは

クラスレスネットワーク:先頭3ビットでネットワーク部とホスト部を区別する
クラスフルネットワーク:CIDR表記(IPアドレス/サブネットマスクの1個数)でネットワーク部とホスト部を区別する

debugログ

debugログを見ても172.16.2.0と172.16.3.0は経路集約されずに広告/学習されています。
広告学習するI/Fと同一クラスフルネットワーク内のルートについては
経路集約されていないことがわかりました。
router1#
*May 4 10:44:53.699: RIP: sending v2 update to 224.0.0.9 via GigabitEthernet0 (172.16.1.1)
*May 4 10:44:53.699: RIP: build update entries
*May 4 10:44:53.699: 10.0.0.0/8 via 0.0.0.0, metric 1, tag 0
*May 4 10:44:53.699: 172.16.2.0/24 via 0.0.0.0, metric 1, tag 0
*May 4 10:44:53.699: 172.16.3.0/24 via 0.0.0.0, metric 1, tag 0
*May 4 10:44:53.699: 192.168.1.0/24 via 0.0.0.0, metric 1, tag 0
router2#
*May 4 08:54:47.099: RIP: received v2 update from 172.16.1.1 on GigabitEthernet0
*May 4 08:54:47.099: 10.0.0.0/8 via 0.0.0.0 in 1 hops
*May 4 08:54:47.099: 172.16.2.0/24 via 0.0.0.0 in 1 hops
*May 4 08:54:47.099: 172.16.3.0/24 via 0.0.0.0 in 1 hops
*May 4 08:54:47.099: 192.168.1.0/24 via 0.0.0.0 in 1 hops

結論

RIPv2がRIPデータベースのクラスフル境界内に複数のサブプレフィックスを持ち、
同じクラスフル境界内のサブプレフィックスを所有するインターフェイスからアップデートを送信する場合、
RIPv2は自動経路集約(Auto Summary)を実行しません。

無線用語(EIRP、RSSI、SNR)と電波強度の目安

概要

無線用語(EIRP、RSSI、SNR)の説明と快適な無線利用環境の目安の数値について

各用語

dbm(デシベルミリワット)
信号強度の単位
0dBmに近いほど(数値が高いほど)優れた信号

EIRP(Equivalent Isotropic Radiated Power)
実効等方輻射電力、簡単に言うと電波集力機器側の送信信号強度
Arubaの無線コントローラの場合はdbm単位で設定が可能
APごとのMAX値はAP135は21.5、AP325は27.0、AP515は30.0。

EIRP27だと建物Aの無線APへ建物Bで接続できることを確認できた。
※2.4GHzで直線距離は60m程

EIRP6でも同一フロアの壁に設置してあるAPから反対側の壁側で接続できることを確認できた。
※5GHzで直線距離は20m程

RSSI(Received Signal Strength Indicator)
受信信号強度、クライアント側のWi-Fiアナライザ等で確認できる。
——————————————————————————————————————————-
-67 dBm Very Good Minimum signal strength for applications that require very reliable, timely delivery of data packets. VoIP/VoWi-Fi, streaming video
-70 dBm Okay Minimum signal strength for reliable packet delivery. Email, web
———————————————————————————————————–
※下記サイトより引用、metageek社はサイトサーベイなどで使うスペクトラムアナライザのメーカ
https://www.metageek.com/training/resources/understanding-rssi/#:~:text=RSSI%20vs%20dBm,levels%20in%20mW%20(milliwatts).

SNR(Signal-to-Noise Ratio)
信号対雑音比 (RSSI – ノイズ他電波の信号強度) ※同一帯域のSSIDごとにSNRは計算できる
そのAPからみたときに同一チャネルを使ってる他電波との雑音比、大きい方が干渉が少ない
——————————————————————————-
25dB to 40dB SNR = Very good signal (3 – 4 bars); always associated; very fast.
——————————————————————————-
※下記サイトより引用、Ciscoが買収したNW機器メーカ(meraki)が引用している記事
http://www.wireless-nets.com/resources/tutorials/define_SNR_values.html

結論

ビデオストリーミング等を快適に見るためには、無線利用場所において下記2つの条件を満たしていること
・「利用するSSIDから受信する電波(RSSI)が強い」
RSSI:利用するSSIDのRSSIが-67 dBm 以上
・「同一周波数を利用する強い電波(SNRが低い)SSIDが存在しない」
SNR :同じ周波数を使用するSSID(特に同一チャネル)で25 dB 以下のSSIDが存在しない

※利用する電波や付近の電波の強度(RSSI)を計算するにはスマホは「Wi-Fi Analyzer」PCは「inSSIDer」等のフリーソフトで確認可能
SNRはRSSIを元に計算可能

OpenVPNを使ってクライアントVPNを構築

何をするか

外出先のインターネットからクライアントVPNを使って自宅NWに接続する。

OpenVPNサーバの構築

必要なパッケージをインストール

作業ディレクトリを作成してコピーして移動。

CA(認証局)の初期化。

CA(認証局)を作成。

CA秘密鍵のパスワードが聞かれるので任意のパスワードを入力。

処理が完了すると以下のファイルが作成される。

DH(Diffie-Hellman)パラメータの生成。

サーバ用秘密鍵、証明書の作成
※nonpassオプションをつけるとパスフレーズを省略できる。

クライアント用証明書、秘密鍵の作成
※nonpassオプションをつけるとパスフレーズを省略できる。

CA秘密鍵のパスワードが聞かれるのでパスワードを入力

処理が完了すると以下のファイルが作成される。
サーバ用証明書:client_1.crt
サーバ用秘密鍵:client_1.key

OpenVPNのテンプレコンフィグをコピー。

メインの設定ファイルを編集。

vpnux Clientの設定

vpnux Clientを起動して「プロファイル」→「追加」を押下する。
■一般設定
プロファイル名:任意
VPNサーバ:OpenVPNサーバのグローバルIP
デバイス:TUN
拡張設定:[LZO圧縮を有効にする]をチェック
CA証明書:「ca.crt」を選択
認証:「証明書認証(PKI)を使用」を選択
証明書認証(PKI)/証明書:「client1.crt」を選択
証明書認証(PKI)/秘密鍵:「client1.key」を選択
■詳細設定
追加セキュリティ設定:「TSL-Auth HMAC署名を使用」をチェック
追加セキュリティ設定/共有鍵:「ta.key」を選択

ログからのトラシュー

暗号方式を大文字で記載していた。
cipher AES-256-CBC → cipher aes-256-cbc
Fri May 15 10:44:27 2020 TLS Error: cannot locate HMAC in incoming packet from [AF_INET]61.86.178.47:1194

プロトコルのipv4の指定が抜けていた。
udp → udp4
Fri May 15 10:37:02 2020 Could not determine IPv4/IPv6 protocol. Using AF_INET

CentOS7のサーバ構築でうまくいかない時の共通確認事項

サーバを構築する際にいつも忘れてしまうところ。

・SELINUXの無効化
状態確認
getenforce

永久的に無効化
vi /etc/selinux/config
—-
SELINUX=enforcing
—-

・FWの無効化
状態確認
systemctl status iptables
systemctl status firewalld

停止(再起動すると復活する)
/etc/init.d/iptables stop
systemctl stop firewalld

・それでも無理な場合
サービスの状態確認、エラーの場合は問題箇所も表示される
systemctl status [サービス名]

エラーログ確認
vi /var/log/[ログファイル]
jounalctl

(zabbix)Template OS Linux内のデフォルトのアイテムとその表示例

zabbixサーバって構築した後も監視項目のチューニングとか大変そう、と思っていたのですがデフォルトで存在するテンプレート「Template OS Linux」で一般的な監視項目(アイテム)は既に入っていたので「Template OS Linux」内の監視項目を整理します。

zabbixサーバ、エージェントのバージョンは「3.4.15」

※右側は監視している値の表示例
■General セクション
Host boot time : 2020/4/11 7:21:16
Host local time : 2020/5/13 15:14:21
Host name : ip-172-131-49-55
System information : Linux ip-172-131-49-55 4.4.0-1105-aws #112-Ubuntu SMP Wed Mar 18 05:11:57 UTC 2020 x86_64
System uptime : 32 days, 07:50:10

■Memory セクション
Available memory : 488.09 MB
Free swap space : 436.63 MB
Free swap space in % : 68.79%
Total memory : 990.65 MB
Total swap space : 634.76 MB

■Network interfaces セクション
Incoming network traffic on eth0 : 1.46 Kbps
Outgoing network traffic on eth0 : 2.51 Kbps

■OS セクション
Host boot time : 2020/4/11 7:21:16
Host local time : 2020/5/13 15:19:21
Host name : ip-172-131-49-55
Maximum number of opened files : 99246
Maximum number of processes : 32768
Number of logged in users : 1
System information : Linux ip-172-131-49-55 4.4.0-1105-aws #112-Ubuntu SMP Wed Mar 18 05:11:57 UTC 2020 x86_64
System uptime : 32 days, 07:50:10

■Performance セクション
Context switches per second : 86 sps
CPU idle time : 99.9%
CPU interrupt time : 0%
CPU iowait time : 0%
CPU nice time : 0%
CPU softirq time : 0%
CPU steal time : 0.02%
CPU system time : 0.02%
CPU user time : 0.07%
Interrupts per second : 47 ips
Processor load (1 min average per core) : 0
Processor load (5 min average per core) : 0
Processor load (15 min average per core) : 0

■Processes セクション
Number of processes : 129
Number of running processes :  1

■Security セクション
Checksum of /etc/passwd : 4980275739
Number of logged in users : 1

■Zabbix agent セクション
Agent ping : Up (1)
Host name of zabbix_agentd running : WebServer
Version of zabbix_agent(d) running : 3.4.15