マシンのネットワークが切断された場合

「ネットワークが消えた」には2つの異なるケースがあります。外部からマシンに何も届かない場合と、マシン自体がどこにも到達できない場合です。この状況ではSSHが使えないため、まずコンソールから始めます。コンソールは常に機能します。ネットワークを経由せず、マシンに直接接続されているからです。

ステップ1. コンソールから入る

/hosting/vds/m/<id> の「コンソール」タブを開きます。テキストコンソール（シリアルポート）はあらゆるコマンドで機能します。「Screen」（VNC）は、システムがシリアル回線上にプロンプトを表示しない場合に必要です。コンソールにログインプロンプトが表示されれば、マシンは生きており、問題は起動ではなくネットワークにあります。

プロンプトがなく、「Screen」にカーネルエラーメッセージが表示される場合は、カーネルパニック：次に何をすべきかを参照してください。

ステップ2. インターフェースとアドレスを確認する

ip -brief address
ip route

インターフェースには「概要」タブにあるパブリックIPv4アドレスが設定されているはずで、ルートには default via ... の行が含まれているはずです。よくある発見事項：

• インターフェースが DOWN 状態にある — 起動します：ip link set dev ens18 up；
• 手動での設定編集後にアドレスが消えた — 設定ファイルを復元し、ネットワークサービスを再起動します（Ubuntuでは systemctl restart systemd-networkd または netplan apply）；
• デフォルトルートがない — アクセスを取り戻すために ip route add default via <gateway> で一時的に復元し、その後設定を修正します。そうしないと再起動後に再発します。

ip を介した変更は再起動までしか持ちません。本当の修正は常に設定ファイルにあります。

ステップ3. 「接続不可」と「名前解決不可」を区別する

ping -c3 1.1.1.1
ping -c3 millida.net

アドレスにはpingが通るのに名前には通らない場合、ネットワークは正常で名前解決が壊れています：名前が解決されない（DNS）に進んでください。

ステップ4. パケットフィルターを確認する

アクセスを失う最も一般的な原因は、ログインを遮断した自分自身のルールです。確認してください：

nft list ruleset
iptables -S
ufw status verbose

受信トラフィックに DROP ポリシーがあり、ポート22が許可されていない場合、SSHから自分を締め出しています。コンソールからアクセスを復元します：

ufw allow 22/tcp
ufw reload

ファイアウォールを有効にする前に、必ず同じコマンドセット内でSSHポートを許可してください。「まず拒否、後で許可」というアプローチはアクセスを失う代償となります。

ステップ5. SSHデーモン自体を確認する

ネットワークが機能していても、サービスがクラッシュしたためにポートが閉じていることがあります：

systemctl status ssh
ss -tlnp | grep :22

サービスの状態を診断する方法については、サービスが起動しない：systemdのトラブルシューティングを参照してください。

何も役に立たなかった場合

「アクセス」タブからSystemRescueリカバリディスクで起動します。パスワードなしのrootログインが可能で、マシンのディスクは /dev/sda として見えます。ルートをマウントし、システムの「外側」からネットワーク設定を修正します。完了したら、通常の起動モードに戻してマシンを再起動してください。そうしないと、SystemRescueで起動し続けます。