Leiten Sie den Datenverkehr mithilfe von iptables an den Kubernetes-Cluster weiter.

Leiten Sie den Datenverkehr mithilfe von iptables an den Kubernetes-Cluster weiter.

Ich habe einen Kubernetes-Cluster (derzeit nur 1 Knoten) auf meinem Root-Server (NetCup) laufen und versuche, den Verkehr dorthin umzuleiten. Ich bin ziemlich schlecht im Netzwerken, also kann mir hoffentlich jemand helfen.

Auf dem Clustermetallbist installiert und Calico als CNI. Metallb ist für die Zuweisung und Bekanntgabe von IP-Adressen an K8s-LoadBalancer zuständig, was intern einwandfrei funktioniert. So kann ich einen Load-Balanced-Dienst vom Server aus erreichen. Ich stelle nur einen einzigen Dienst mit einer festen internen IP zur Verfügung (Reverse-Proxy).

Jetzt möchte ich es nach außen zugänglich machen, indem ich den Verkehr direkt an die IP-Adresse von metallb weiterleite, indem ichiptables

Die folgenden Regeln wurden in iptables angewendet:

iptables -A PREROUTING -t nat -p tcp -m tcp -j DNAT --to-destination <metallb-ip> -i eth0 --destination-port 80 -m comment --comment Redirect web traffic to cluster (80)
iptables -A PREROUTING -t nat -p tcp -m tcp -j DNAT --to-destination <metallb-ip> -i eth0 --destination-port 443 -m comment --comment Redirect web traffic to cluster (443)
iptables -A POSTROUTING -t nat -p tcp -m tcp -j SNAT --to-source <public-server-ip> -o eth0 --destination-port 80 -m comment --comment Redirect web traffic from cluster (80)
iptables -A POSTROUTING -t nat -p tcp -m tcp -j SNAT --to-source <public-server-ip> -o eth0 --destination-port 443 -m comment --comment Redirect web traffic from cluster (443)

(Vielleicht sind die Befehle nicht 100 % korrekt, weil ich sie aus meinem Ansible-Skript extrahiert habe. Den Ansible-Teil finden Sie unten)

Soweit ich das verstehe, sollte dies den gesamten eingehenden TCP-Verkehr mit DNAT an die interne IP senden und den gesamten ausgehenden Verkehr mit SNAT über die öffentliche Serveradresse verfügen. Für einen sich verbindenden Client sollte es also so aussehen, als würde er direkt mit der öffentlichen IP/dem öffentlichen Port kommunizieren?

Leider führt der Versuch, über das Internet auf den Dienst zuzugreifen, zu folgendem Ergebnis:

$> curl <public-server-ip>
curl: (7) Failed to connect to <public-server-ip> port 80 after 647 ms: Network is down

Der Zugriff vom Server aus funktioniert:

$> curl <metallb-ip>
404 page not found # which the expected answer since its a blank Traefik reverse proxy

Ein Nmap-Port-Scan gibt derzeit Folgendes aus:

$> nmap -Pn -p 80,443 <public-server-ip>
Starting Nmap 7.93 ( https://nmap.org ) at 2022-12-15 15:57 CET
Strange SO_ERROR from connection to <public-server-ip> (50 - 'Network is down') -- bailing scan
QUITTING!

Aber es läuft, da ich über SSH verbunden bin.

Derzeit ist keines ufwaktiviert.

Ich bin für jede Hilfe dankbar, da ich, wie gesagt, nicht sehr gut im Netzwerken bin. ;)

Ansible-Skript:

- name: DNAT port 80 to cluster
  iptables:
    table: nat
    chain: PREROUTING
    in_interface: eth0
    protocol: tcp
    match: tcp
    jump: DNAT # REDIRECT
    to_destination: <metallb-ip>
    destination_port: 80
    comment: Redirect web traffic to cluster (80)
  become: yes

- name: DNAT port 443 to cluster
  iptables:
    table: nat
    chain: PREROUTING
    in_interface: eth0
    protocol: tcp
    match: tcp
    destination_port: 443
    jump: DNAT # REDIRECT
    to_destination: <metallb-ip>
    comment: Redirect web traffic to cluster (443)
  become: yes 

- name: SNAT port 80 from cluster
  iptables:
    table: nat
    chain: POSTROUTING
    out_interface: eth0
    protocol: tcp
    match: tcp
    destination_port: 80
    jump: SNAT # REDIRECT
    to_source: <public-server-ip>
    comment: Redirect web traffic from cluster (443)
  become: yes

- name: SNAT port 443 from cluster
  iptables:
    table: nat
    chain: POSTROUTING
    out_interface: eth0
    protocol: tcp
    match: tcp
    destination_port: 443
    jump: SNAT # REDIRECT
    to_source: <public-server-ip>
    comment: Redirect web traffic from cluster (443)
  become: yes

- name: Configure IP Masquerading
  iptables: 
    table: nat
    chain: POSTROUTING
    out_interface: eth0
    jump: MASQUERADE

AKTUALISIEREN: Mit der Hilfe vonDasArtikel habe ich versucht, den Ablauf zu verstehen. Ich habe Protokollierungsanweisungen hinzugefügt, um zu untersuchen, wo etwas schief läuft. Das ist, was ich bisher gefunden habe:

Um zu überprüfen, wo Pakete verloren gehen, habe ich die folgenden Regeln hinzugefügt:

iptables -t raw -A PREROUTING -p tcp --dport 80 -j LOG --log-prefix "[raw:PREROUTING]: "
iptables -t mangle -A PREROUTING -p tcp --dport 80 -j LOG --log-prefix "[mangle:PREROUTING]: "
iptables -t nat -A PREROUTING -p tcp --dport 80 -j LOG --log-prefix "[nat:PREROUTING]: "
iptables -t mangle -A POSTROUTING -p tcp --sport 80 -j LOG --log-prefix "[mangle:PREROUTING]: "
iptables -t nat -A POSTROUTING -p tcp --sport 80 -j LOG --log-prefix "[nat:PREROUTING]: "

Darunter erscheinen /var/log/kern.lognur die rawund mangleProtokollanweisungen. Es scheint also, dass der nat-Schritt nicht ausgelöst wird. Ich habe die Mangle-Regeln mit: überprüft, sudo iptables -t mangle -Lkonnte hier aber kein Problem feststellen.

IP-Forward ist aktiviert:

$> sudo sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 1

Warum kommen die Pakete also nicht zum nat-Schritt?

$> sudo iptables -t mangle -L
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination
cali-PREROUTING  all  --  anywhere             anywhere             /* cali:6gwbT8clXdHdC1b1 */
LOG        tcp  --  anywhere             anywhere             tcp dpt:http LOG level warning prefix "[mangle:PREROUTING]: "

Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination
cali-POSTROUTING  all  --  anywhere             anywhere             /* cali:O3lYWMrLQYEMJtB5 */

Chain KUBE-IPTABLES-HINT (0 references)
target     prot opt source               destination

Chain KUBE-KUBELET-CANARY (0 references)
target     prot opt source               destination

Chain KUBE-PROXY-CANARY (0 references)
target     prot opt source               destination

Chain cali-from-host-endpoint (1 references)
target     prot opt source               destination

Chain cali-to-host-endpoint (1 references)
target     prot opt source               destination

Chain cali-PREROUTING (1 references)
target     prot opt source               destination
ACCEPT     all  --  anywhere             anywhere             /* cali:6BJqBjBC7crtA-7- */ ctstate RELATED,ESTABLISHED
ACCEPT     all  --  anywhere             anywhere             /* cali:KX7AGNd6rMcDUai6 */ mark match 0x10000/0x10000
cali-from-host-endpoint  all  --  anywhere             anywhere             /* cali:wNH7KsA3ILKJBsY9 */
ACCEPT     all  --  anywhere             anywhere             /* cali:Cg96MgVuoPm7UMRo */ /* Host endpoint policy accepted packet. */ mark match 0x10000/0x10000

Chain cali-POSTROUTING (1 references)
target     prot opt source               destination
RETURN     all  --  anywhere             anywhere             /* cali:NX-7roTexQ3fGRfU */ mark match 0x10000/0x10000
MARK       all  --  anywhere             anywhere             /* cali:nnqPh8lh2VOogSzX */ MARK and 0xfff0ffff
cali-to-host-endpoint  all  --  anywhere             anywhere             /* cali:nquN8Jw8Tz72pcBW */ ctstate DNAT
RETURN     all  --  anywhere             anywhere             /* cali:jWrgvDQ0xEZHmta3 */ /* Host endpoint policy accepted packet. */ mark match 0x10000/0x10000

verwandte Informationen