IPv6 weiterleitung IPtables

  • Hallo zusammen

    Ich habe hier bei netcup einen kleinen vServer welcher per IPv4 und IPv6 erreichbar ist. Per Wireguard gibt es einem Verbindung zu meinem Homeserver auf welchem mailcow installiert ist. Die Verbindung per Wireguard ist mit IPv4 und IPv6 eingerichtet und auch in beide richtungen per Ping erreichbar.


    Nun habe ich per iptables einige Regeln für Ports welche auf dem vServer ankommen und dann per Wireguard zum Homeserver sollen. Mit IPv4 klappt alles. Aber die Regeln für IPv6 scheinen nicht zu funktionieren.



    Was muss ich an den Reglen für IPv6 ändern damit auch diese funktionieren?

  • Danke für deinen Tipp fd42:42:42::2 ist die Interne IPv6 Adresse 4190 ist der Port.


    Ich habe


    -A PREROUTING -i eth0 -p tcp -m tcp --dport 25 -j DNAT --to-destination fd42:42:42::2:25


    zu


    -A PREROUTING -i eth0 -p tcp -m tcp -d fd42:42:42::2 --dport 25 -j DNAT --to :25


    geändert. Aber bisher hat dies auch keinen Erfolg gebracht.

  • Ich möchte lösen! Ich mach das so:

    Code
    1. # SSH /SFTP
    2. /sbin/ip6tables -t nat -A PREROUTING -d $ext_ip -i $ext_int -p tcp --dport 12345 -j DNAT --to [fd00:21:1::116]:22
    3. /sbin/ip6tables -A FORWARD -p tcp --dport 22 -d fd00:21:1::116 -m state --state NEW -j ACCEPT
    4. /sbin/ip6tables -A FORWARD -p tcp --sport 22 -s fd00:21:1::116 -m state --state RELATED,ESTABLISHED -j ACCEPT


    Und es funktioniert sogar. Zumindest unter Proxmox mit meinen LXC Containerchens. ^^

  • Ich möchte lösen! Ich mach das so:

    Code
    1. # SSH /SFTP
    2. /sbin/ip6tables -t nat -A PREROUTING -d $ext_ip -i $ext_int -p tcp --dport 12345 -j DNAT --to [fd00:21:1::116]:22
    3. /sbin/ip6tables -A FORWARD -p tcp --dport 22 -d fd00:21:1::116 -m state --state NEW -j ACCEPT
    4. /sbin/ip6tables -A FORWARD -p tcp --sport 22 -s fd00:21:1::116 -m state --state RELATED,ESTABLISHED -j ACCEPT


    Und es funktioniert sogar. Zumindest unter Proxmox mit meinen LXC Containerchens. ^^

    Ich hoffe, dass hier noch jemand mit liest.

    Ich hatte nun einen ähnlichen Fall. Ich habe LXD auf dem Server und wollte eine Portweiterleitung zu einem Container machen. Dieser Beitrag hat mir dabei sehr geholfen, da ich in IPv6 noch völlig neu bin. Allerdings funktioniert bei mir die ganze Sache bereits alleine mit der ersten Regel (PREROUTING). Die anderen beiden brauche ich gar nicht. Hat sich da etwas geändert, dass man diese nicht braucht, oder gibt es einen besonderen Sinn, warum man diese beiden Regeln auch noch eintragen sollte? Ich nutze Ubuntu Server 20.04.

  • Die anderen beiden brauche ich gar nicht.

    Das kommt darauf an, wie deine sonstigen Regeln aussehen, insbesondere die Policies.

    Eine Philosophie bei Serversicherheit ist bspw. dass nur bestimmte Ports offen sein sollen und der Rest durch die Firewall geschlossen ist.

    Ich gehe mal davon aus, dass bei whoami0501 alles auf "Default Closed" steht, und deshalb die letzten beiden Regeln explizit Port 22 erlauben.


    Entsprechend wird über oder unter dem Scriptausschnitt ein ip6tables -P FORWARD DROP bzw. ip6tables -A FORWARD -j REJECT stehen.

    Das gilt aber nur für die Forward Chain, nicht aber für die Input und Output Chain - die dafür verantwortlich sind, dass der Kernel auf dieser Netzwerkkarte die Verbindungen annimmt.

  • Wobei die beste Sicherheit ist, wenn gar nicht erst Ports geöffnet sind und somit gar nicht erst durch eine Firewall geschlossen werden müssen.

    Natürlich, aber per Default alles zu droppen oder rejecten ist halt ein weiteres Sicherheitsnetz, falls irgendwelche Ports ungeplant und unbemerkt dazu kommen.

  • Wobei die beste Sicherheit ist, wenn gar nicht erst Ports geöffnet sind und somit gar nicht erst durch eine Firewall geschlossen werden müssen.

    Joa, aber jeder Benutzer auf einem Linux Server kann einen Port ab Nummer 1024 öffnen. Schadware genauso.

    Dagegen hilft dann nur eine Firewall, die die Kommunikation nach außen / von außen auf diesen Ports verhindert.

  • Das ist allerdings richtig. Wobei man schon das erste Problem hat, wenn überhaupt jemand mit einem Benutzer einen Dienst starten kann. Soweit sollte möglichst schon gar nicht erst jemand kommen.

  • es sind nicht immer andere User dafür notwendig, dass unerwünschte Ports geöffnet werden. Hier mal ein falsches Script, da mal ne Software, deren Code man nicht Zeile für Zeile überprüft hat... also auf eine restriktive Firewall würde ich beim Server nie verzichten! Deny/Reject all, dann gezielt öffnen, ist kein großer Aufwand und macht einem das Serverleben einfacher sicherer.

  • Das meine ich ja. Wenn da außer mir noch jemand zugreifen kann, ist das erste Problem bereits da.

    Ein anderer guter Grund ist Software wie mongodb (zumindest vor ca. einem Jahr), die mit Standardpasswort oder ohne Passwort automatisch nach der Installation startet. Ohne Firewall wären solche Dienste für jeden Angreifer offen, bevor die Einstellungen geändert werden konnten.

  • mongodb (zumindest vor ca. einem Jahr), die mit Standardpasswort oder ohne Passwort automatisch nach der Installation startet.

    Nur auf dem Loopback Interface ;-)

    Der Admin muss die Bind Zeile in der Config ändern, damit das auftritt. Und wenn er dabei die Authorization Zeile vergisst, passiert das o.g. Problem.

  • Das ist allerdings richtig. Wobei man schon das erste Problem hat, wenn überhaupt jemand mit einem Benutzer einen Dienst starten kann. Soweit sollte möglichst schon gar nicht erst jemand kommen.

    Einen "Dienst" kann Grundsätzlich jeder starten, denn das ist im Prinzip nichts weiter als jedes beliebige Programm, das im Hintergrund läuft und einen Port öffnet. Dafür braucht es kein Init-Script. Mittels systemd kann man zwar timeouts festlegen, um Programme von nicht (mehr) eingeloggten Benutzern abzuschießen, aber das führt schnell zu anderen Problemen.