セカンダリIPアドレスに関するSSHのトラブルシューティング

セカンダリIPアドレスに関するSSHのトラブルシューティング

**IP情報の追加

次の物理構成を持つUbuntu 18.04サーバーがあります。

  • 管理用1ETH
  • ローカルメディアサービス用の4つのethバインディング

初期設定は、イーサネット管理リンク経由のSSH経由で行われます。固定IPアドレスで設定しましたが、すべてがスムーズに実行されました。

次に、VLAN インターフェイスと VLAN の固定 IP アドレスを使用してバインディングを設定しました。 VLAN に SSH で接続できます。

その後、イーサネット管理リンクのIPを別々の/ 31ネットワークに変更し、管理リンクがトラフィックを受信するときにデフォルトルートを使用するようにルーティングポリシーを設定しました。

これで、問題なくSSH経由でVLAN IPに接続できます。私の管理者リンクにSSHで接続することもできますが、約30秒後にSSHセッションが中断され、30秒後にリモート側で予期せずセッションを閉じます。私はこれがある種のルーティング問題またはSSH設定調整であると仮定していますが、トラブルシューティング方法がわかりません。 Journalctl -f は、セッションが中断またはクローズされたときにイベントを記録しません。どんなアイデアもありがとうございます。

私のnetplan設定といくつかのIP出力は次のとおりです。

network:
  version: 2
  ethernets:
    enp0s31f6:
      dhcp4: no
      addresses: [192.168.3.1/31]
      #gateway4:
      routes:
        - to: 0.0.0.0/0
          via: 192.168.3.0
          metric: 500
          table: 1
      routing-policy:
          - from: 192.168.3.1
            table: 1
    enp4s0f0:
      dhcp4: no
    enp4s0f1:
      dhcp4: no
    enp4s0f2:
      dhcp4: no
    enp4s0f3:
      dhcp4: no

network:
  version: 2
  bonds:
    bond0:
      dhcp4: no
      interfaces:
        - enp4s0f0
        - enp4s0f1
        - enp4s0f2
        - enp4s0f3
      parameters:
        mode: 802.3ad
        primary: enp4s0f0

network:
  version: 2
  vlans:
    bond0.2022:
      dhcp4: no
      id: 2022
      link: bond0
      addresses: [192.168.1.239/23]
      gateway4: 192.168.0.1
      nameservers:
        addresses: [192.168.0.1]

~$ ip route
default via 192.168.0.1 dev bond0.2022 proto static
192.168.0.0/23 dev bond0.2022 proto kernel scope link src 192.168.1.250
192.168.3.0/31 dev enp0s31f6 proto kernel scope link src 192.168.3.1
192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1 linkdown

$ ip route show dev enp0s31f6 table 1
default via 192.168.3.1 proto static metric 500
default via 192.168.3.0 proto static metric 500

~$ ip a | grep UP
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
2: enp4s0f0: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc mq master bond0 state UP group default qlen 1000
3: enp4s0f1: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc mq master bond0 state UP group default qlen 1000
4: enp4s0f2: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc mq master bond0 state UP group default qlen 1000
5: enp0s31f6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
6: enp4s0f3: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc mq master bond0 state UP group default qlen 1000
7: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
8: bond0.2022@bond0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
9: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000

C:\tracert 192.168.1.250

Tracing route to 192.168.1.250 over a maximum of 30 hops

  1    <1 ms    <1 ms    <1 ms  192.168.1.250

Trace complete.

C:\tracert 192.168.3.1

Tracing route to 192.168.3.1 over a maximum of 30 hops

  1    <1 ms    <1 ms    <1 ms  192.168.0.1
  2     1 ms     1 ms    <1 ms  192.168.1.241
  3    <1 ms    <1 ms    <1 ms  192.168.3.1

Trace complete.

ベストアンサー1

私の問題を解決しました。クライアントサブネットには、ファイアウォールとリモートネットワーク用のルータという2つのルーティングインターフェイスがあります。ファイアウォールはデフォルトゲートウェイですが、ルータは管理に使用するリモートネットワークのネクストホップです。デフォルトゲートウェイの代わりに、ルーターのネクストホップにリモートネットワーク用のクライアントの固定パスを追加しましたが、SSHセッションは閉じられなくなりました。

おすすめ記事