2018年11月17日(土) - 21:45 | カテゴリ:
Network
ns-lab BBのバックボーンNWを支えるコアルータはCisco1812Jを使っていた。
外回線が100Mbpsだったりルータを階層化している事から、
Cisco1812Jでも問題無かったのだが、回線増強も予定しているのでコアルータも刷新した。
当初、RTX1210・IX2215・ISR891でどれにするか迷ったのだが、
某所でCisco892FSPを発見し、予定を変更してこちらを採用する事にした。
上段が今回購入した892FSP、下段が従来から使っているゲートウェイ用の891FJ
ns-lab BBはISPを2契約している都合上、ルーティング制御にPBRとtracking制御を多用している。
この制御を行っているのがコアルータなので、PBR・trackingを使えないと話にならなかった。
また、サブインターフェースでIPv4/v6への接続を行っているのでGigabitI/Fにしたかった。
普通の891FJだとFastEtherになるのだが、891FSPはGigabitEtherを2本備えているので、
今回の自宅NW要件にも合致したのでIYHした。
………
試しに100Mbpsを流し込んでみたが、色々と制御を盛り込んでいる中でCPU負荷は8%程。
ルータのポテンシャルとしては1Gbpsまでは行ける筈なので、
CPU負荷の計算上も問題無く1Gbpsを出せると思われる。
また、IPv4/v6網を分ける為にVRFでルーティングテーブルを分割した上でOSPF/BGPも喋らす事にしたのだが、
Cisco1812Jでは出来なかった、OSPFv3 VRF-Liteも出来るようになった。
片足を突っ込んでいる身としては、やはりコアルータはCisco・Juniperで組みたい所。
久々のNW弄りで徹夜した日も出たが、ルーティング最適化とかtrackingポリシーの変更も行えて楽しかった。
2018年11月10日(土) - 11:06 | カテゴリ:
Linux
権威DNSサーバのアプリケーションと言えばBINDが有名だが、
世の中にはOSS・商用問わず色んな物が存在する。
筆者の場合、自宅サーバのDNSは権威・キャッシュ問わず(GSLB以外)BINDで構築している。
ただ、BINDのみで構築している場合、脆弱性を突かれるとパケット一発で落とされたり、
ゾーン管理が基本的にテキストなので、汎用性の面で難があったりする。
そんな事もあり、色々と情報収集していたらPowerDNSと外部管理ツールを組み合わせると、
それっぽい物を作れる事が判ったので、自鯖で構築してみた。
構築手順は何時も通りのwikiに纏めたのでそちらを参照。
ちなみに、今回は権威DNSサーバ(PowerDNS Authoritative Server)のみ構築してみた。
構成としてはこんな感じにしてみた。
ポイントとしては、ゾーン管理をPowerDNS+PDNS Managerに任せておき、
実際のユーザクエリに応答するフロントエンドは従来のBINDを利用してみた。
本来なら一番危険なのがフロントエンドなので、この箇所をNSD・Knot DNS辺りにしておくのがベスト。
ただし、今回はPowerDNSとGUIツールの使用感をテストしたかったので、
フロントエンドは手抜きして使い慣れたBINDにしてみた。
構成図はシンプル。ゾーン転送でBIND(slave)にデータを送る。
アプリケーションは違うだろうが、同様の構成は『Hidden Primary』として商用でもやる事が多い。
………
PowerDNSのGUIツールは色々な物をテストしてみたが、最終的にPDNS Managerに落ち着いた。
PDNS Managerは実装がシンプルなのと、PHP+JSで作られているので既存のWEBサーバと親和性が高く、
1台のサーバに色々詰め込んでいる自鯖用途に合致した。
当初、PowerDNS-Adminを使おうと思っていたのだが、
PIPの構築やらPython依存関係の解消など色々と面倒な中、
TCP:443でアクセスさせるには、リバースプロキシを噛ませる必要も出てきたので諦めた。
ただ、PowerDNS-Adminは機能が豊富で、ユーザ認証をAD連携(LDAP)する事も出来るらしいので、
エンタープライズで利用するなら、このツールが筆頭候補になると思う。
PDNS Managerの良い所は、余分な機能が無いので直感的にゾーン情報を弄れる。
その割に、ユーザ認証はローカルDBでちゃんと出来たり、
レコードタイプにALIAS等のニッチな物が揃っているので、十分な機能を持っている。
レコードで使うとしても、大多数は『A / AAAA / NS / MX / CNAME / TXT』辺りだと思うのと、
そこまで細かい制御やるなら、GUIよりもゾーン情報を直書きした方が意図した設定になると思う。
………
使ってみた感じだと、PDNS Managerは動作が軽く、ゾーン転送にも影響は無かった。
簡単にPowerDNSを使ってみたい場合には、良い選択肢になりそうだった。
そんな中でも気になったのは、レコードを編集する度にゾーン情報のシリアルが上がる為、
利用者が多い環境ではシリアルの『YYYYMMDD』と実際の日付が合わなくなりそうだった。
ただ、シリアル自体は数が相当数確保されているので、シリアルを気にしないなら問題無さそう。
そもそも、GUIを使う様な環境ではシリアル管理もGUI任せの方が良いので、希有な心配かもしれない。
…まぁ、シリアルを戻す事はDBを直接弄れば出来そうだったが (｀・ω・´)
“ns-lab BB”のインターネット向けDNSサーバは従来通りの構成を取っているが、
色々とテストして、本番利用が出来そうならばこちらの権威DNSも載せ替えようと思う。
« 続きを隠す
2018年11月03日(土) - 19:00 | カテゴリ:
Linux
通信先管理とWiFi環境からのWeb通信ログを取る為に、
ns-labではProxyを構築してあったりする。
Proxyには皆さんご存じのSquidを利用しているのだが、
アップグレードが面倒でstableのv3.5を使い続けていた。
ただ、先日辺りからv4.0系もstableになったと話を聞いたので、
10月末にSquid v4.3にアップグレードをしてみた。
ちなみに、11/03現在の最新バージョンはv4.4だったりするが未テストなので割愛(´・ω・｀)
パッケージで入れるとバージョンが低いので、ソースコードを独自ビルド。
オプションは、ほぼv3.5の物を使い回す事が出来た。
Proxyネタと言えば、DigiLoogでも過去に何回か取り扱っていたりする。
直近でSquid v4.0系に関係ありそうなのが下の通り。まずはコレらが解消しているか確認してみた。
結論としては、両方とも解消していたヽ(´ー｀)ノ
Squid自体のパラメータ変更は、アップグレードによるエラー回避以外はやっていないので、
単にSquidの処理が最適化されたのかもしれない。
Squid v4.0系はまだ枯れていない所がありそうだが、大体の機能については完成した感があった。
まだまだProxyは必要になると思うので、時間を見つけて実動作テストを続けていこうと思う。
« 続きを隠す
