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月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の導入は出来たので、当初の目的は達成出来たとしてヨシとしよう。
« 続きを隠す
2020年10月24日(土) - 22:19 | カテゴリ:
Linux
DNSサーバと言えばBINDを思い浮かべる人が多いと思うが、
パケット1発で落ちるBINDコロリと呼ばれる様な脆弱性が出てきたりして、
昨今は脱BINDが囁かれる様になった。
そうは言っても、デファクトスタンダードとなっているBINDじゃないと出来ない事があったり、
権威DNS・キャッシュDNSを兼用させて、リソースをケチるにはBIND以外の選択肢が無かった。
筆者も例に漏れず業務含めメイン用途ではBINDを使い続けていたが、
ひょんな事からBIND以外の権威DNSサーバを運用する必要性が出てきたので情報収集を開始。
『コレは自鯖基盤の権威DNSにNSDを追加して運用チャンス (｀・ω・´)』
という事で、dnsdistを使う事でBIND・NSD間のフォールバックも実装しつつ、
権威DNSにBIND・NSDを併用した環境を構築してみた。
NSDのビルド方法などはコチラ
“ns-lab BB”のインターネット向け権威DNSは、gdnsdを使ってグローバルロードバランサも兼任している。
また、DNSクエリログを解析する事でFW自動遮断をしているので、クエリログ取得も必須要件となる。
この課題を解決する為に、フロントエンドにdnsdistを使ってクエリログを取得しつつ、
グローバルロードバランサ用のサブドメインクエリのみgdnsdに曲げる設計となっている。
NSDはソースを改造しないとDNSクエリログを取得出来ないのだが、
同様にクエリログを取れない、gdnsd・dnsdist構成を作ってあったので問題を解決出来そうだった。
という事で、今回の権威DNS構成変更によって最終的に上の構成になった。
“ns-lab BB”のインターネット向け権威DNSは、
IPv4/IPv6でデュアルスタックにしつつ合計4台で負荷分散をしているのだが、
内部では2台1セットで運用しており、セット毎に稼働OSとkernelチューニングを変えている。
今回は2台1セットを維持しつつ、1セット内でBINDメインとNSDメインを用意した。
さらにバックエンドにNSDとBINDをバックアップとして構えておき、dnsdistで転送先を切り替えられる様にした。
この構成にする事で、BINDやNSDが脆弱性で落ちたとしても1～3秒程度で互いのバックアップに切り替わり、
権威DNS停止から来る名前解決待ちや正常系への再問い合わせ遅延が発生しにくくなった。
また、フォールバックする様にしておく事により、サーバメンテナンス時に正常系のバックエンドに切り替え、
サービス停止無しでメンテナンスを行える様になった。
………
独自ドメインを持っている大半の人は、レジストラや代理店が用意している権威DNSを使うと思う。
というのも、権威DNSが落ちるとサービスに繋がらなくなる上、メンテナンスと脆弱性対応が面倒なので、
自鯖を趣味としている人でも、権威DNSを自前運用してインターネット公開している人は少ない筈。
企業レベルでドメインを運用するなら、IaaS付属の権威DNSや権威DNS専用サービスを別途契約してしまい、
自前運用している所は相当減ってきている様に感じる。
さらに、権威DNSサーバの脱自前運用も叫ばれ「餅は餅屋」ならぬ「ドメインは権威DNS屋」も浸透してきた。
だとしても、ローカルなど閉じた環境では自前運用が必須となる上、相応の経験が必要となるのが事実。
先の通り、DNSが止まるとサービスが全滅する事もあり、可用性確保に躍起している運用担当も多いと思う。
だからこそ、何でも出来る自鯖で今回の様なトリッキー構成を試してみるのは今後も必要になるだろう。
« 続きを隠す
