2024年10月10日(木) - 23:08 | カテゴリ:
Linux
先日、自宅鯖のDNSクエリログを眺めていたところ、
Zabbix 7.0から発せられるDNSクエリが大量に出ていたり、大小英数字でランダム化されている事に気づいた。
DNSキャッシュサーバの負荷高騰までは行っていないが結構な量だったので原因調査をしてみた。
………
改めてログ解析すると元はZabbix Proxy 7.0だった。
以前のバージョンでは秒間50~100クエリ程度と控え目なのだが、
Zabbix 7.0にアップグレードした直後から秒間200~300クエリに増加しており、
さらに今までは無かったAAAAレコードのDNS名前解決も増加している事が分かった。
そんなでログ解析しながらコミュニティを漁っていたら、時期もバージョンもズバリ合致する記事が見つかった。
This looks like being a feature of libevent that Zabbix 7.0 uses for async DNS resolution. |
どうやら、Zabbix 7.0の非同期DNS名前解決で利用しているlibeventライブラリの機能らしく、
プログラムの組み方次第ではAAAAレコードも無作為に名前解決してNXDOMAINになり、
NXDOMAINをキャッシュせずに改めて名前解決を行う無限ループになる様だった。
………
さらに、DNSクエリがDNS-0x20で大小英数字にランダマイズされる事により、
より一層キャッシュに乗りにくくなっていた。
DNS-0x20の仕組みはカミンスキー攻撃などDNSキャッシュポイズニングを防止する目的で有用だが、
環境によっては凶悪なDDoS状態になり得ると実感した。
筆者の環境ではDNSキャッシュサーバのクエリログ解析をしているので、
DNS-0x20を施されると困る場合もあるのだが、仕様らしく解除するにはプログラムを書き換えるしか無さそう。
コミュニティにみお解決困難と書かれてあり、ワークアラウンドもDNSキャッシュを使う方法のみだった。
自宅のDNSキャッシュサーバは元からスペックを積んでいるので余裕で耐えられるクエリ数ではあるが、
エンタープライズなど大規模環境でコレが発生すると、凄い負荷がかかる筈なのでぞっとする。
特にISPやサーバ事業者とかは死活問題な気がする (´・ω・`)
以前に仕様と分かっているならサーバ増強で対処も出来るが、バグの分類にも感じるので解決は難しそう。
メジャーバージョンアップなので何かあると思っていたが、予期しない所から刺客が来た形となった。
2024年08月31日(土) - 21:30 | カテゴリ:
Linux
過去の名残で利用しているRJ45のSFPモジュールがあるのだが、
EtherChannelの片系トラフィックが0bpsのままになっている事に気づいた。
SFPモジュール故障と判断して在庫のモジュールとも交換した所、
交換した直後に別のSFPモジュールも応答しなくなり自宅で二重障害に派生した。


今回故障したSFPモジュールの片割れがこちら。筆者の元で5年は動作してくれた。
物理ポートが余っているので、そちらに差し変えるのも一つの手だが、
SFPモジュールが故障した時の挙動含め自宅で検証しているので今後も続投予定。
だが、在庫が無くなってしまったので次のモジュールを購入する必要が出てきた。
今回を機に高耐久モデルを導入したいが値段が高いので尻込み中。
最終的には同系統の耐熱モデルになりそうだが、届いたらモジュールを入れ替えたい所。
最近、周囲のIT機材が物理的に故障し続けているので諸々の寿命が来ているのかもしれない。
物理装置は在庫を一応は確保しているが、そろそろ次期バックボーンを考えていく必要があるかも。
2024年08月25日(日) - 12:46 | カテゴリ:
Linux
サーバ検証用にProxmox基盤を運用しており、
一度構築したサーバでスナップショット取得しつつクローンで使いまわす事が多い筆者。
クローン時にMACアドレスやIPアドレスなど固有パラメータが被らない様に気を付けているが、
自動生成するIPv6リンクローカルアドレスが被っているケースが先日起きた。
そもそも、リンクローカルアドレスが被る事は無いだろうと高を括っていたのだが、
messagesログに”advertised our address fe80::X on eth0!”と出力されていて偶然気づいた。
MACアドレスは違うし、EUI-64で被る事も無いと考えていた中での重複だったので少し調査してみた。
今回の事象が発生した環境はRockyLinux 8.10で稼働しており、
IPアドレスなどネットワーク周りはNetwork Managerで一元管理していた。
何か設定が重複していると考えてnmcliとdiffを駆使して差分を確認した所、
NICのUUIDが重複している事を発見。
リンクローカルアドレスが被った環境でUUID変更とnmcli down; nmcli upしてみたら、
NICに付与されたリンクローカルアドレスも更新される事を確認出来た。
………
RockyLinux 8.10のNetwork Managerでは、
“/etc/sysconfig/networks-scripts/ifcfg-eth0″のUUIDパラメータを見ている様な動きをしており、
このパラメータをわざと重複させた際の挙動がどうなるのか気になったのでテストしてみる事に。
だが、RockyLinux 8.10のテスト環境が無かったので、ディストリビューションが違うがRHEL 9.4で実施。
RHEL 9.4で生成するNetwork Managerの設定は、
“/etc/NetworkManager/system-connections/enp6s0.nmconnection”なのでUUIDを変更した所、
MACアドレスは違うがUUIDを同一にしてみても、リンクローカルアドレスも一意なままだった。

左:検証サーバの元環境
右:サーバをクローンした後、MACアドレスとUUID変更をした環境
………
アドレスが被った環境からの予想では、UUIDが同一ならリンクローカルアドレスも同一になり、
MACアドレスの差異は影響しないと考えていたが、普通にリンクローカルアドレスも変わった。
事象の発生した環境とテスト環境が違うので参考情報になってしまうが、
RHEL 9.4ならUUIDに依存せずリンクローカルアドレスが生成されている様に見える。
スクリーンショットを取り忘れたが、UUID変更前後でもリンクローカルアドレスは変化しなかったので、
MACアドレスなどUUID以外のパラメータを見ている可能性も高そうに見える。。
仮想サーバをクローンした際にEUI-64割り当てのIPv6アドレスが重複する可能性があるのは理解していたが、
リンクローカルアドレスが重複するパターンは想定外だった。
本気で調査するならソースコードを読めばいいが大変なのは今回はここまで。
システムを過去の知識ベースで弄ると問題になるケースがある良い教訓となった。
« 続きを隠す