2018年11月25日(日) - 19:15 | カテゴリ:
Network
DHCPサーバの冗長化には色々な構築レシピが存在するが、
フェールオーバー機能で割り当てアドレスを同期しつつ、
プライマリが倒れたらセカンダリでDHCP機能を引き継ぐ構成が、経験上楽に冗長化を行えた。
ただ、IPv6で利用するDHCPサーバ(便宜上、DHCPv6と表記)は、
最近になってフェールオーバープロトコルが整備された為、
2018年11月現在・開発終了しているISC DHCPには機能が実装されていない。
現在開発中のKEA DHCPでもバックエンドにDBを用いた冗長化機能はあるのだが、
リースファイルを使う様な簡易な冗長化は出来ないのがネックだったりする。
………
話は変わり、筆者自宅のIPv6クライアントアクセス網は、
お金をケチる為にラズパイを用いたRA配布・DHCPv6サーバで構築してあるのだが、
このラズパイを最近になって2台に増やした為、DHCPv6サーバ冗長化問題が発生した。
当初、KEA DHCPで組み直す事を考えていたが、バックエンドにDB利用が前提となるのでやめた。
というのも、ラズパイの補助記憶装置(ストレージ)はSDカードとなる為、
DBみたいに読み書きが大量発生する用途には向かず、過去筆者も似たような事をやって壊した事があった。
という事で何か手が無いか色々と考えつつ、RFC・ドキュメント・ソースを漁っていた所、
EUI-64でインターフェースIDを配布する事で、
アドレス衝突無く任意のIPv6アドレスを使える事に気付いたのでやってみた。
※ 細かい事は、毎度のwikiに纏めたのでそちらをご確認ください
………
そもそもの話、IPv6アドレスの配布はRA(RouterAdvertisement)を使うのが大半だが、
中にはRA配布に対応せず、DHCPv6によるアドレス配布のみ対応した困ったOSがあったり、
ND-RDNSSに対応せず、こちらもDHCPv6によるDNS配布のみ対応したWindows7というOSが存在する。
これらのOS全てに対応するには、RAとDHCPv6のフル対応が必須となってしまい、
上記の様に自前でルータもどきを構築する必要が出てきてしまう。
ちなみに、昨今ではNECルータがND-RDNSSに対応したらしいが、
筆者は対応している物を所持していないので未テスト状態。そのうちテストせねば (｀・ω・´)
………
上記の理由から、IPv6網(クライアントセグメント)でラズパイルータを自作して使っているのだが、
OSのセキュリティアップデートもそれなりの頻度でやっている都合上、
シングル構成ではラズパイ再起動時にNW停止が発生していたので、冗長化してみようと画策した。
RAを使っているならDHCPv6をIPv6アドレス配布に普通は使わないとしても、
上記の通り、DHCPv6でのアドレス配布にのみ対応している物がある為、出来る限り冗長化しておきたかった。
そんな事を思いつつ情報収集した結果、DHCPv6サーバを冗長化するには下記の手段がある事が判ってきた。
- DHCPv6で配布するアドレスレンジを細かくした、
DHCPv6サーバを複数構築する構成
- バックエンドにDBを利用しつつ、
フロントエンドをクラスタ化
- EUI-64でアドレス衝突を理論上排除しつつ、
フロントエンドをスタンドアロンで複数構築
当初はパターン1で構築していたのだが『それだったら普通のIPv4環境でも出来る』ので、
『ネタとして面白く無かろう』と方向性を何処かで間違えた結果、
IPv6だからこそ出来るパターン3(EUI-64)方式での冗長化にチャレンジしてみた。
結論だが、ISC DHCPでもIPv6アドレスの配布をEUI-64ルールで行う事が出来た。
やろうとしている事は皆同じらしくISCのメーリングリストを読んだり、
ドキュメントを読んでいたら似たような事が書いてあった。
ただ、設定を有効にするにはソースコード中のヘッダーを編集してソースリビルドが必須であった。
挙動面では稀(100再起動して1回程度)にアドレスプール内なのにアドレス払い出しが出来なかったり、
リンクローカルアドレスで払いだそうとしたりイマイチな挙動が出たりしたので、
エンタープライズで使うなら調整が必要に感じた。
ただ、前途の通りエンタープライズ用途ならKEA DHCPを使うべきだし、
Infoblox辺りならアプライアンス側で冗長化に対応しているので、
ISC DHCPを今更使う様とは稀だと思う。
だが、ラズパイみたいな非力サーバでもソフトウェア次第では十分使える物を作れるのが判った。
通信速度は頑張って10～30Mbps程度だが、そこまで速度を求める使い方をしていないので、
DHCPv6・RA辺りの仕様が枯れるか、興味のそそられる新しいNW機器が出るまで使ってみようと思う。
« 続きを隠す
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も載せ替えようと思う。
« 続きを隠す
