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には準拠しているので普段のご近所乗りにはこれぐらいでもいいでしょう。

 

 

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

 

OGK KAMUI-3 (L) は MajestyS のメットインに収まらない

日々

OGK KAMUI-3 Lサイズ(頭囲59-60cm) はマジェスティS(2014)のメットインに収まんないです(たぶん現行モデルでも同じかと)。

 

メットインのくぼみにメットの顎部をあわせれば後頭部のフィンがメットイン後部に干渉して収まりきらず、後頭部を収めれば顎の部分がくぼみに収まらずでどちらにしろ収まらないorz

 

シートを無理矢理押し込めばロックはかかるものの、かなり無理がかかる感じなので数分程度ならともかく常用しないほうがよさげ。

 

 どこかに各社メットイン-メット適合情報みたいなのまとまってりゃいいんだけどねぇ……

 

x264 UTF-8になったとかそんなところのメモ

エンコード x264

H265 のご時世なのに、端末やら何やらの都合で x264 にしがみついてるわけですが、昨秋に入ったコミット 7ab4c928 で、 x264 がいろいろエラーを出すようになったのでメモ。

commit 7ab4c928ef4511ea5753a36a57c3506d9fd5086b
Author: Henrik Gramner <henrik@gramner.com>
Date:   Sat Sep 12 19:24:00 2020 +0200

    Add support for long filenames on Windows 10

何があったかというと、manifest ファイルが追加されてその中で activeCodePage UTF-8 という指定が付いたので、x264 プロセスのデフォルト文字コードが UTF-8 になったというそういうことです。

正道の対応策は「x264 が読むファイルは全てUTF-8にする」です。
直前のコミット d198931a63 でも「GPAC が UTF-8 サポートしてるから～」とかあるので UTF-8 統一が方針に則った方向と思います。

この変更で出るようになったエラーがこんなのです↓ (現行の master fa264466 のビルドで SJIS なファイルを読んだ場合のエラー)
中身にSJIS(非ASCII)を含む avs ファイルを入力にした場合。例えば日本語パスから Import した場合のエラーメッセージ。

avs [error]: Import: couldn't open "文字化け化け"
(Enc.avs, line 11)
x264 [error]: could not open input file `Enc.avs'

avs の中で (DGIndex で Demux した) d2v を読んでいて、d2v の中に日本語パスがあった場合のエラーメッセージ。

avs [error]: Avisynth open failure:MPEG2Source: Could not open one of the input files. (Enc.trim.avs, line 4)

(Enc.avs, line 13)
x264 [error]: could not open input file `Enc.avs'


対策としては以下のどれかで、上から順におすすめです（上で書いたとおりUTF-8化路線なので）。

  • x264 が読むファイルは全て UTF-8 にする。
    • バッチの途中とかでファイルの文字コード変換かけるようにする。など。
  • x264 が読むファイルをASCIIに統一する。
    • 上の亜種。日本語パスなど使わず全てASCIIで通せば自動的に UTF-8 対応に。
  • 7ab4c928 を含まないビルドを作る。
    • rebase -i で d 7ab4c928 したビルドで試したところ、ビルド時エラーなし。実行時も従来通りSJISファイルを与えてもエラーなしでした。ただし最後までエンコードしてないのでエンコード結果が正しいかは不明です。


エンコードチェーン見直さないと。。