2020年12月05日(土) - 21:32 | カテゴリ:
Network
筆者はNWラボに物理装置を使う事が多かったのだが、
物を揃えたら置き場が無くなってきたのと、稼働させる電気代が増えてきて困っていた。
また、本職の都合上物理装置を使った検証をする事が減ってきた事もあり、
昨年から今年にかけて実施していた自宅サーバ刷新を機にラボをGNS3に全面移行していた。
という事で、今回はNW仮想ラボ環境をネタとして紹介しようと思う。
適当にトポロジを組んで稼働させたステータスがこちら。
トラフィックを流していないので、CPU負荷は低いがIOSを動かす為にメモリ使用率が高い。
NWラボを構築する場合、資金がある人は実機を揃えたりCMLを購入して動かす事が多そうだが、
実機を動かすにはNW装置の置き場と稼働させる電気代が課題となる。
CMLも同様にサーバが必要となる上、Ciscoにライセンス料を払うのでお金がかかる。
という事で、本格的にNW検証をしないが簡単な検証は行う事を目的に据えてGNS3を選択した。
………
従来のGNS3はクライアントPCで全部エミュレートしていたのだが、
最近のバージョンはクライアントPC上で動くGNS3コンソールと、
実際にルータをエミュレートするGNS3 VMの二つを動かす必要がある。
GNS3 VMはVirtualBoxやHyper-Vでも動くので、
仮想サーバホストを準備せずにクライアントPC単体でも環境を構築出来る。
他にはVMwareに対応しており、本領を発揮するのはVMware版となる。
今回はこのVMware版を使い、VMware ESXi上でGNS3 VMを稼働させる構成となる。
この構成の場合、クライアントPCはコンソールだけをインストールすれば良いので環境を汚しにくい。
GNS3 VMの方はインスタンスイメージをインポートすれば動くので、ラボ環境を構築しやすい。
仮想サーバホストとなるVMware ESXiを構築するのが大変ではあるが、
VMware Workstation版も存在するので、クライアントPCだけでもNWラボを構築出来る。
クライアントPCからGNS3 VMに接続する際はコツがあるので注意。
通常はHTTPS接続を行う事でGNS3の制御を暗号化すると思うが、
バージョン都合なのかHTTP接続でTCP:80を指定しないと接続出来なかった。
GNS3のメリットは無料である事に尽きる。対応するIOSを持っている場合はサーバ準備のみで動く。
デメリットはIOS-XEなど最近のIOSが動かない所。コレばかりは仕方無いので実機を使う必要がある。
ただ、GNS3でもOSPF・BGPは問題無く動くので最低限のルーティングテストは出来ると思う。
………
AWSなどIaaSと閉域網接続をする時にはルーティングにBGPを使う事が多く、
今後も同様のスキルは求められる。
今まではネットワークを弄った事が無い人が必要に迫られて弄る場合、
手軽に準備が出来るGNS3を使うのも一つの手段になるかもしれない。
« 続きを隠す
2020年11月28日(土) - 23:12 | カテゴリ:
ゲーム
今月も例に漏れず月末にゲームを購入してきた。
普段なら祖父地図で予約をして購入するのだが、
今回は購入するか最後まで迷っていたので予約無しの店頭購入となった。
という事で、CUBEの通常版カントエディションを購入してきた。
夏ノ雨は今年プレイしたので記憶に新しいが、その流れで他のゲームもプレイしてみたくなった。
他にはマンガ「勇者パーティーを追放されたビーストテイマー、最強種の猫耳少女と出会う」を一気買い。
普段、マンガをまとめ買いをする事は稀なのだが、ふとした切っ掛けで1話だけ読んだら面白かった。
秋の夜長に読みふけるのも良いかもしれない。
2020年11月21日(土) - 23:48 | カテゴリ:
Linux
6月末に検証用ドメインを購入していたが、今まで他の検証をしていて忘れていた (´・ω・｀)
折角購入した物を放置するのも勿体無いので、DSレコード申請が出来るレジストラの調査を再開したら、
バリュードメインも一部のgTLD/ccTLDにはDSレコード申請に対応している事が判明した。
そうなればシメた物。今回の検証ドメインはバリュードメインで購入していたので、
レジストラトランスファーを行わずにDSレコード申請が出来る事となる。
という事で、自力で解決不可能な問題は無くなったので、実際に自鯖権威DNSにDNSSECを導入してみた。
元ネタは、IIJエンジニアブログで公開していた次の記事。
バリュードメイン利用時のDSレコード申請方法は、筆者の技術wikiに纏めてみた。
今回はお試しでDNSSECを触ってみたかったのと、粗探しの検証も兼ねているので、
構成はIIJのサンプルを流用して変に躓かないようにした。
ゾーン管理にはBIND、ゾーン署名にKnot、DNSクエリ処理にNSDを使う多段構成になっている。
最初はKnotを使わずに、スクリプトとansibleを組み合わせてゾーン署名の自作を考えていたのだが、
レコードを書き換えた時のロック処理や、署名の自動更新が複雑で実装が凄く面倒臭かったので諦めた。
………
今回一番躓いたのはDNSSECの仕組み把握する事。関連技術が多い上、文献も多く中々大変だった。
とは言っても、正しく把握しないと運用出来ないのでJPRS資料を片っ端から読んでなんとかした。
資料にも書かれていない細かい仕様があったりするが、
運用する上で必要な情報はゲット出来たので結果オーライだと思う。
ソフトウェア面ではKnotを使うのが初めてだったが、
1週間程度弄っていたらチューニングのコツは大体わかった。
DNSSECの実装範囲はソフトウェア毎に違うので、結果として弄るのが最善・最短となった。
という事で、DNSSECオプションを有効にしてDNS名前解決したのがこちら。
実際はもっと長いレコードが返ってくるのだが、画像が横にデカくなってしまうので割愛。
サンプルでは個別にAAAAレコードも指定しているが、ちゃんとRRSIGレコードが付与されている。
………
本来はメイン利用の権威DNSにもDNSSECを導入したいのだが、、
サーバをマルチマスターかつansibleでゾーン管理をしているのでサーバの改修が必要となった。
また、DNSSEC運用を間違えたら名前解決が全滅するので、いきなり適用するのは見送った。
検証ドメインを購入して何でも出来る様に、メイン利用のドメインと別に用意した訳なので、
暫くはこのまま検証ドメインで運用を続け、軌道に乗ったらメイン利用のドメインに反映しようと思う。
形は置いといてDNSSECの導入は出来たので、当初の目的は達成出来たとしてヨシとしよう。
« 続きを隠す
