初めてのリーダー・マネジメント振り返り

リーダーを担うのは2回目ですが、1回目はリーダー2人体制だったため、2回目が実質はじめてのリーダーという感じでした。
とても濃い2年間だったため、振り返り、反省、学び等を残しておきます。

リーダー経験振り返り
①逆風の中での引き継ぎ
【状況】 2階級上のハイスペックな前任者の退職に伴う業務引き継ぎを開始。リーダー案件2つ、SE案件2つの計4案件を担当することに。
【課題】 引き継ぎ期間は1か月あったが、前任者の有給消化や既存業務のクローズ対応が重なり、実質的な引き継ぎは2週間。未知の技術(IP-KVM等)もあり、強いプレッシャーを感じる。
【反省】 限られた時間の中で、情報の優先順位付けや効率的なキャッチアップ方法をさらに工夫する余地があった。

②キャッチアップの限界と挫折
【状況】 新体制での業務がスタート。リーダー案件の把握に注力するあまり、SE案件まで手が回らず、お客様から存在価値を問われるクレームが発生。
【課題】 日々の業務に加え、休日・夜間のサービス残業で情報を補うが、精神的・時間的に限界を迎える。
【学び・反省】 「できないと思われたくない」というプライドと、上長への気後れから、キャパシティオーバーを早期に相談できなかった。「早めのエスカレーション」はリーダーの義務であると痛感。

③転機と「巻き込み」の成功
【状況】 既存顧客から新規案件の相談を受け、3つ目のリーダー案件がスタート。これに伴いSE案件から離脱し、リソースをリーダー業務へ集中させる。
【行動】 8月の契約更新期、初めての契約実務に対し、自力の限界を認めて上長へSOSを発信。深夜まで上長のフォローを仰ぎながら、不慣れな契約対応や顧客説明を完遂。
【成果・教訓】 一人で抱え込まず**「周囲を巻き込む」ことで、自分以上の役職が担うべき難易度の高い業務を完遂**でき、大きな自信と経験に繋がった。

④属人化の罠とテックリードへの成長
【状況】 3案件の同時リーダーという社内でも稀な状況を完遂すべく、がむしゃらに邁進。社内評価は高まるが、私生活を犠牲にした働きにより心身に過度な負荷(適応障害に近い症状)がかかる。
【課題】 自身の技術力(オンプレNW、SV構築)に頼りすぎた結果、業務が属人化。「自分と同じレベルの人間がいればいい」という自惚れに近い悩みに陥り、適切なデリゲーション(権限移譲)ができていなかった。
【反省】 自分のタスクに余裕がないため、メンバーへの依頼が雑になり、結局自分でやり直すという悪循環。「人に任せるための準備」への投資不足を痛感。

⑤完遂とチームの絆
【成果】 綱渡りのような調整の末、スケジュール通りシステム構築・検証を完了。リリース後の課題はあるものの、チームメンバーから「あなたでなければできなかった」と労いの言葉を受ける。
【総括】 プレイヤーとしての強みを活かしつつも、マネジメントの難しさと「持続可能な働き方」の重要性を深く学んだ2年となった。

■マネジメントの道に進んでいきたいのか?
約2年、がっつりとマネジメントやリーダーを経験したうえで、今後もマネジメントの道に進んでいきたいかと言われると「感情的にはNO」です。
やはりプレイヤー時代の「時間を忘れ業務(設計/構築の検討や切り分け)に没頭していた自分」の方が生き生きしていました。
しかし、キャリア的な生存戦略を考えると、全くマネジメントをしないのは大きなリスクになるため、
プレイヤーとしての専門性を維持/向上しつつ、マネジメントも可能なリードエンジニアを目指すのが良いかなと今時点では考えております。
☆中長期的なToDo
・マネジメントの型を身に着ける
 →不要な(強迫観念に駆られた)サビ残を減らす、技術的好奇心を満たすためのサビ残は悪くない
・サードプレイスを探す
 →休息の効率化

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