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コミュニティ運営も難しさと、今後の自宅ラボ方針も考え直す必要が出てきた出来事だった。
« 続きを隠す
2024年05月18日(土) - 14:17 | カテゴリ:
Network
自宅ラボのRTX830を利用したNGN-VPNは数年前に構築して絶賛稼働中だが、
ひょんな事からルーティングポリシーの最適化を施したので改めて転送速度を測ってみた。
最適化したのは、自宅コアルータのルーティングテーブルと通信ポリシーの二つ。
CIFS自体の通信経路は変更して無いが他の通信をバランシングさせる事で、
インターネット回線毎のトラフィックをコントロールし直した。
制御内容も載せようと思ったが、文量が多くなりそうだったのと時間都合で割愛 (´・ω・｀)
CIFS転送速度を見ると初期設計した時と遜色無い速度を維持できた。
当初の状態からトラフィックは右肩上がりで増え続けていた事から速度低下を懸念してたが、
最終的に維持出来ているのでキャパシティは大丈夫そうだった。
サーバ類が稼働しているデータセンターとの接続は、
IPSec VPNの中でBGPを用いたEGPルーティングで制御しているが、
NGN-VPN内はIGPを用いる設計にしているため、BGPでの制御をしていない。
そこで、今回はOSPFとStaticRoute+IP SLAで動的制御を施し直した。
上手く通信を転送出来ているので暫くは修正版ポリシーで様子見しようと思う。
2024年05月11日(土) - 17:43 | カテゴリ:
Network
それは、唐突に起きたーーー
YouTubeを見るのすら辛い位の通信遅延が増えており、
インターネット回線かプロバイダーの何方かが混雑していると思っていた。
だが、確実に回線が空いているであろう深夜でも発生する様になったのと、
pingすら遅延している事が分かったので流石に調べる事にした。
すると、パケロスはしないがpingが100～150msまで落ち込んでおり、
「いつのアナログ回線だよ」と思う位の遅さで使うに堪えれらなくなっていた。
その真相を探るべく、筆者はネットワークの奥地へと向かった。
結果、ファイアウォールとNAT64/DNS64を兼ねているFortigate 50Eで遅延している事がわかり、
初期化などをしても解消しなかったので代替品を調達してきた。
自宅ラボで様々なネットワーク機器を使ってきたが、
明確にぶっ壊れたのはJuniper SRX100と、今回のFortigate 50Eの二つくらい。
今回は本職でも中々見ない故障内容だったので原因を特定するのに時間がかかった。
今回の環境を図にすると大体こんな感じになっており、
FortigateはVDOMで分割しPCのデフォルトゲートウェイとして動く物と、
NAT64のアドレス変換を行うVDOMの2つを同時稼働させている。
壊れていたのはFortigateで、通信を3秒程度流すとレイテンシやジッターが劣化する状況だった。
本職で起きたら面倒くさい事この上ない故障状況だが、
再現性があったので通信テストをしやすかったのが功を奏した。
………
スペックには満足しているのと直近で構成変更の予定も無かったので同機種で入替を実施。
交換後に正常動作出来る事を確認した後、通信テストもしてみたがやはり故障した方は劣化していた。
故障した設備
入れ替えた設備
速度計測は各時間帯に3回ずつ実行したが、計測時は構成が少し違うのでIPv4の速度は参考情報になる。
インターネットの接続点を100Mbpsに落としているため理論上でも100Mbpsが上限となっている。
100Mbps上限が入っている上で故障機器ではIPv6宛が10Mbpsしか出ない上、
ジッターも異常にブレが大きい状況だった。
対して、機器交換をした後は100Mbpsを安定して出しつつジッターも落ち着いた値となっている。
機器交換してから3日経過し、その間に計100GBは通信しているが安定して稼働しいる。
機種は変更していないのでSNMP監視も修正無しで使う事が出来ており文字通り元に戻った。
速度も申し分なく出ているので、暫くの間はFortigate 50Eをゲートウェイ設備として継続する予定。
何はともあれ、久々の自宅ラボ障害で大変ではあったが楽しい時間だった。
« 続きを隠す
