☰

常に無料：Ubuntu 20.04 LTS ARMからUbuntu 22.04 LTS ARMにアップグレードした後、ネットワークなし

tag-icon • tag-icon ubuntu networking arm cloud oracle
常に無料：Ubuntu 20.04 LTS ARMからUbuntu 22.04 LTS ARMにアップグレードした後、ネットワークなし

シナリオは次のとおりです。

Ubuntu 20.04 LTSからUbuntu 22.04 LTSにアップグレードしました。ただし、アップグレード後にホストへの完全な接続が失われ、Cloud Shellコンソールを介してのみアクセスできました。

観察された行動：

  • パブリックIP経由でSSHにアクセスできません。 Cloud Shellはシリアルコンソールを介してのみ使用してください。 ECDSAが推奨されているので、鍵交換RSAが問題かどうかをテストしましたが、これは問題ではないようです。

  • 実行時にソースに接続できません。sudo apt update

  • nslookup google.esどの出力も提供しません（アクセスできません）。

  • ip addrIPインターフェイスが動作しています：

    1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000
    link/ether 02:00:17:00:95:86 brd ff:ff:ff:ff:ff:ff
    inet 10.0.0.62/24 metric 100 brd 10.0.0.255 scope global dynamic ens3
       valid_lft 62767sec preferred_lft 62767sec
    inet6 fe80::17ff:fe00:9586/64 scope link 
       valid_lft forever preferred_lft forever

  • ip route出力：

    default via 10.0.0.1 dev ens3 proto dhcp src 10.0.0.62 metric 100 
10.0.0.0/24 dev ens3 proto kernel scope link src 10.0.0.62 metric 100 
10.0.0.1 dev ens3 proto dhcp scope link src 10.0.0.62 metric 100 
169.254.169.254 via 10.0.0.1 dev ens3 proto dhcp src 10.0.0.62 metric 100

  • iptables -L出力：

    Chain INPUT (policy DROP)
target     prot opt source               destination         

Chain FORWARD (policy DROP)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

  • outの出力iptables-save -cは次のとおりです。

    :INPUT DROP [71948:4580785] 
:FORWARD DROP [0:0]  
:OUTPUT ACCEPT[59782:3909997] COMMIT
# Completed on Tue Aug 16 08:10:43 2022

  • 50-cloud-init.yamlNetplanには、次の内容を含む構成ファイルが1つしかありません。

      ethernets:
      ens3:
          dhcp4: true
          match:
              macaddress: 02:00:17:00:95:86
          set-name: ens3
  version: 2

  • /etc/resolv.conf出力：

    nameserver 127.0.0.53 
options edns0 trust-ad
search vcn09040100.oraclevcn.com

  • これがOracle Cloud構成の問題であるかどうかは不明です。何も触れておらず、以前はウェブサイトを操作してホスティングしていましたが、そうです。 VCN にはvcn-20210904-0043サブネット 10.0.0.0/24 と次の受信セキュリティリストが割り当てられます。

    Oracle Cloudセキュリティリスト

アイデアが足りなくて助けてくれてありがとう。問題なく同じVCNを共有する同じテナントで異なるインスタンスが実行されているので、これがOSの問題だと思う方向に傾いています。

答え1

あなたはiptablesネットワーク操作をブロックするルールです。明確なルールはありませんが、フィルタ/入力のデフォルトDROPポリシーという1つのルールが適用されます。これは、システムが受信したすべてのトラフィックがアプリケーションで使用される前に破棄されることを意味します。 DNS検証に失敗しました。 TCP接続（DNSが失敗したため、IPアドレスに直接接続されている）はSYN-SENT状態を維持します。など。

質問にこれについての内容はまったく記録されていないので、更新する前にシステムにどのルールがまだ存在していたかわかりません。既存のルールをルールセットとして削除するのは危険な作業です。iptables：デフォルトポリシーをに復元しませんACCEPT。したがって、すべてのフィルタリングルールを手動で削除するには、次の手順を実行する必要があります。

iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT
iptables -F
iptables -X

nat利用可能な他のテーブル（、、、mangle）がありますが、rawOPのiptables-save -cコマンドはそのテーブルが使用中であることを示していません。

上記の最初のコマンドはフィルタ/入力ポリシーを復元し、ルールと（現在は空の）ユーザーチェーンを削除した後にACCEPTのみ可能です。DROP

メモ:nftablesこの問題は発生せず、現在次のものを使用しているとnft flush ruleset仮定すると、1つのコマンドですべてのテーブルに対して上記のすべての操作を実行できます。iptablesiptables-nftnftablesAPI

その他のこと：システム構成のどの部分がファイアウォールルールを設定しているかを見つけて修正します。

これは、ファイアウォールパッケージなどの手動ルールである場合もfirewalldありますufw。そこでどのような修正をすべきかを調べる必要があります。

構成ファイルの直接手動規則の場合、このコマンドは次の候補を見つけるのに役立ちます。

grep -r 'INPUT DROP' /etc

また、システムにはファイアウォールルールがないため、良い考えではありません。しかし、まだクラウド環境で提供されるファイアウォールで保護されています。

関連情報