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年08月08日(土) - 22:35 | カテゴリ:
Network
“ns-lab BB”の自宅サーバとリモートで動いているVPS・専用サーバを繋ぐ為、
VyOSを使って拠点間IPSecVPNを構築してNW通信が出来る様にしてある。
従来はVPN専用に固定IPプロバイダを契約してIPv4 IPSecVPNを張っていたのだが、
費用とVPN冗長化の課題が出てきたので何とかしようと考えていた。
そんな中『PPPoEで大量に振ってくるIPv6を使えば専用プロバイダいらないのでは!?』
と思い立ったので、IPv6 IPSecVPNへ移行する事にした。
………
そうなると、IPv6アドレスのみ付与したインターフェースでIPSecを張る必要が出てくるのだが、
VyOS v1.2.Xに設定を投入するとこんなエラーが出てきた。
# commit
[ vpn ipsec site-to-site peer 2001:ffff:ffff:ffff::1 tunnel 1 ]
VPN configuration error: IPv4 over IPv6 IPsec is not supported
Warning: Local address 2001:0:0:0::1 specified for peer "2001:ffff:ffff:ffff::1"
is not configured on any of the ipsec-interfaces and is not the
clustering address. IPsec must be re-started after address
has been configured.
|
VyOS公式でもバグ報告が上がっているのだが、優先度低になっており何時直るのか判らない状況。
コレが出来ないとIPv6環境に移行が出来ないのは勿論の事、修正を待って何もしないのもどうかと思ったので、
自力でVyOS内のIPSec設定スクリプトを直してみた。
………
修正箇所は次の通り。スクリプトがperlで書かれていたので読みやすかった。
どうやら、IPv6のみ付与したインターフェースでIPSecを設定しようとすると、
条件判定に引っかかってしまいエラーが出る様だった。
この問題は、VyOSのフォークとなるEdgeRouterでも発生するらしく、
先人の知恵も借りながら次の通りに修正してみた。
修正前:[/opt/vyatta/sbin/vpn-config.pl]
550 # Check remote/local and peer protocol consistency
551 # IPv6 over IPv6 scenario is actually supported by StrongS/WAN,
552 # we do not allow it in this version because of design and QA issues.
553 if (($conn_proto != 6) && ($leftsubnet_proto == 6)) {
554 vpn_die(["vpn", "ipsec", "site-to-site", "peer", $peer, "tunnel", $tunnel],
"$vpn_cfg_err IPv6 over IPv4 IPsec is not supported");
555 } elsif (($conn_proto == 6) && ($leftsubnet_proto != 6)) {
556 vpn_die(["vpn", "ipsec", "site-to-site", "peer", $peer, "tunnel", $tunnel],
"$vpn_cfg_err IPv4 over IPv6 IPsec is not supported");
557 }
|
修正後:[/opt/vyatta/sbin/vpn-config.pl]
550 # Check remote/local and peer protocol consistency
551 # IPv6 over IPv6 scenario is actually supported by StrongS/WAN,
552 # we do not allow it in this version because of design and QA issues.
553 if (($conn_proto != 6) && ($leftsubnet_proto != 0 and $leftsubnet_proto == 6)) {
554 vpn_die(["vpn", "ipsec", "site-to-site", "peer", $peer, "tunnel", $tunnel],
"$vpn_cfg_err IPv6 over IPv4 IPsec is not supported");
555 }
556 if (($conn_proto == 6) && ($leftsubnet_proto != 0 and $leftsubnet_proto != 6)) {
557 vpn_die(["vpn", "ipsec", "site-to-site", "peer", $peer, "tunnel", $tunnel],
"$vpn_cfg_err IPv4 over IPv6 IPsec is not supported");
558 }
|
554行目と557行目は幅の関係で改行しているが実際は1行で書く。
実際の修正箇所は553行目と556行目の判定処理。
この改修を入れると、IPv6 IPSec VPNも設定が通る様になった。
だが、VyOSのアップグレードをすると元に戻る筈なので注意が必要。
そのうち公式修正で直ると思うが、それまではこの改修でお茶を濁そうと思う。
記事を公開した後に、違う不具合も見つけたので修正&追記
自力修正によってIPv6 IPSecVPNの設定が入る様になったが、
IPSecのIKEステータスを表示するとIKE SAが成立しているにも関わらず”down”と表示された。
$ show vpn ike sa | no-more
Peer ID / IP Local ID / IP
------------ -------------
2001:ffff:ffff:ffff::1 2001:0:0:0::1
State IKEVer Encrypt Hash D-H Group NAT-T A-Time L-Time
----- ------ ------- ---- --------- ----- ------ ------
down IKEv2 aes256 sha1_96 2(MODP_1024) no -5640
|
色々とバグっているが、コレの原因は内部処理でハッシュキーが参照出来なくなっている為。
具体的には、VyOSのライブラリでIPv6アドレス判定を10進数でのみ評価しており、
16進数は例外処理に投げ込んでしまう為、コマンド実行時にアドレス不一致で値を取れなくなる。
解消する為には、ライブラリのIPv6判定をちゃんと16進数も評価する様に作れば直る。
ただし、RFC準拠で厳密に判定するとソレだけでライブラリになるので、今回は最低限に留める。
修正前:[/opt/vyatta/share/perl5/Vyatta/VPN/OPMode.pm]
32 sub conv_id {
33 my $peer = pop(@_);
34 if ( $peer =~ /\d+\.\d+\.\d+\.\d+/ ){
35 $peer = $peer;
36 } elsif ($peer =~ /\d+\:\d+\:\d+\:\d+\:\d+\:\d+\:\d+\:\d+/){
37 $peer = $peer;
38 } elsif ($peer =~ /\%any/){
39 $peer = "any";
40 } else {
41 $peer = "\@$peer";
42 }
43 return $peer;
44 }
|
修正後:[/opt/vyatta/share/perl5/Vyatta/VPN/OPMode.pm]
32 sub conv_id {
33 my $peer = pop(@_);
34 if ( $peer =~ /\d+\.\d+\.\d+\.\d+/ ){
35 $peer = $peer;
36 } elsif ($peer =~ /\d+\:\d+\:\d+\:\d+\:\d+\:\d+\:\d+\:\d+/){
37 $peer = $peer;
38 } elsif ($peer =~ /^(\:)?([0-9a-zA-Z]\:){0,8}(\:)?/){
39 $peer = $peer;
40 } elsif ($peer =~ /\%any/){
41 $peer = "any";
42 } else {
43 $peer = "\@$peer";
44 }
45 return $peer;
46 }
|
38~39行目を追加。適当だが、最低限動作するからヨシ!
何処かのタイミングで、修正のフォーラム投稿にチャレンジするのも良いかもしれない。
« 続きを隠す
2020年06月29日(月) - 22:48 | カテゴリ:
Network
独自ドメインを利用するには何でも良いから権威DNSが必要となるので、
普通の人ならばレジストラが提供している権威DNSを使っていると思う。
筆者の場合はスキル向上と世間のDNS動向を調査する為に自前で権威DNSを運用しており、
メインで利用している “ns-lab.org” 含め、関連する4ドメインで分速10~50クエリを捌いている。
DNSは昔から存在する事もあり基本的な考え方は枯れているが、
昨今は「DNS over TLS/HTTPS」セキュリティ強化を図ったり、
以前話題になった「NXNSAttack」の様に新しい攻撃手法が日々編み出されたりしている。
………
そんな中、古めの技術なのに日本で普及していない技術としてDNSSECが存在する。
DNSSECを使うにはレジストリにDSレコード登録が必要な上、ミスるとドメインが全滅する危険がある。
また、キャッシュDNSがDNSSECに対応していない事も多く普及していないのが現状となる。
筆者が所有している4ドメインもコレに漏れず、権威DNSはDNSSECに対応していない。
そもそも、利用しているレジストリがDSレコード申請に対応していない事もあるのだが、
KSK/ZSK運用のナレッジも無いので、対応をずっと見送っていた。
ちょっと前に自宅サーバ刷新が完了した事もあり、暫くの間は積みゲーで遊んだりしていたのだが、
そろそろ自鯖沼に戻りたくなってきたので、スキルを磨けそうなネタが何か無いか探していた。
今上がっている物としては、ESXi 7.0構築、eBGP/iBGPルーティングがあるのだが、
ずっと放置していたDNSSECに着手するのもアリだと思ったので本格的に検討してみた。
ただ、DNSSEC構築する上で問題となったのは、上位レジストリに依頼するDSレコード登録だった。
筆者が所有しているドメインはgTLDドメインなのだが、
大多数のレジストラがgTLDドメインのDSレコード登録申請に対応しておらず、
対応レジストラを探し出しても、企業が使う代物でお値段的に個人利用お断りだった。
そんな中でもJPRS管理の “JP” ドメインはDSレコード登録申請に対応しているレジストラが数件あった。
ならば、今回を機にJPドメインを取得するのも良かろうと思い、ドメイン取得に向けて情報収集を開始した。
頭を捻りながら新規取得のドメイン名を考えつつ、JPドメインオークションも徘徊確認していた所、
まんま「技術検証」に打って付けなドメインが出品されていた。
『これは何かの縁だ。買わねば!』と思い、初のドメインオークションに参加して無事ドメインを落札。
という事で、昨今のIT屋だったら何処かで聞いた事がある3文字をJPドメインで取得出来た。
whois代行を使っているので、オークション時のレジストラ情報が公開されている。
………
今回はオークション初参加だったので、普段から利用しているバリュードメイン経由で参加してみた。
無事落札出来たので筆者の名義で管理者登録が行われた上、whois代行で公開情報を上書きしている。
ただ、バリュードメインはDSレコード登録申請に対応していないので、
他社にレジストラトランスファーを行う必要が出てきた。
JPRS公開のDNSSEC対応レジストラを確認しつつ個人利用出来そうな所を探した所、
「お名前.com」「ゴンベエドメイン」なら個人利用でもDNSSECに対応している事が判明。
両レジストラのサポートにも聞いた所、ゴンベエドメインならDSレコード登録申請に対応している事が判明。
お名前.comもDNSSEC自体には対応していたのだが、レジストラ所有の権威DNS利用が必須条件となり、
今回の要件となる『自前で構築』を満たせなかったので選択肢から無くなった。
DNSSECの運用は難易度が高い上、運用を失敗するとドメインの名前解決が全滅する危険が付き纏う。
その上、キャッシュDNSがDNSSECに対応していない事が多く、恩恵を受けるシーンが少ないのが現状となる。
業務利用なら専用サービスを用いる事が出来る上、今ならDNSSEC対応を謳ったサービスも出てきている。
そうは言っても、基礎知識をもった上でサービスを利用するのと、知らないで利用するのは雲泥の差なので、
今回を機にDNSSEC運用スキルを身につけようと思う。
« 続きを隠す