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アドレスが重複する可能性があるのは理解していたが、
リンクローカルアドレスが重複するパターンは想定外だった。
本気で調査するならソースコードを読めばいいが大変なのは今回はここまで。
システムを過去の知識ベースで弄ると問題になるケースがある良い教訓となった。
« 続きを隠す
2024年07月27日(土) - 22:12 | カテゴリ:
Network
筆者の自宅ラボでもOPNsenseを利用しており、暫くアップグレードをしていなかった。
この度、まとまった時間を取る事が出来たのでOPNsenseを全台アップグレードして、
執筆次点の最新バージョンとなる24.7.5に上げてみた
真っ先に思ったのは、アップグレード前後でダッシュボード構成が大きく変わる事。
今までのダッシュボードよりも、動的かつグラフィカルな構成に変わっていた。
OPNsenseの処理速度は特に変化無いので様子見中。
気になるのは、OPNsenseをHyper-V上で稼働させるとWebGUIのサービスがフリーズする事。
OPNsenseのshellに直接ログインしてサービス再起動すればアクセス出来るが、
毎回実行するのも面倒くさいのでなんとかして欲しい所。
環境依存な気もするが、余裕があったらログ調査して不具合を解消できないか見ようと思う。
2024年06月30日(日) - 00:00 | カテゴリ:
Network
筆者の管理する自宅ラボでもVyOSを多用しており、LTSソースコードをビルドして利用している。
久々にオートアップグレードの検証をすべく最新のLTSでビルドした所、
インストールイメージをmakeする処理でHTTP 403エラーが表示されてしまいビルドが停止した…
Reading package lists...
E: Failed to fetch http://dev.packages.vyos.net/repositories/equuleus/dists/equuleus/InRelease
403 Forbidden [IP: 104.X.X.X 443]
E: The repository 'http://dev.packages.vyos.net/repositories/equuleus equuleus InRelease'
is not signed.
P: Begin unmounting filesystems...
P: Saving caches...
Reading package lists...
Building dependency tree...
make: *** [Makefile:32: iso] Error 1
|
ビルドをdocker上で実行していたため環境固有の問題と考え修正を図ったが動かず、
仮想環境にDebianをインストールしてネイティブビルドも試したが同じエラーが出力された。
GitHubのReleases Tagsで公開されているソースを利用してもダメだった (´；ω；｀)
こんな時こそフォーラムに何か書かれている事が多いので翻訳片手に漁った所、
LTS Releaseへのアクセスを遮断したと投稿があった。
背景を読むと第三者がビルドした物をVyOS公式の物として公開した輩がおり、
警告をし続けていたけれど改善されなかったためソースコード自体へのアクセスを遮断した模様。
だが、推測ではあるが実際はコミュニティに貢献せず金銭利益を得ている者を締め出す口実ではと思う。
OSSはコミュニティ貢献と運営で成り立つので、貢献しない人を避けたいのは理解も出来るが、
締め出しまではやり過ぎな気がする。
とは言っても開発者としての言い分も納得出来るのと、
コミュニティ衰退や資金難による開発中止を避けたいのも頷けるので中々難しい話と感じた。
結構お世話になっているので、少額寄付する代わりにLTSが使える様になるなら払いたい位だが…
………
そうなると、正規の方法でLTS Releaseを取得する必要が出てくるのだが、
コントリビューターとして活動をすればLTS Releaseにアクセス出来る様になるらしい。
ガチのプログラムを書くのは出来ないが、スクリプト修正やドキュメント修正なら少し出来るので、
そっち方面でコミュニティ貢献するのもアリかと思った。
他には、自宅ラボでVyOSを常用しつつOSPF・BGPなどのルーティングも回しているので、
そのテスト結果を使った実用テスト面で貢献するのも良いかもしれない。
VyOS LTS Releaseにアクセスする術が完全に断たれた訳では無いのと、
コミュニティ貢献次第ではアクセス出来る可能性もあるのが救いがあるとも言える。
OSSコミュニティ運営も難しさと、今後の自宅ラボ方針も考え直す必要が出てきた出来事だった。
« 続きを隠す
