Puncte:0

Rețea de poduri containere cu subrețea pe Hetzner și CNI

drapel us
cpl

Încerc să creez o rețea privată de VM și containere Norul Hetzner. Am testat această configurație pe rețeaua mea locală de acasă și totul funcționează bine.

Planul este de a avea o rețea privată pentru VM-uri (10.0.0.0/8 doar pentru testare). Pentru testul meu il folosesc 10.10.0.1 și 10.10.0.2 ca VM-uri. Și fiecare VM, va avea o rețea de punte CNI, (de exemplu: 172.20.0.0/16, pentru container). Vreau să fac rețelele bridge accesibile de către orice VM de pe 10.0.0.0/8 rețea, cu rute statice.

Pe Hetzner, am configurat o rută statică 172.20.0.0/16 până la 10.10.0.1. Pe 10.10.0.1 Am o retea bridge CNI pentru Podman, configurata pe aceeasi gama 172.20.0.0/16.

Orice container care este plasat în rețeaua respectivă, nu are probleme cu ping sau să contacteze: local, alte containere, gazdă sau internet și gazdă (10.10.0.1) nu are probleme în a ajunge la containere (172.20.0.X).

Problema este când vreau să ping containerul din 10.10.0.2. Am monitorizat traficul cu tcpdump și iftop, iar ruta Hetzner pare să funcționeze bine, deoarece conexiunile ajung la VM-ul pornit 10.10.0.1 (ens10). Ceea ce mă face să mă întreb dacă este o problemă de rutare între ens10 și podman-vlan interfețe bridge?

Iată traseele de la 10.10.0.1

implicit prin 172.31.1.1 dev eth0 proto dhcp src X.Y.Z.W metric 100 
10.0.0.0/8 prin 10.0.0.1 dev ens10 
10.0.0.1 dev ens10 scope link 
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 
172.20.0.0/16 dev podman-vlan proto kernel scope link src 172.20.0.1 
172.31.1.1 dev eth0 proto dhcp scope link src X.Y.Z.W metric 100 

Pe 10.10.0.2 VM, am făcut doar o ip r adăugați 172.20.0.0/16 prin 10.0.0.1 (care pare să funcționeze ca).

Așteptarea mea era să ajung 10.10.0.2 -> 10.0.0.1 -> 10.10.0.1 -> 172.20.0.1 -> 172.20.0.X. În schimb, totul pare să se piardă 10.10.0.1, inclusiv dacă încerc ping -I ens10 172.20.0.X

Aceasta este configurația CNI:

{
  "cniVersion": "0.4.0",
  "nume": "podman",
  „pluginuri”: [
    {
      "tip": "pod",
      "bridge": "podman-vlan",
      „isGateway”: adevărat,
      „ipMasq”: adevărat,
      „promiscMode”: adevărat,
      „ipam”: {
        "tip": "gazdă-local",
        "rute": [{ "dst": "0.0.0.0/0" }],
        „interval”: [
          [
            {
              „subrețea”: „172.20.0.0/16”,
              „gateway”: „172.20.0.1”
            }
          ]
        ]
      }
    },
    {
      "type": "portmap",
      „capacități”: {
        „portMappings”: adevărat
      }
    },
    {
      "type": "firewall"
    },
    {
      "type": "tuning"
    }
  ]
}

Mulțumesc anticipat.

Puncte:0
drapel us
cpl

A fost o problemă cu Docker existent pe acel VM și iptables.

Control iptables -L pe VM

Lanț FORWARD (politica DROP)
target prot opt ​​sursă destinație
DOCKER-USER all -- oriunde oriunde
CNI-FORWARD toate -- oriunde oriunde

Docker a avut prioritate. Deci, fie configurați regula pentru a trimite interfața potrivită către CNI/Podman/Docker, sau orice este necesar.

În cazul meu, eliminarea Docker a fost o opțiune și asta a rezolvat totul.

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.