いざというときに仕えるし、実用性もあるという品を入手です。
この、充電ケーブルそのものがストラップになっているという仕様。
スマートフォンケースにアタッチメントを取り付けるだけ。
これで、ショルダーストラップ完成。
保護カバーを取り外せば充電もできます。しっかりと落ちないようにストラップつきでした。
カテゴリー: ガジェット Page 1 of 102
スマートフォンからの画像を自分のPCに転用する形で用いているNextcloud。
アップロードが途中で失敗したり、特定の条件下で接続が切れたりすることがあります。Apacheビルトインのmod_reqtimeout設定を最適化し、サーバーの安定性と利便性を両立させるためのチューニングを行いました。
環境
- Nextcloud 32
- Apache 2.4
- PHP-FPM8.3
- Ubuntu 24.04
そもそもmod_reqtimeoutとは？
Slowloris（スローロリス）攻撃への対策
このモジュールがビルトインされたのは、Slowlorisという、非常に低コストで強力な攻撃手法への対抗があります。
通常のDoS攻撃は大量の通信を送りますが、Slowlorisは逆に「極めてゆっくり」通信します。
- サーバーに接続を開始する。
- リクエスト（ヘッダーやボディ）を、タイムアウトにならないギリギリの遅さで、1バイトずつ小出しに送る。
- サーバー側は「まだデータが来るはずだ」と判断し、その接続（スレッドやプロセス）を維持し続ける。
結果 サーバーの同時接続数の上限が攻撃者の「待ち」状態で埋まってしまい、正規のユーザーがアクセスできなくなります。
mod_reqtimeout は、この「嫌がらせ」を許さないための防衛線です。
サーバーリソースの適正管理
Apacheサーバーが1つの接続を維持するには、メモリやCPUリソースを消費します。
もしタイムアウト設定がない、あるいは極端に長い場合、以下のような問題が発生します。
- ゾンビ接続の蓄積: ネットワークが切れたのにクローズ処理が終わっていない接続が残り続ける。
- リソースの浪費: 応答の遅いクライアント（意図的か否かに関わらず）のために、サーバーの貴重な作業枠をいつまでも空けておくことになります。
なぜこれがNextcloudで徒になるのか
Nextcloudのデータの性質と通信の仕組みにあります。
巨大なファイルを細切れにする
Nextcloudは、数MBから数GBあるような大きなファイルを送る際、一気に送らずにファイルを分割して、「チャンク（塊）」に分割して送信します。
- 動作の流れ:
- チャンクAを送信 → サーバーが処理 → チャンクBを送信……
- 問題点:
- チャンクとチャンクの間に、クライアント側でのファイル読み込みやハッシュ計算などで一瞬「無通信」の時間が流れます。
- 結果:
- Apacheのmod_reqtimeoutは、この無通信を先のSlowlorisと誤認して、接続をバッサリ切ってしまいます。
モバイル回線の不安定さ
Nextcloudは外出先のスマートフォンから使うことを想定しています。
- 電波の瞬断:
- 移動中にWi-Fiから4G/5G回線に切り替わったりする。
- 上り速度の制限:
- モバイル回線は「下り」は速くても「上り」が極端に遅いことが多い。
これも、先のSlowloris攻撃と見做されてしまいます。
チューニングの必要性
だからといって、このmod_reqtimeoutを無効にすると、それらの攻撃への備えがなくなります。
Nextcloudの利便性を高めつつ不審な攻撃を守るというのは
「任務」は遂行する「部下」も守る
お前ごときに「両方」やるというのはそう難しいことじゃあないな
ぐらいの精神でやっていきましょう。
さっくりとした手順
- mod_reatimeoutの設定ファイルのバックアップを取る。
- mod_reatimeoutの設定ファイルを修正する。
- サービス再起動を行う。
mod_reatimeoutの設定ファイルのバックアップ
- 念のためのモジュール確認
sudo apache2ctl -M |grep reqreqtimeout_module (shared)を確認します。（apacheをapt等で入れていれば、まず入っています）
- ファイルバックアップ
sudo cp -pi /etc/apache2/mods-available/reqtimeout.conf /path/to/backup/directory/reqtimeout.conf.$(date +%Y%m%d)/path/to/backup/directoryは自分の環境に合わせます。
- ファイルバックアップ確認
diff -u /path/to/backup/directory/reqtimeout.conf.$(date +%Y%m%d) /etc/apache2/mods-available/reqtimeout.conf エラーがないことを確認します。
mod_reatimeoutの設定ファイルを修正
/etc/apache2/mods-available/reqtimeout.confを管理者権限で修正します。
筆者は以下のように行いました。
-RequestReadTimeout body=10,minrate=500
+RequestReadTimeout body=20,minrate=500具体的には、リクエストボディ（データの送信本体）の読み取り開始を待機する時間を10秒から20秒へ延長しています。
- body=20:
- リクエストボディの最初の1バイトを待つ時間を20秒に設定。
- minrate=500:
- データが送り始められた後、最低でも秒間500バイトの転送速度を要求する。これより遅い状態が続くとタイムアウトします。
- ファイルの差分確認
diff -u /path/to/backup/directory/reqtimeout.conf.$(date +%Y%m%d) /etc/apache2/mods-available/reqtimeout.conf 以下のような差分を確認します。
-RequestReadTimeout body=10,minrate=500
+RequestReadTimeout body=20,minrate=500設定反映
- 構文チェック
sudo apache2ctl configtest→ Syntax OKとなることを必ず確認してください。でないと、apacheサービスが停止したままとなってしまい、サービス断が発生します。
- Apache サービス再起動
sudo systemctl reload apache2.service- Apacheサービス再起動確認
systemctl status apache2.serviceactive(running)を確認します。
まとめ
Nextcloudサーバーにおいて、RequestReadTimeout のbody待ち時間を延長することは、「モバイル環境や大容量ファイル送信時の安定性」を向上させるために非常に有効な手段です。
もし、ログ（Apacheのerror_log）に The timeout specified has expired や request body read timeout といった記録が残っている場合は、この値を調整してみることをお勧めします。
- 参考コマンド
sudo grep "request body read timeout" /var/log/apache2/error.log
警告: 実行中のバージョン: 2.0.4~docker; サーバーはこのTalkバージョンの全ての機能をサポートしていません。欠落している機能: chat-relay
と出たので、それに対応していきます。
環境
- Nextcloud 33.0
- Dockerを利用して高性能バックエンドサーバ（Signaling Server）を構築。構築手順
- それ以外はLAMP環境。
- Apache 2.4
- MySQL
- PHP-FPM
- その上でNextcloud
アップデートは、こちらの手順で、コマンドラインから行いました。
その後、管理画面で上記のエラーが出たという次第です。
やっぱり必要なフェイズ・ゼロ
このNextcloudを個人的に運用しているのならばそのまま行って構いません。しかし、これを組織で運用しているとなると話はまるで違います。
- NextcloudのアップデートによりDockerコンテナもアップデートが必要。
- ついてはこの計画でサーバ設定を行う
- そのため、追加で作業時間をいただきたい
- 作業時間は○時頃、○分程度で終わる。その間、Nextcloudは使えなくなる
など、利用者への周知という名の政治交渉が必要になります。この運用者の政治的な立ち位置（担当者/担当部門が強権を振るえるか否か）でも言い方や手段が決まってきます。そこは状況に応じていきましょう。
※ 検証環境を用意できる程度には時間と予算と環境に余裕がある方は、その環境にいることを感謝しつつ、検証を重ねていきましょう。
さっくりとした手順
- Nextcloudのメンテナンスモードを有効化します。
- Dockerの設定ファイルを修正します。
- Dockerコンテナを最多値揚げします。
- Nextcloudのメンテナンスモードを無効化します。
- エラーの解消を確認します。
メンテナンスモードを有効化
- Nextcloudのルートディレクトリ移動
cd /path/to/nextcloud/root/directory && pwd自分の環境に合わせます。(筆者環境/home/www-data/nextcloud)
- メンテナンスモード有効化
sudo -u www-data php occ maintenance:mode --on- メンテナンスモード確認
運用中のNextcloudのURLにアクセスし、メンテナンスモードであることを確認します。
設定ファイル (server.conf) の構成
- ファイルのバックアップ
sudo cp -pi /hoge/docker/files/nextcloud-signaling/server.conf /path/to/backup/directory/server.conf.$(date +%Y%m%d)自分の環境に合わせます。
- ファイルのバックアップ確認
diff -u /path/to/backup/directory/server.conf.$(date +%Y%m%d) /hoge/docker/files/nextcloud-signaling/server.conf差分がないことを確認します。
server.confファイル修正
chat-relay 機能を有効にするため、以下のように項目を付け加えます。
- [chat] セクション（新規追記）
[chat]
enabled = true追記したら保存を行います。
- ファイル修正確認
diff -u /path/to/backup/directory/server.conf.$(date +%Y%m%d) /hoge/docker/files/nextcloud-signaling/server.conf以下の差分を確認します。
+ [chat]
+ enabled = trueDocker アップデート・再起動
これが地味にハマりました。古い docker-compose (v1.29.x等) を使用している環境だと、イメージのメタデータ構造の違いによるエラー（KeyError: 'ContainerConfig'）が発生。
それを避けるための手順です。
- 最新イメージの直接取得
docker-compose を介さず、Docker本体で最新イメージをプルする。
sudo docker pull strukturag/nextcloud-spreed-signaling:latestsudo docker pull nats:2.9- 不完全なコンテナの掃除
作成失敗などで残った残骸を削除し、競合を防ぐ。
sudo docker container prune -f- コンテナの起動
sudo docker-compose up -dNextcloudのメンテナンスモードの無効化
- メンテナンスモード無効化
sudo -u www-data php occ maintenance:mode --off- メンテナンスモード確認
運用中のNextcloudのURLにアクセスし、管理画面に入ります。
Nextcloud管理画面での反映
Nextcloudの「設定」>「Talk」にある高性能バックエンド設定で、URL横の「チェックマーク（保存）」を押し、chat-relay が Available features に含まれたことを確認して対処完了です。
改めて思ったこと
Dockerは確かに便利な代物ですが、管理が複雑になっていくというのが難点。それ故、Dockerは最小限にして登録していきたいものです。
宅内でのサーバとして立てているUbuntu20.04という完全にEOLを迎えている機体。それがエラーを起こしたときのメモです。
1. 発生した事象
Ubuntu 20.04を入れているミニPCの起動時、画面に以下のメッセージが表示され、デスクトップが立ち上がらずに (initramfs) というプロンプトで停止しました。
sgx: disabled by BIOS(initramfs) _（入力待ち状態）
2. 原因切り分け
以下、Geminiからのアドバイス。
- SGXのメッセージ: これは単なる「通知」であり、起動不可の直接的な原因ではないことが多い。
- initramfsでの停止: 真の原因は、ファイルシステムの整合性エラー。強制終了や停電などで、Ubuntuがインストールされているディスク領域（パーティション）が正常に読み込めなくなったために発生します。
3. 対処手順（修復方法）
これに従って対処を行いました。
エラーを起こしたパーティションの特定
(initramfs) プロンプトで exit を入力
エラーの詳細（どのパーティションが壊れているか）を確認するために、まず exit と打ちます。
エラーメッセージからデバイス名を特定
The root filesystem on /dev/sdb2 requires a manual fsck
というメッセージが表示されました（筆者環境）これをメモします。
パーティション修復
特定したデバイス名に対して修復コマンドを実行します。
fsck /dev/sdb2 -y※ -y オプションを付けることで、すべての修復箇所を自動で「Yes」として処理します。
修復完了後の再起動
FILE SYSTEM WAS MODIFIED と表示されたら、以下のコマンドで再起動（またはブート続行）を試みます。
rebootまたは
exit結局原因は？
機器が古すぎたためのディスクエラー につきます。
これが仕事でしたら「さっさと取り替えろ」「いや、取り替えないように準備する」なのですが、自分の環境なのでそうはいかず。
なんとか予算と時間を見つけてリプレースをする必要に迫られました。
何かと現役なUSBメモリ。再セットアップ中に（Windows管理→ディスク管理）
このように見割り当て/もしくは複数のパーティションができた場合に対応するときのメモです。
注意点
この操作を行うと、USBメモリ内のデータはすべて消去されます。 必要なファイルがある場合は、作業前に必ずパソコン本体などへバックアップを取ってください。
ディスク番号は絶対に間違えないでください。
OSインストールドライブが文字通り吹っ飛ぶような操作です。
手順
コマンドプロンプトを管理者で実行。
Windowsキー→cmdを入力。コマンドプロンプトが入力されたら、右クリックで「管理者として実行」を選択。
コマンドプロンプトでdiskpartを起動
diskpartを入力してEnterを実行。
ディスク番号を確認
list diskを実行。
この時、上述したディスク3が操作をするUSBメモリであることを確認しましょう。
※ここでディスク番号を間違えると、パソコンのSSDなどを消去してしまうため慎重に選んでください。
USBメモリを選択
select disk 3を実行します。「ディスク 3 が選択されました」と表示されます。
中身を消去
cleanを実行します。これで、ディスク内の全てのパーティションが消えます。
新しいパーティションを作成
create partition primaryを実行します。
USBメモリのフォーマット
fs=ntfs quick等でフォーマットを行います。
終了
exitでdiskpartを抜けます。
はじめに
Webサイトを公開していると、必ず遭遇するのが「自動化された嫌がらせ」です。
ログを確認すると、1秒ごとに異なるURLへPOSTリクエストを送り続けてくるボットたちがいます。
今回は、特定のネットワークセグメントから行われた執拗な「PHPUnitのバックドア設置スキャン」に対し、アプリケーション層（ModSecurity）だけでなく、カーネル層（IPset）で物理的に遮断した際のメモです。
前提
以下の手順でipsetを導入していること。
1. ログに残る「執拗なアクセス」
ある日、アクセスログを眺めていると、以下のような文字列が並んでいることに気づきました。
# access.log の例 (ダミーデータ)
192.0.2.239 - - [06/Mar/2026:14:35:07] "POST /lib/phpunit/Util/PHP/eval-stdin.php HTTP/1.1" 404 3067 "-" "Mozilla/5.0..."
192.0.2.239 - - [06/Mar/2026:14:35:08] "POST /lib/phpunit/src/Util/PHP/eval-stdin.php HTTP/1.1" 404 3067 "-" "Mozilla/5.0..."
...攻撃者は /vendor/ や /lib/ などのディレクトリを総当たりし、脆弱性のあるPHPUnitファイルを探しています。
このアクセス元を調べてみました。
2. ASN（拠点のプロバイダー）を特定する
しかし、調べてIPをブロックするだけでは終わりません。相手は同じネットワーク（ASN）内の別IPから再び攻撃してくるからです。
そこで whois コマンドを用いて、この攻撃者が所属するネットワークの広がりを確認しました。
- 攻撃者のIPから所属ASNを特定する
※ダミーIPにしています。
whois -h whois.radb.net -- '192.0.2.239'結果、このIPは特定のホスティング事業者が管理する「広大なネットワーク帯域」の一部であることが判明しました（仮に AS_DUMMY_99 とします）。
3. 「IPset」による物理的遮断
単なるIPの拒否リストでは、数千に及ぶボットのIPを捌ききれません。数千ものIP/NWをufwでブロックすると、たちどころにその膨大なルールでufwは機能不全を起こします。
それが、上述したLinuxカーネルレベルで高速にパケットを破棄できる ipset を使用した形です。
手順：ASNを広域ブロックする
まず、そのASNが保持する全CIDRを取得し、aggregate コマンドで最適なサイズに集約します。
- ASNからルートを取得し、整理する
whois -h whois.radb.net -- '-i origin AS_DUMMY_99' | grep -E '^route:' | aggregate > ban_list.txt(aggregateがない場合はsudo apt install aggregateでインストールします)
これにより、手作業では到底管理できない広大なネットワーク帯域を、数行のルールに圧縮できます。最後に、このルールを ipset に投入します。
筆者手順ではこの形。
sudo ipset add ufw-blocklist IPアドレス・NWアドレスsudo ipset save ufw-blocklist -f /etc/ufw/ipsets.saveまとめ
なぜASNごと切り捨てるのかは「彼らの根城だから」につきます。（そのあたりは筆者コラムに書いています）
そもそも、これらのボットは、海外の法が緩いVPSや出所の怪しいプロバイダに巣喰っています。
こん城ん奴ばら共は糞じゃ
撫で切りぞ
根切りぞ
ぐらいのブロックは必要です。
このスクリプトのver.2といったところです。
#!/bin/bash
# セット名の定義
SET_NAME="ufw-blocklist"
SAVE_FILE="/etc/ufw/ipsets.save"
# 1. root権限チェック
if [[ $EUID -ne 0 ]]; then
echo "エラー: このスクリプトは sudo または root 権限で実行してください。"
exit 1
fi
# 保存用関数 (変更があった場合のみ呼び出し)
confirm_and_save() {
echo "------------------------------------------"
read -p "変更をファイルに保存しますか？ ($SAVE_FILE) (y/n): " confirm
if [[ "$confirm" =~ ^[Yy]$ ]]; then
ipset save "$SET_NAME" -f "$SAVE_FILE"
echo "保存完了しました。"
else
echo "保存をスキップしました。"
fi
}
# ipsetが存在しない場合に作成
if ! ipset list "$SET_NAME" > /dev/null 2>&1; then
echo "情報: $SET_NAME が見つからないため新規作成します。"
ipset create "$SET_NAME" hash:net
fi
while true; do
echo "=========================================="
echo " ipset 管理メニュー ($SET_NAME)"
echo "=========================================="
echo "1) ネットワーク帯/IP を追加 (例: 192.0.2.0/24 203.0.113.5)"
echo "2) ネットワーク帯/IP を削除"
echo "3) 現在のリストを表示 (list)"
echo "q) 終了"
echo "------------------------------------------"
read -p "番号を選択してください: " choice
case $choice in
1)
echo "【追加モード】追加したいNW帯を入力してください（空エンターでメニューに戻る）"
echo "例: 203.0.113.0/24 198.51.100.0/24"
changed=false
while true; do
read -p "追加対象: " targets
[ -z "$targets" ] && break
for target in $targets; do
if ipset add "$SET_NAME" "$target" 2>/dev/null; then
echo " [成功] $target を追加しました。"
changed=true
else
echo " [失敗] $target は既にあるか、形式が不正です。"
fi
done
done
[ "$changed" = true ] && confirm_and_save
;;
2)
echo "【削除モード】削除したいNW帯を入力してください（空エンターでメニューに戻る）"
changed=false
while true; do
read -p "削除対象: " targets
[ -z "$targets" ] && break
for target in $targets; do
if ipset del "$SET_NAME" "$target" 2>/dev/null; then
echo " [成功] $target を削除しました。"
changed=true
else
echo " [失敗] $target が見つからないか、形式が不正です。"
fi
done
done
[ "$changed" = true ] && confirm_and_save
;;
3)
echo "--- 現在の登録内容 ---"
ipset list "$SET_NAME" | grep -A 100 "Members:"
;;
q)
echo "終了します。"
exit 0
;;
*)
echo "無効な選択です。"
;;
esac
echo ""
done
試作版との違いは
- 連続入力に対応。ASNが持つNWを連続で断つことができます。
- 既にブロックされているNW/IPアドレスをチェックする機能を追加。
まだ詰められる感じなのでもう少し続けます。
部屋の掃除をしている中で、思わぬものを見ました。
シャープの電子ノートです。ご丁寧にほぼ日のカバーに入れていたことからも保存状況は良好でした。
画像では見切れていますが、スタイラスもカスタマイズしていたので、買った当初はそれなりに気合いを入れていたことがうかがえます。
これを使ってこなかったのは
- 万年筆を多用するようになった
- それに合わせてあの書き味が違う
で使わなくなったことは予想されますが、新たな使い道が見つかりそうです。それは
「ボードゲームの記録」。
以前の大鎌戦役のように、計算式が複数あるゲームは多々あります。そんな中で
- インク切れが起きず
- インクがコンポーネントにつかず
- 相手の服やカードにつかない
構造は非常に大事。これは少し使っていこうと思った次第です。
攻撃者の種は尽きまじという形。
この、ufwの効率化を図るスクリプトを試作です。
前提条件
上記リンク先にあるとおり、ipsetをipset-persistant抜きで入れている場合。なので、相当、対象者は限られます。
スクリプト内容
#!/bin/bash
# セット名の定義
SET_NAME="ufw-blocklist"
SAVE_FILE="/etc/ufw/ipsets.save"
# 1. root権限チェック
if [[ $EUID -ne 0 ]]; then
echo "エラー: このスクリプトは sudo または root 権限で実行してください。"
exit 1
fi
# 保存用関数
save_ipset() {
read -p "設定をファイルに保存しますか？ (y/n): " confirm
if [[ "$confirm" =~ ^[Yy]$ ]]; then
ipset save "$SET_NAME" -f "$SAVE_FILE"
echo "保存完了: $SAVE_FILE"
else
echo "保存をスキップしました（メモリ上の設定のみ更新）。"
fi
}
# ipsetが存在しない場合に作成
if ! ipset list "$SET_NAME" > /dev/null 2>&1; then
echo "情報: $SET_NAME が見つからないため新規作成します。"
ipset create "$SET_NAME" hash:net
fi
while true; do
echo "------------------------------------------"
echo " ipset 管理メニュー ($SET_NAME)"
echo "------------------------------------------"
echo "1) IP/ネットワークを追加 (例: 198.51.100.42, 203.0.113.0/24)"
echo "2) IP/ネットワークを削除"
echo "3) ステータス表示 (list)"
echo "q) 終了"
echo "------------------------------------------"
read -p "番号を選択してください: " choice
case $choice in
1)
echo "--- 追加モード ---"
read -p "追加する IP/NW: " target
if [ -n "$target" ]; then
if ipset add "$SET_NAME" "$target"; then
echo "追加成功: $target"
save_ipset
fi
fi
;;
2)
echo "--- 削除モード ---"
read -p "削除する IP/NW: " target
if [ -n "$target" ]; then
if ipset del "$SET_NAME" "$target"; then
echo "削除成功: $target"
save_ipset
fi
fi
;;
3)
echo "--- 現在のリスト ---"
ipset list "$SET_NAME"
;;
q)
echo "終了します。"
exit 0
;;
*)
echo "無効な選択です。"
;;
esac
echo ""
done後は
sudo chmod 755 ipset-block.sh等として実行権限を付与。
sudo bash ipset-block.sh等で実行することで
------------------------------------------
ipset 管理メニュー (ufw-blocklist)
------------------------------------------
1) IP/ネットワークを追加 (例: 198.51.100.42, 203.0.113.0/24)
2) IP/ネットワークを削除
3) ステータス表示 (list)
q) 終了
------------------------------------------番号表示。
--- 追加モード ---
追加する IP/NW: で、IP/NWを設定すれば、後はセーブまでしてくれます。
今後の展望
- 引数
- ファイルからの一括入力
- 既にあるリストとの突き合わせ
など。興味は尽きません。
自宅に置いてあったルータが入れ替え完了。その際、NASが固定設定だったため、接続できなかったというありがちなことをしでかしたので、そのメモです。
大前提
10年以上も前のNAS、AS-202Tでの手順です。
これは個人運用だったから助かった手。企業でこれをやるのは様々な意味でおすすめしません。
手順メモ
深夜作業だったため、写真などは残していません。ご了承ください。
あらかじめACC(ASUSTOR Control Centrer)をセットアップしておきます。
この段階で実行してもおそらくNWはスキャンされないでしょう。
設定の全リセットを行います。
ASUSTOR NASの筐体は、背面にリセットスイッチがあります。クリップの先や画鋲でないと届かない場所にあります。それを1秒ほど押し続け、ビープがなったら話します。
※設定データが消えるだけで、実データはそのままであることは安心ください。※
NASとPCをLANケーブルで直結します。
ここがポイントです。設定リセットを行うと、169.254.1.2などのIPに変わっています。
必要に応じてPCのIPアドレスを一時的に変えておくとよいでしょう。
NASの管理画面を開きます。
表示されたIPアドレス:8000をブラウザで打ち込み、ログインします。パスワードも初期パスワードに戻っています。
ネットワークの再設定を行います。
- [設定] を開く
- デスクトップにある「設定（歯車アイコン）」をクリックします。
- [ネットワーク] 画面へ移動
- 左メニューから [ネットワーク] を選び、上のタブから [ネットワークインターフェース] をクリックします。
- インターフェースの編集
- 「LAN 1」を選択した状態で、[編集] ボタンをクリックします。
- 固定IP（静的IP）の設定
- 「IPv4設定」タブで [IPアドレスを手動で設定する] にチェックを入れます。
- 以下の値を入力してください：
- IPアドレス:
192.168.xx.x（現在繋がっているアドレス） - サブネットマスク:
255.255.255.0 - デフォルトゲートウェイ:
192.168.x.1（※一般的なルーターの住所です）
- IPアドレス:
- DNSサーバーの設定
- [DNSサーバーを手動で設定する] にチェックを入れます。
- 優先DNSサーバー:
192.168.x.1（または Googleの8.8.8.8）を入力します。 - これを設定しないと「DNSサービスが動作していません」という警告が出続けます。
- 適用
- [OK] を押すと設定が保存されます。
適用後、NW配線を元に戻します。
ルータのNW配下に戻します。
復旧を確認します。
- 新しいIPアドレスでルータのNWクライアントからNASにログインできるか
- 元のファイルにアクセスできるか
の2点を確認し、パスワードの変更やアクセスポートの変更などを実施します。