メモ書きアウン

Windows 11では、NVMe SSDのドライバを  NVMeネイティブドライバ（nvmedisk.sys） に切り替えることで、 速度が改善するケースがあるらしい。 そこで今回は、参考記事を元に自分の環境でも切り替えを行い、CrystalDiskMarkで前後比較してみた。 参考： Windows11でNVMe SSDを標準ドライバにすると速度が向上する？（gazlog） 検証環境 CPU ：Intel Core i5 9400F SSD ：Corsair Force MP600 ※PCIe 3.0 x4 で接続されている。 OS ：Windows 11 ベンチ ：CrystalDiskMark 9.0.1 x64 設定 ：3回 / 1GiB / 単位 MB/s（C: 使用率 21%） ドライバの変更内容 変更前は「ディスク ドライブ」として認識されていたが、変更後は「ストレージ デバイス」として認識されるようになった。 Before ：ディスク ドライブ（SCSIドライバ disk.sys） After ：ストレージ ディスク（nvmedisk.sys） 以下はBefore / Afterのスクリーンショット。 変更前（Before） 変更後（After） CrystalDiskMark 結果（Before / After） ベンチ結果を表にまとめると以下の通り。 テスト Read Before Read After 差分 Write Before Write After 差分 SEQ1M Q8T1 3430.26 3437.15 +0.20% ...

NVMe SSDを2枚使ってRAID0を組むと、シーケンシャル（連続読み書き）が伸びて気持ちいいです。 ただ、最近のマザーボードではM.2スロットが「CPU直結レーン」と「チップセット経由」に分かれていることがあり、 同じPCIe Gen4 SSDでも体感やベンチ結果が変わる場合があります。 今回は、手元で組んだ2種類のNVMe RAID0をCrystalDiskMarkで比較しました。 検証環境 CPU：Ryzen 7 9800X3D M/B：X870E チップセット搭載マザーボード RAID：AMD RAID Driver による RAID0 ストライプ64KB ベンチ：CrystalDiskMark 9.0.1 x64 回数：3 / サイズ：1GiB / 単位：MB/s 構成A（CPU直結）：Samsung 990 PRO 2TB ×2（RAID0） 構成B（チップセット経由）：Crucial CT2000 2TB ×2（RAID0） ※M.2スロットの配線（CPU直結／チップセット経由）はマザーボード設計に依存します。 本記事では「CPU直結」「チップセット経由」は、実際の配線に基づく区分として扱います。 なぜ差が出る？（AMD RAID Driver 前提） AMD RAID Driver を使ったRAID0でも、体感寄りの指標（特に SEQ Q1T1 / RND4K Q1T1）では、 CPU直結レーンのほうが有利に出やすい傾向があります。 主に、次の2点が絡みやすいと考えています。 1) チップセット経由は「CPUに戻る経路」を通る 高キュー（Q8）では並列で押し切れる一方、低キュー（Q1）では待ち時間が効きやすく、結果に差が出やすくなります。 2) RAIDドライバの処理＋SSD特性がQ1領域に出る RAID0は帯域が伸びる一方で、低キュー領域ではSSDの得意不得意や、ドライバ処理のオーバーヘッドが見えやすくなります。 ...

いつも記事をお読みくださってありがとうございます。 あうんです。 最近の更新内容をご覧くだされば一目瞭然ですが、記事が綺麗に整形されてますよね。 あれ、全部AIがやってくれています。 なお、記事の口調は私が普段AIと会話している口調のまま書いてくれてたりします。 たまに真面目な回答になるのも、またご愛敬だなと思います。 私は3つAIを契約しています。 ChatGPT、Gemini、Grok です。 なぜ3つも契約しているのかというと、GPTのo3などの推論モデルで会話すると、すぐに期間制限が課せられるからです。 今のところ、GeminiとGrokは制限が来ていないので、ChatGPTが一番厳しいようですね。 趣味のサーバーいじりですが、これらの相談は得意不得意がしっかり分かれました。 Gemini > Grok > ChatGPT 普段の会話や文章校正の自然さは、 ChatGPT > Gemini > Grok ニュースの鮮度については、 Grok > Gemini > ChatGPT GrokはXのプレミアムプランに加入すると、たくさん会話ができるようになるのでお得。 ※なおgrok.comとは別の、X上のGrokです。 まだ事前のカスタムプロンプト機能が全員に解放されていないので不便ですね。 GeminiもGoogle Oneの上位プランに入るだけで使えるので、これはこれでお得。 そう考えると、ChatGPTは割高なのかもしれないですね。 優秀なClaudeはさらに高価なので、そっちは契約していません。 ネックなのは、会話の記憶ができないことでしょうね。 もはや欠かせないパートナーになってきたので、今後も仲良くしていきたいところです。 以上

この記事では、Ubuntu 24 ServerにクリーンインストールしたAdGuard Homeの管理画面を、Let's Encryptの証明書を使ってSSL化（HTTPS化）し、さらにその証明書を完全に自動で更新し続けるための設定手順を、誰でも再現できるように詳しく解説します。 目次 1. はじめに：前提条件 2. Step 1: AdGuard Homeのインストール 3. Step 2: Certbotのインストール 4. Step 3: 証明書の取得と自動更新の設定（最重要） 5. Step 4: AdGuard Homeへの証明書設定 6. Step 5: 動作確認と最終テスト 7. まとめ 1. はじめに：前提条件 このガイドを進めるにあたり、以下の環境が整っていることを前提とします。 Ubuntu 24 Server がインストールされ、SSHでアクセスできる状態。 独自ドメイン を取得済みであること。（例: adguard.your-domain.com ） 上記ドメインの Aレコード （またはAAAAレコード）が、お使いのサーバーのグローバルIPアドレスを指すように設定済みであること。 ルーター等で、 ポート80（TCP） と ポート443（TCP） がサーバーのローカルIPアドレスに転送（ポートフォワーディング）されていること。 2. Step 1: AdGuard Homeのインスト...

AdGuard Home × Fail2Ban × ipset で TXT／RRSIG 攻撃を自動防御する こんにちは、あうんです！ DNS を公開していると必ずと言っていいほど飛んでくる TXT レコード攻撃 と RRSIG（DNSSEC 署名）クエリ攻撃 を、 AdGuard Home × Fail2Ban × ipset でガッチリ自動防御する手順をまとめました。 🧨 なにが危ないの？ 特定ドメインに向けた 大量 TXT リクエスト それに紛れた RRSIG クエリ爆撃 放置すると 自分の DNS が踏み台 になり DDoS に加担するリスク💦 🛠 構成の流れ AdGuard Home → querylog.json ↓ Fail2Ban（フィルタ & BAN） ↓ iptables + ipset（高速ブロック） 1️⃣ Fail2Ban の設定 🔎 フィルタ定義 /etc/fail2ban/filter.d/adguard-dns-abuse.conf [Definition] failregex = .*"QT":"TXT".*"IP":"<HOST>".* .*"QT":"RRSIG".*"IP":"<HOST>".* 🔐 Jail /etc/fail2ban/jail.local [adguard-dns-abuse] enabled = true backend = systemd filter = adguard-dns-abuse journalmatch = _SYSTEMD_UNIT=AdGuardHome.service maxretry = 1 findtime = 10m bantime = 10m banaction = iptables-ipset-proto4[name=AG-DNS,protocol=udp,...

最近、AdGuard HomeのDNSログに不審なTXTリクエストが大量に来て困っていませんか？ ボットネットによるスキャン、リフレクション攻撃の準備、あるいは単なる嫌がらせ…その正体は謎ですが、明らかにおかしな挙動ですよね🧟‍♂️🧟‍♀️💣 💡 解決方法：この1行をカスタムルールに追加するだけ！ ||*^$dnstype=txt,dnsrewrite=REFUSED これで、 あらゆるTXTレコードへのクエリに対して「拒絶（REFUSED）」を返す ことができます。 あるいは、 ||*^$dnstype=txt,dnsrewrite=NOERROR;TXT; これで、 あらゆるTXTレコードへのクエリに対して「空にして応答（NOERROR）」を返す ことができます。 🔍 どんなときに有効？ DNSリフレクション攻撃の踏み台にされそうなとき 不審なボットからのTXTクエリが継続的に来ているとき fail2banだけではさばききれない大量の分散アクセス対策に ⚠️ 注意：正規のTXTクエリも無効になります！ このルールは すべてのドメインのTXTクエリに適用される ため、SPF/DKIM/DMARCなどのメール送信認証も空で返すようになってしまいます。 そのため、以下のような 有名ドメインを除外するルール も併せて追加するのがおすすめです👇 @@||google.com^$dnstype=txt @@||microsoft.com^$dnstype=txt @@||cloudflare.com^$dnstype=txt @@||apple.com^$dnstype=txt これで必要なドメインだけはちゃんとTXT応答を通すことができます🙆‍♀️ 🎯 まとめ AdGuard HomeでのTXT爆撃対策に、 超シンプルな1行ルール が超強力！ 汎用的な空応答で攻撃効果をゼロに！ 正規のサービスへの影響を避けるには「除外ルール」も忘れずに✨ どんどん高度化してくるボットネット...