..たれろぐ..

SoftEther on Ubuntu 24 on ProxmoxVE 8.2 の VPN 通信が不安定な場合の一対策

tips ProxmoxVE Linux
まとめ

SoftEther を動かしている Ubuntu の NIC の segmentation offload が悪さをしている可能性があるので segmentation offload を無効化してみよう。

環境
  • SoftEther 4.43beta
  • Ubuntu 24.04 LTS VM の NIC 2本はそれぞれ Intel E1000 を指定。 ens19 がローカルブリッジ用 NIC。
  • ProxmoxVE 8.2.2
不具合

L2TP/IPSec で VPN 接続した端末で、VPN 側から端末側に大きなデータ(ファイル)をコピーしようとすると速度が出ない(数KB/s) & 失敗する。(SoftEther ネイティブ接続は未検証なので、ネイティブ接続だと影響がない可能性あり)
MTU 周りを疑い、仮想 HUB の拡張オプション AdjustTcpMssValue を下げたりしてみたが効果なし。
Proxmox ホスト側の NIC offload の無効化も効果なし。

対策

VM のローカルブリッジ用 NIC の offloading 具合を確認すると以下の通りで TSO, GSO, GRO が有効になっているのが分かる。

$ sudo ethtool -k ens19 | grep -v fixed
(snip)
tcp-segmentation-offload: on
        tx-tcp-segmentation: on
        tx-tcp-mangleid-segmentation: on
generic-segmentation-offload: on
generic-receive-offload: on

これらの offloading が悪さをしている場合があるとのことなので、NIC offloading を無効化する。

$ sudo ethtool -K ens19 tso off gso off gro off
$ sudo ethtool -k ens19 | grep -v fixed
(snip)
tcp-segmentation-offload: off
        tx-tcp-segmentation: off
        tx-tcp-mangleid-segmentation: off
generic-segmentation-offload: off
generic-receive-offload: off

この状態でテストしたところ、ファイルのコピーの不安定さがなくなったので永続化設定をする。
netplan 環境なので永続化設定は次トピの通り。
Ubuntu netplan で NIC offloading を無効にする設定の書き方 - ..たれろぐ..


参考
  • NIC offload の無効化の示唆

forum.softether.org

  • ProxmoxVE 上で SoftEther サーバを立てるときの注意点(仮想NICの種別)

zenn.dev

ac-as.net

  • 仮想 NIC での offload の挙動について

zenn.dev

Ubuntu netplan で NIC offloading を無効にする設定の書き方

tips Linux

色々悪さをする場合のある NIC offloading をUbuntu netplan 環境で無効にする設定の書き方。


例えば TSO (TCP Segmentation Offload), GSO (Generic Segmentation Offload), GRO (Generic Receive Offload) を無効にする場合、テンポラリには ethtool で以下のようにやるかと思います。

$ sudo ethtool -K ens19 tso off gso off gro off


これを恒常的に(再起動時に効かせる)するには /etc/netplan/ 以下にある Netplan の設定ファイル、例えば /etc/netplan/50-cloud-init.yaml の ethernets 以下に次のように項目を追加し、それぞれ false にしてやります。

network:
    ethernets:
        ens19:
            tcp-segmentation-offload: false
            tcp6-segmentation-offload: false
            generic-segmentation-offload: false
            generic-receive-offload: false

設定の反映は以下コマンドを使うか再起動にて。

$ sudo netplan apply


その他の offloading 項目については以下の Netplan ドキュメントを参照してください。 (offload でページ内検索すると設定可能な項目が見つかります)
netplan.readthedocs.io


ubuntu netplan nic offload off でググっても適当なページが見つけられなかったのでメモ。

参考

NIC offloading の解説
ac-as.net

VyOS 1.4 で DNS blocking をやってみる

VyOS tips

VyOS 1.1.7 から 1.4 に移行して、DNS 周りが dnsmasq -> PowerDNS に切り替わった影響で、こちらにあるように追加 hosts ファイルにブロックしたいホストを並べてブロックする手が使えなくなりました。

別の手を探したところ、公式フォーラムの以下のポストがありました。
forum.vyos.io

DNS 解決時に lua スクリプトで hook することで同じような DNS blocking ができるとのことです。


公式フォーラムにある方法の通り3つのスクリプトファイル、pdns-adblock-script.lua, pdns-adblock-blocklist.lua, adblock を置いてやればほぼいけるのですが、VyOS 1.4-epa2 では PowerDNS 設定ファイル recursor.conf のディレクトリが異なっていますので /config/scripts/commit/post-hooks.d/adblock スクリプトに修正が必要です。

adblock スクリプトで、

echo "lua-dns-script=/config/scripts/pdns-adblock-script.lua" | sudo tee -a /run/powerdns/recursor.conf

となっている後半の sudo 部のパスを以下のように修正してやっててください。

echo "lua-dns-script=/config/scripts/pdns-adblock-script.lua" | sudo tee -a /run/pdns-recursor/recursor.conf


また、block したいホストは pdns-adblock-blocklist.lua に配列の形で書き並べるので、お好みで変更しましょう。
自分はこちらの 広告除去用ホストファイル を元に置換したり手修正いれたりして作成しました。

最後に設定モードで commit すると adblock スクリプトが実行され、 block 動作が有効になります(commit する変更がない場合は adblock スクリプトを直接実行しても OK です)。

これで block 対象のドメインの DNS 参照が走った際にはドメイン不在扱いになり、無事 block できるようになります。


一点運用上の注意点があって、adblock スクリプトの記述を見れば分かるように、設定を commit するたびに /run/pdns-recursor/recursor.conf の末尾に lua-dns-script=/config/scripts/pdns-adblock-script.lua が追記されていきます。
ファイル容量が増えていくだけで動作上の問題は無いのですが、時々掃除した方がいいかもしれません。


それではよい VyOS ライフを。

参考

ProxmoxVE VLAN 1 を tagged で VM まで流すには

ProxmoxVE tips

ProxmoxVE 8.1 にて VLAN1(VID1) を tagged で VM に渡すには、Linux bridge ではなく OVS bridge を使う必要があります。

ProxmoxVE デフォルトの Linux bridge では、 VLAN1 はデフォルト VLAN 扱いになり、自動的に untag されてしまうので、 VM 側に tagged で渡すことができません。

参考
使ってる機材

続々・VyOS 1.4 と PPPoE と MSS clamp の設定と

VyOS tips

VyOS 1.1.7 （続・VyOS と PPPoE と MSS clamp の設定と - ..たれろぐ.. ）から VyOS 1.4 へ更新したので PPPoE と MSS clamp の設定を見直した。

要点
  • outbound は公式設定(adjust-mss)で設定できるようになった
  • inbound は変わらず policy 設定が必要
環境
  • NTT Flet's PPPoE の MTU 1454, MSS 1414 環境
  • VyOS 1.4-epa2
  • 2024/4/7 時点
やりかた

VyOS 1.1.7 時代の設定では PPPoE インタフェースからの outbound で MSS 値を再設定するスクリプトを仕込んでいましたが、VyOS 1.2 で adjust-mss という公式コマンドができたのでそちらで設定します。(VyOS 1.4 公式doc) 

set interfaces pppoe <interfacename> ip adjust-mss '1414'

これだけで outbound パケットには MSS 1414 が設定されます。簡単になりましたね^^。

もう一方の inboud パケットについては上の設定は考慮してくれないので、こちらは従来通り policy 設定で対応します。
以下設定を対象の PPPoE インタフェースに付けてやります。 policy とインタフェースの紐付け設定が移動しているので注意。

    route PPPOE-IN {
        interface "<interfacename>"
        rule 10 {
            protocol "tcp"
            set {
                tcp-mss "1414"
            }
            tcp {
                flags {
                    syn
                }
            }
        }
    }


以上の設定を入れて wget https://hatenadiary.org/ したときのハンドシェイク部のパケットキャプチャが次の通り。

  • LAN側
$ monitor traffic interface eth0 filter "net 54.199.90.60"
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
[A] IP 192.168.0.17.54082 > 54.199.90.60.443: Flags [S], seq 2836625661, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
[B] IP 54.199.90.60.443 > 192.168.0.17.54082: Flags [S.], seq 3661481965, ack 2836625662, win 62727, options [mss 1414,nop,nop,sackOK,nop,wscale 7], length 0
[C] IP 192.168.0.17.54082 > 54.199.90.60.443: Flags [.], ack 1, win 1027, length 0
  • PPPoE 側
$ monitor traffic interface pppoe0 filter "net 54.199.90.60"
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on pppoe0, link-type LINUX_SLL (Linux cooked v1), snapshot length 262144 bytes
[A] IP 124.99.76.45.54062 > 54.199.90.60.443: Flags [S], seq 2461816294, win 64240, options [mss 1414,nop,wscale 8,nop,nop,sackOK], length 0
[B] IP 54.199.90.60.443 > 124.99.76.45.54062: Flags [S.], seq 205872300, ack 2461816295, win 62727, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
[C] IP 124.99.76.45.54062 > 54.199.90.60.443: Flags [.], ack 1, win 1027, length 0

パケットの流れは LAN 側 [A] -> PPPoE 側 [A] -> はてな -> PPPoE 側 [B] -> LAN側 [B] の通り。

LAN 側 [A] と PPPoE 側 [A] の比較で、 outbound で MSS 1460 -> 1414 に制限されていること、 PPPoE 側 [B] と LAN 側 [B] の比較で inbound で MSS 1460 -> 1414 に制限されていることがわかります。

公式で MSS 制限に対応してくれたので無理矢理なことをしなくてすむようになり、設定が簡単になりました。
同時に inbound 側も制限かけてほしいところではありますが。。


それではよい VyOS ライフを。

参考

Ryzen イベント 18 WHEA-Logger Cache Hierarchy Error 対策に CPU LLC Level 変更が効いた

PC tips

まとめ

価格.com - 『落ちるー イベント 18 WHEA-Logger』 AMD Ryzen 9 5950X BOX のクチコミ掲示板 と同じ現象が発生していて、試行錯誤の結果、自分の環境では BIOS から CPU Load Line Calibration を Level 4 に変更してやると安定しました。

 

環境 

CPU : Ryzen7 3700X OCなし定格駆動 (PBO disable)

MB: Asrock X570 Pro4

BIOS : 2021/4/20 4.00 AMD AGESA ComboAM4v2 1.2.0.2

MEM: CFD Selection W4U3200CM-16G (DDR4-3200 16GBx2枚) 定格駆動 memtest86 完走確認済み

 

経緯的な

夜間エンコードバッチを回していると、何故かバッチが終わる前にリブートしているらしく、 Windows システムログを見ると「イベント 18 WHEA-Logger」「Cache  hierarchy error」が記録される現象が続いていた。

傾向を見ていると1,2時間高負荷状態が続くと落ちているような状況。

 

「GPUドライバが悪い」「BIOSを最新にすれば～」「メモリが～」「初期不良」などの情報があるのでドライバ, BIOS を最新にしても解消されず、熱暴走も考えられたがこちらはmax 70度ほどだし CPU のスロットリングが効くはずなので有力候補にはならず。

初期不良な期間は過ぎてるし、最近になって落ちるようになったので不良も考えにくい(経年劣化は考えられる)。

 

最終的には CPU Load Line Calibration (LLC) なるものがあると言うことを知り、そこの設定をデフォルトの Auto (Level5) から Level4 に上げてやることで(いまのところ)安定するようになった次第。

 

CPU LLC は BIOS OC Tweaker メニューの下の方にある Voltage Configuration から変更可能。デフォルトの Auto だと Level5 になっていて、高負荷時の電圧降下 (Vdroop というらしい) への補正が一番弱い設定。

ここのレベルを Level4 にあげてやると安定するようになったので、高負荷状態が続くとCPUへの供給電圧が落ちてリブート、となっていたのではないかと推測。

 

特に設定を変更したわけでも無いのに落ちるようになったということから、Windows Update によるタスクスケジューリングまわりの変更？あるいは CPU かマザーボードの経年劣化かなぁと思う次第。

サイドフローファンだから VRM 周りがへたってきてるんだろうか(まだ2年たってないのになぁ(´・ω・｀))

MajestyS のメットインに ユニカー工業 BH-34 はすっぽり入る

日々

naga-sawa.hatenadiary.org

↑先日買ったOGK KABUTO KAMUI-3 (L) はメットインに収まってくれないので日々の普段使いにはちと辛い。

シート脇のメットホルダーに吊っておく手もあるものの、過去に吊っていたヘルメットをむしり取られたことがあるので避けたいところ。

 

ということで KAMUI-3 はツーリング専用ヘルメットと言うことにして、普段使い用には近所のホームセンターで売っていた ユニカー工業の BH-34 Freeサイズ(頭囲58-60cm) を使うことにした。

これまで使っていたのとほぼ同じデザインなのでもくろみ通りマジェスティS(2014)のメットインにすっぽり収まりました。

有名どころのブランド品では無いものの最低ラインのJISとSGには準拠しているので普段のご近所乗りにはこれぐらいでもいいでしょう。

 

 

 とはいえ、やっぱり各社のメットイン-メット適合情報みたいなの欲しいよね……