Tutoriel Linux

ネットワークアクセスを失うことなくnmcliでプロファイルを変更する

Débutant2 min de lecture

リモートマシンでIPアドレス、ゲートウェイ、またはDNSを変更するのは、単一のnmcliコマンドに収束します。これらの設定はNetworkManagerのプロファイルに保存され、このプロファイルを再アクティブにすると、ちょうどこのコマンドを入力するために使われているSSHセッションが切断される可能性があります。

プロファイルを変更する前に、アクティブな接続を持つプロファイルを特定し、2番目のセッションまたはハイパーバイザーのコンソールを開いたままにしておいてください。各変更を設定ドメインに制限し、変更された値を再確認し、再アクティブ化した後にルートとDNSを確認してからバックアップセッションを閉じてください。

冗長接続が見えるLinuxミニサーバーに接続されたイーサネットケーブル
ネットワークプロファイルを再アクティブにする前に、コンソールまたは2番目の接続を準備してください。

管理者を確認し、バックアップアクセスを準備する

nmcliはNetworkManagerによって管理された接続のみを操作します。systemd-networkd、ifupdown、Netplanなどの他のバックエンドによって管理されているマシンでは、これらのコマンドは実際のネットワークに影響を与えません。

systemctl is-active NetworkManager
nmcli general status
nmcli connection show --active
ip route get 1.1.1.1

systemctl is-activeはactiveを返さなければならず、nmcli general statusはエラーなく応答しなければなりません。ip route get 1.1.1.1は、このターゲットに接続するために使用されるインターフェース、ゲートウェイ、およびソースアドレスを返します:これら3つの値をメモして、再アクティブ化の後の参照にしてください。

SSHセッションが1つしかない場合、変更するプロファイルがそのセッションを運んでいる場合には不十分です:再アクティブ化中に切断されると、戻れなくなってしまいます。2番目のセッションを開いたままにしてください;VMまたはリモートサーバーでは、ハイパーバイザーまたはホスティングプロバイダーのコンソールがこの2番目のアクセスを提供します。

アクティブな接続を持つプロファイルを特定する

登録されたプロファイルのリストを表示し、アクティブなインターフェースに関連付けられたものを確認してください。

nmcli -f NAME,UUID,TYPE,DEVICE connection show
PROFILE='有線接続 1'
nmcli -f connection.id,connection.uuid,connection.interface-name,ipv4.method,ipv4.addresses,ipv4.gateway,ipv4.dns connection show "$PROFILE"
nmcli connection show --active

有線接続 1をマシンでメモした名前に置き換え、スペースが含まれている場合は引用符で囲んでください。変数PROFILEは、同じターミナル内の次のコマンドで利用可能です。出力は、IPv4がDHCPから来ているのか、手動で設定されているのかを示し、現在プロファイルに関連付けられているアドレス、ゲートウェイ、およびDNSを表示します。

プロファイルのDEVICEフィールドをnmcli connection show --activeのアクティブ行と比較してください。Wi-Fiプロファイルとイーサネットプロファイルが共存することがよくあります:非アクティブなプロファイルを変更しても、現在のセッションが切断されることはありませんが、対象とするネットワークパスが変わることもありません。

プロパティを変更し、その値を再確認する

まず、アドレスやルートに影響を与えないプロパティから始めます:このステップは、プロファイルの名前とsudo権限を確認し、現在のセッションを暴露しません。connection.autoconnect-priorityが適しています。これは、次回のプロファイル選択にのみ適用され、何も再アクティブ化しません。アクティブセッションを運ばないプロファイルであれば、この注意は任意です:失敗しても影響はありません。

sudo nmcli connection modify "$PROFILE" connection.autoconnect-priority 20
nmcli -f connection.id,connection.autoconnect-priority connection show "$PROFILE"

2番目のコマンドは20を表示する必要があります。元の値を変更する前にメモしておいて、復元できるようにしてください。各変更は、オートコネクトの優先度、DNS、またはアドレスの単一の設定ドメインに保持してください。再確認は再アクティブ化の前に行います;その後の確認に失敗した場合、その原因はこの変更に限定されます。

DHCPによって提供されるDNSを無視するための設定は明示的です:

sudo nmcli connection modify "$PROFILE" ipv4.ignore-auto-dns yes

次に、スペースで区切り、引用符で囲まれたresolverを指定します:

sudo nmcli connection modify "$PROFILE" ipv4.dns "1.1.1.1 1.0.0.1"
nmcli -f ipv4.ignore-auto-dns,ipv4.dns connection show "$PROFILE"

1.1.1.1と1.0.0.1は例として使用されています。企業やホスティングプロバイダーが独自のresolverを強制する場合は、それを保持してください:公開アドレスに置き換えないでください。ネットワークポリシーを確認せずに行わないでください。壊れた解決は、正しいルートよりも確実にアクセスを切断します。

プロファイルを手動アドレッシングに切り替えるためには、メソッド、アドレス、およびゲートウェイをまとめてコマンドで指定します:

sudo nmcli connection modify "$PROFILE" ipv4.method manual ipv4.addresses 198.51.100.10/24 ipv4.gateway 198.51.100.1
nmcli -f ipv4.method,ipv4.addresses,ipv4.gateway connection show "$PROFILE"

198.51.100.10/24および198.51.100.1は、例に予約された範囲に属します:マシンのアドレッシング計画に適応させてください。切り替えを行う前に、ip route getで表示されたDHCPリースのアドレスとゲートウェイをメモしてください:復元はipv4.methodをautoに再設定し、プロファイルを再アクティブ化します。

公式ドキュメントのNetworkManagerのnmcliは、インストールされたバージョンに応じたプロパティの名前とその構文をリストしています。

接続を再アクティブ化し、その後ルートとDNSを確認する

変更された値は、プロファイルが再アクティブ化されるまで効果がありません。nmcli connection upは、トラフィック、SSHを含めて、一時的に途切れる可能性があります。コマンドが正しくてもです。

sudo nmcli connection up id "$PROFILE"
nmcli connection show --active
ip route get 1.1.1.1
getent hosts example.com
resolvectl status

nmcli connection upはエラーなしで終了し、プロファイルはnmcli connection show --activeでアクティブであることを示す必要があります。ip route getによって返されたインターフェースとゲートウェイを、診断でメモした値と比較してください。

getent hosts example.comは、マシン上で構成されたメカニズムを使って解決をテストします。resolvectl statusは、systemd-resolvedが解決を処理している場合のアクティブなDNSを詳述します;このコマンドがあなたのディストリビューションに存在しない場合は、DNSが検証されたと考えるのではなく、本当に使用されているリゾルバを確認してください。

解決しない名前を持つ正しいルートはDNSではなく、ルートを示しています。Linuxにおけるip routeは、ルート、ゲートウェイ、およびソースアドレスを分離します。インターフェースのアドレスを再確認するためには、Linuxにおけるip addrがコントロールを補完します。

別のツールがネットワークを管理している場合は手順を中止する

初期診断が他の管理者を示した場合、nmcliでプロファイルを再アクティブ化しないでください。Ubuntuでは、YAMLファイルがNetworkManagerとは異なるバックエンドを持つNetplanによって管理される場合があります:この構成に対して逆にテストするNetplanが適しています。

2番目のSSHセッションとバックアップコンソールは、切替中のアクセス喪失のリスクを制限しますが、不正なターゲットを無害にするものではありません。プロファイル、インターフェース、ルート、および解決が期待される値に一致することを確認してから、バックアップセッションを閉じてください。