自宅ラボの安全な入口：VLAN・SSH防御・VPN・MQTT ACLの設計

安全な入口は、製品名より「どの端末が、どの経路で、どの管理面へ届いてよいか」で決まります。この記事はVLAN・SSH防御・VPN・MQTT ACLの長い手順を連結せず、入口を選ぶ判断表と、元検証で確認できた範囲だけを残します。

入口を一つずつ減らす判断表

VLAN：SSIDの数より管理面への到達表を先に作る

決めるのはネットワーク名ではなく通信方向

管理端末、一般端末、IoT、サーバーの4役について、DNS、管理UI、SSH、インターネットへの到達可否を表にします。元記事のVLAN部分は設計一般論で、隔離後のパケット実測はありません。したがって「分離できた」とはせず、導入前の判断表として範囲を限定します。

変更中も戻る経路を一つ残す

ルール変更と同時に管理端末まで切り離すと、正しい設定へ戻せません。有線の管理経路か既存セッションを残し、許可側と拒否側を別端末から確認します。

SSH：Fail2banでは自分をbanする失敗から戻した

banリストと復旧操作を対にする

隔離環境では誤banした想定を作り、手動のunbanip後にbanリストから対象が消えることを確認しました。公開SSHを推奨する根拠ではなく、ロックアウト時の復旧操作を先に持つための検証です。

VPN：4方式の比較は入口を増やさないために使う

一つの管理用途に複数の常設入口を重ねない

元検証は使い捨てVMとDockerで4方式の到達を比べましたが、実家庭回線での長期運用値ではありません。選定時は、管理対象、クライアント対応、鍵の失効、停止方法を比較し、採用しなかった方式を常設したまま残さないことを結論にします。

回線側で通信が不安定な場合は、帯域だけでなくMAP-Eの外側ポート枯渇も別の故障として切り分けます。

MQTT：認証成功とtopic認可を分ける

許可topic、拒否topic、retain残留を別々に観測する

Mosquittoの隔離検証では、認証拒否とACL拒否を作り、検証後に元へ戻しました。接続できることは全topicへの権限を意味しません。また、送信者を止めてもretain済みメッセージは購読時に現れます。古い値を現在の送信と誤読しないため、retainの削除も撤去手順に含めます。

入口を開ける前の検収

1. 管理対象と許可する端末を一行で書く。
2. 許可側の成功と、拒否側の失敗を別端末で確認する。
3. ログに送信元・時刻・拒否理由が残るか確認する。
4. 鍵の失効、ban解除、ACL復元のいずれかを実行する。
5. 採用しない入口を停止し、外部から管理面が見えないことを読む。

観測を中央へ集めるときも、管理入口そのものを増やす必要はありません。流れない場合の切り分けはOpenTelemetry Collectorの失敗と復旧を参照してください。