Điểm:0

Kết nối cầu container với mạng con trên Hetzner và CNI

lá cờ us
cpl

Tôi đang cố gắng tạo một mạng riêng gồm các máy ảo và vùng chứa trên Đám mây Hetzner. Tôi đã thử nghiệm thiết lập này trên mạng gia đình cục bộ của mình và tất cả đều hoạt động tốt.

Kế hoạch là có một mạng riêng cho máy ảo (10.0.0.0/8 chỉ để thử nghiệm). Đối với thử nghiệm của tôi, tôi đang sử dụng 10.10.0.110.10.0.2 như VM. Và mỗi VM, sẽ có một mạng cầu nối CNI, (ví dụ: 172.20.0.0/16, cho vùng chứa). Tôi muốn làm cho các mạng cầu nối có thể truy cập được bởi bất kỳ VM nào trên 10.0.0.0/8 mạng, với các tuyến tĩnh.

Trên Hetzner, tôi đã định cấu hình một tuyến tĩnh 172.20.0.0/16 đến 10.10.0.1. Trên 10.10.0.1 Tôi có mạng cầu nối CNI cho Podman, được định cấu hình trên cùng một phạm vi 172.20.0.0/16.

Bất kỳ vùng chứa nào được đặt trên mạng đó, không gặp sự cố khi ping hoặc liên hệ với: cục bộ, vùng chứa khác, máy chủ hoặc internet và máy chủ lưu trữ (10.10.0.1) không gặp khó khăn khi tiếp cận các thùng chứa (172.20.0.X).

Vấn đề là khi tôi muốn ping container từ 10.10.0.2. Tôi đã theo dõi lưu lượng truy cập với tcpdumpnếu hàng đầuvà tuyến đường Hetzner dường như hoạt động tốt, vì các kết nối đến VM trên 10.10.0.1 (ens10). Điều này khiến tôi tự hỏi liệu đó có phải là sự cố định tuyến giữa ens10podman-vlan giao diện cầu nối?

Đây là các tuyến đường từ 10.10.0.1

mặc định qua 172.31.1.1 dev eth0 proto dhcp src X.Y.Z.W số liệu 100 
10.0.0.0/8 đến 10.0.0.1 dành cho nhà phát triển và 10 
Liên kết phạm vi 10.0.0.1 dev ens10 
172.17.0.0/16 dev docker0 liên kết phạm vi kernel proto src 172.17.0.1 
172.20.0.0/16 dev podman-vlan liên kết phạm vi kernel proto src 172.20.0.1 
172.31.1.1 dev eth0 proto liên kết phạm vi dhcp src X.Y.Z.W số liệu 100 

trên 10.10.0.2 VM, tôi mới chỉ thực hiện một ip r thêm 172.20.0.0/16 qua 10.0.0.1 (có vẻ như hoạt động như).

kỳ vọng của tôi là để có được 10.10.0.2 -> 10.0.0.1 -> 10.10.0.1 -> 172.20.0.1 -> 172.20.0.X. Thay vào đó mọi thứ dường như bị mất tại 10.10.0.1, bao gồm cả nếu tôi cố gắng ping -I ens10 172.20.0.X

Đây là cấu hình CNI:

{
  "cniVersion": "0.4.0",
  "tên": "podman",
  "bổ sung": [
    {
      "type": "cầu",
      "cầu": "podman-vlan",
      "isGateway": đúng,
      "ipMasq": đúng,
      "promiscMode": đúng,
      "ipam": {
        "type": "host-local",
        "tuyến đường": [{ "dst": "0.0.0.0/0" }],
        "các dãy": [
          [
            {
              "mạng con": "172.20.0.0/16",
              "cổng": "172.20.0.1"
            }
          ]
        ]
      }
    },
    {
      "type": "sơ đồ cổng",
      "khả năng": {
        "portMappings": đúng
      }
    },
    {
      "loại": "tường lửa"
    },
    {
      "loại": "điều chỉnh"
    }
  ]
}

Cảm ơn trước.

Điểm:0
lá cờ us
cpl

Đó là sự cố với Docker tồn tại trên VM và iptables đó.

kiểm tra iptables -L trên máy ảo

Chuỗi FORWARD (chính sách DROP)
đích prot opt ​​nguồn đích
DOCKER-USER all -- mọi nơi mọi nơi
CNI-FORWARD all -- mọi nơi mọi nơi

Docker được ưu tiên. Vì vậy, hãy định cấu hình quy tắc để chuyển tiếp giao diện phù hợp tới CNI/Podman/Docker hoặc bất kỳ thứ gì cần thiết.

Trong trường hợp của tôi, việc xóa Docker là một tùy chọn và điều đó đã khắc phục mọi thứ.

Đăng câu trả lời

Hầu hết mọi người không hiểu rằng việc đặt nhiều câu hỏi sẽ mở ra cơ hội học hỏi và cải thiện mối quan hệ giữa các cá nhân. Ví dụ, trong các nghiên cứu của Alison, mặc dù mọi người có thể nhớ chính xác có bao nhiêu câu hỏi đã được đặt ra trong các cuộc trò chuyện của họ, nhưng họ không trực giác nhận ra mối liên hệ giữa câu hỏi và sự yêu thích. Qua bốn nghiên cứu, trong đó những người tham gia tự tham gia vào các cuộc trò chuyện hoặc đọc bản ghi lại các cuộc trò chuyện của người khác, mọi người có xu hướng không nhận ra rằng việc đặt câu hỏi sẽ ảnh hưởng—hoặc đã ảnh hưởng—mức độ thân thiện giữa những người đối thoại.