2020年06月10日(水) - 22:50 | カテゴリ:
Network
今までは、PPPoE+IPv4固定+NVR500の回線環境を使っていたが、最近は速度遅延が顕著になっていた。
特に4月末辺りから遅延が酷くなり、一番酷い時では1Mbps程度まで悪化していた。
また、10年前の機種となるNVR500ではスペック不足の場面も増えており、
TCPセッションを複数張るWebアプリを使い続けると、セッションテーブルを食い潰しそうになっていた。
NVR500が発売された2010年と現在を比較すると、Webアプリ台頭によって通信特性も大きく変化しており、
NATセッション数4,096・RAM搭載量64MBでは心許ないのが主な原因であり、
NVR500のサポートしているダイナミックルーティングプロトコルが少ないのも課題の一つだった。
今までは自宅サーバで公開Webサーバを動かしていた事もあり、品質重視のIPv4固定回線を使っていたが、
先日完了した自宅サーバ刷新によって、公開Webサーバも別拠点の仮想サーバに引っ越した上、
バックボーンにはメイン回線とは別のISPを使ったVPN型に変更したので、
通信品質重視の従来回線を使う必要性が下がっていた。
………
以前もIPoE引越しを検討した事があったのだが、検討当時はIPv4専有オプションが無かったので諦めていた。
しかし、世間から要望が多かったのかVNEでもIPv4アドレス専有オプションを提供開始した上、
JPNEのIPv4専有オプションを使ったサービスとして、
IPQ・OpenCircuit・interlinkがアドレス専有オプションをリリースしていた。
通信遅延・IPv4専有オプション・回線維持の必要性低下を総合的に考えると、
IPoE+IPv4専有オプションに移った方がメリットがある為、IPQ提供のIPoE+IPv4専有接続に変更しつつ、
ルータの処理速度を上げる為にも、メイン回線収容ルータをNVR500からRTX830に刷新してみた。
大まかなNW構成は下記の通り。メイン回線の収容ルータをYAMAHA RTX830に刷新しつつ、
コアルータ・端末用ゲートウェイは従来通りCisco 891Fを継続利用する構成にした。
ルータ間にCisco Catalyst 2960SなどL2SWが各種挟まっているが、
全リンクを1G以上でリンクアップさせており、速度低下が起きない様にしてある。
この状態で、CentOSインストーラを複数ダウンロードして負荷をかけると、
ルータのCPU負荷は下記の様になった。
| YAMAHA RTX830 |
Cisco 891F [コア] |
Cisco 891F [GW] |
 |
 |
 |
実測200Mbps程度とは言っても、平均CPU負荷が7～10%に納まっているのは驚いた。
RTX830と891Fを比較すると一目瞭然で、同容量を流しているのにCPU負荷が全然違う結果になった。
………
NW回線速度測地絵サイトを使ってみた結果は下記の通り。
JPNEがKDDI系ネットワークな事もありKDDI回線の方が有利なのだが、軒並み250Mbpsは出せた。
- [6/7 21:20～21:25] KDDI スピードチェック
- [6/7 21:25～21:35] Radish Network Speed Testing 東京
- [6/7 21:35～21:40] USEN インターネット回線スピードテスト
- [6/7 21:40～21:45] Google インターネット速度テスト
………
IPoEを1週間弱使っているが、今まで問題になっていた速度遅延が起きる事は無かった。
今回はIPv4専有オプションも付けており、インターネットからの接続も出来るので従来の様な自鯖公開も出来る上、
IPQの特典として逆引き登録も出来るので、むしろ今までよりも機能充実を測れた。
NTTがIPoE先行で10Gサービスを提供した事も考えると、今後はIPoE接続が主流になっていくのかも知れない。
速度速い・IPv6ネイティブ接続・輻輳POIバイパスと、良い事ずくめに思えるが、
IPoEを使うにはYAMAHAルータを弄れる位のネットワーク知識は必要なので、普及するのは当面先になると思う。
さらに、IPoE利用時のIPv4トンネル接続は、普通の場合アドレス共有型となるので、
ネトゲをやる様な人は通信要件を満たせないかも知れない。
この辺りは、NW機器メーカーと広報活動に頑張ってもらいたい所。
………
今回のメインプロバイダ変更にはそれなりの手間がかかった。
IPv6バイパストンネル(IP-IPトンネル)によって、通信速度遅延が改善した事もあり当面はこのまま維持する予定。
10年前のルータを使い続けると処理・機能不足が否めないので、筆者にとっては良いメイン回線刷新イベントとなった。
« 続きを隠す
2020年06月06日(土) - 19:41 | カテゴリ:
PC
弄り倒してないので、今回は購入報告のみ掲載ーーー
テレワーク増加によってWebカメラの品薄問題が出てきたりしているが、
筆者はノートPCに搭載しているWebカメラを使っているので騒動は回避できている。
そんな中、情報源として読んでいるINTERNET Watchを見ていたら、
ネットワークカメラとしつつも、ファーム書き換えでUSB接続Webカメラとしても使える、
ATOM Camについて特集が組まれていた。
普段ならスルーするのだが、クラウドファンディングから誕生した物で価格以上に多機能なのと、
実売2,500～3,000円とかなり安い事もあり、物は試しで買ってみた。
録画機能を試す為にSDカードも購入。安かったので16GBを購入。
内容物は、カメラ本体・取扱説明書・電源ケーブル・電源アダプタの4つ。
パッケージ自体も簡素化しており、プチプチの様な緩衝材は無く、代わりに段ボールで固定してあった。
ATOM CamはAndroid/iOSのアプリから設定を行うので、端末が別途必要になる。
アプリのUIはシンプル設計になっておりマニュアルを読まなくても何とかなる。
筆者の場合、実測5分程度でカメラと端末でペアリングが完了した。
HD画質で撮影している時のNWトラフィックは、100～200KB程度でWebカメラとしては軽め。
5GHz無線では動かないがIPv4/IPv6関係なく正常動作し、カメラをIPv4にした上でNAT64/DNS64でも接続出来た。
通信を見た限り、HTTPSでセッションを張れればピアリングできる模様。
解析途中なのでまだ詳細を書けないが、ファームウェアを改造して流し込めばSSHログインも出来そう。
ひとまず、kernel 3.10を使っている事と、U-Boot形式なのはわかった。
欠点といえば、アプリケーションで左右パンが出来ないのと、Webカメラ本体にAPIが無い事。
前者は物理機構が必要になるので低価格に抑える為に切り捨てるのは仕方ないと思うが、
APIは是非とも実装してもらいたい所。
そうすれば、自宅サーバと連携してAPIを叩く事が可能となり、ATOM Camのメリットがさらに上がると思う。
是非とも今後のファームウェア改良に期待したい。
« 続きを隠す
2020年06月05日(金) - 20:36 | カテゴリ:
Linux
旧環境ではBINDを用いてキャッシュDNSサーバを運用していた。
デファクトスタンダードとなっているBINDに慣れておかないと職にも影響が出る上、
仕様変更・脆弱性情報も追いかけるには、実際に運用するのが手っ取り早いという理由もある。
昨今ではBIND以外にもキャッシュDNSが増えた上、BIND以外を採用する環境も増えてきた。
技術提供側としてはニーズに対してスキルを出せないのは不勉強と言わざるを得ないので、
今回のサーバ刷新を機に一部サーバはBIND以外を採用してみた。
また、今後はDNSSEC採用環境が増えて行くと思われる為、
再帰問い合わせが可能なキャッシュDNSでDNSSEC検証も有効化してみた。
“ns-lab BB” のネットワークではプロトコル接続テスト用にIPv4/IPv6で完全分離しており、
IPv6からIPv4に接続する技術も確認する為、FortiGate50EでNAT64も動いている。
NAT64の為には、DNS64も動かす必要があるので、IPv6環境専用キャッシュDNSも稼働している。
そんな中、メインとなる仮想サーバ群は北海道の「さくらの専用サーバ」で稼働しており、
“ns-lab BB” のバックボーン用ドメインとレコードの管理もそちらで行っている。
流石にバックボーン情報を平文でインターネットに通す訳にもいかないので、
拠点間VPNでNW接続を行い、各拠点のキャッシュDNSから上位フォワードをする構成にしている。
BIND以外の環境では、BINDっぽい挙動を再現する為にdnsdistを前段に配置している
IPv6環境ではユニキャストアドレスをそのまま使えば良いので、
敢えて宅内ドメインを持たずにインターネットに直で名前解決を行っている。
前述の通りNAT64+DNS64用のBINDが稼働しているので、下記の様な設定をBINDに施し、
AAAAレコードが割り当てられていない場合でも、AAAAレコードを生成応答する様にしている。
acl "client" {
2001:db8:face:1000::/64;
2001:db8:face:2000::/64;
localhost;
};
acl "private" {
10.0.0.0/8;
172.16.0.0/12;
192.168.0.0/16;
};
view "internal" {
dns64-server "dns64.example.org.";
dns64-contact "postmaster.example.org.";
match-clients { client; };
match-destinations { client; };
dns64 64:ff9b::/96 {
clients { client; };
mapped { !private; any; };
exclude { 64:ff9b::/96; ::ffff:0000:0000/96; };
suffix ::;
recursive-only yes;
break-dnssec yes;
};
};
|
設定を詰めれば単純化する事も出来るが、再帰接続の許可セグメントを限定している為、
ACLを弄って厳密に制御している。
………
DNSサーバなので前段にロードバランサーを介さなくても冗長化が可能な上、
キャッシュDNSは構成が枯れてきている為、特有の複雑設定は実施していない。
なお、dnsdistを前段に置く事でロードバランス・クエリ分散など高度な事が可能となり、
実際に “ns-lab BB” のインターネット向けの権威DNSで採用している。
今回のDNS刷新で難易度の高かった箇所は、
DNSSEC検証を有効化しているキャッシュDNSでトラストアンカーを読み込む箇所。
手動更新・自動更新など色々試してみたが、設定を細かく作り込むと安定しなかったので、
BINDによる自動制御を最終的に採用する事にした。
刷新後の環境は稼働開始してから半年以上経過しているが、
DNSSEC検証含めキャッシュDNSとして問題無く稼働している。
エンタープライズ環境だと、権威DNSはRoute53などを使って外出しする事が出来るが、
キャッシュDNSは自前で持っていないとどうしようも無い事が多い。
そうなると、BINDなりのOSSを使うか、ADドメコンをキャッシュDNSに指定するか、
アプライアンスを入れる事が大半だと思う。
DoT/DoH等の次世代技術も存在するが新環境での導入は見送った。
というのも、同じサーバで監視用Webサーバも動いておりポート番号も被ってしまうのと、
下手にポート変更する位なら実装しないのも手と判断した。
DoT/DoHについては、dnsdistで実現出来そうなので必要性が出た時に試そうと思う。
« 続きを隠す
