Hallo Leute!
Ich bin derzeit mit meiner neuen Firewall beschäftigt... Ich habe deswegen einen BananaPI gekauft und bin dabei alles dort zu portieren. Es ist aber wirklich viel zu tun, denn aktuell ist mein PC "direkt" von Internet erreichbar (nur einige Ports und nur von einigen IPs, natürlich) und später wird der PC hinter den BananaPI stehen, muss aber weiterhin erreichbar sein.
Gut, was ich brauche ist eine Portweiterleitung, natürlich! Allerdings möchte ich die Quell-IP behalten, so dass ich zB in Apache sehen kann, wer die Anfrage schickt und nicht die IP des BananaPI...
Natürlich darf ich deswegen kein MASQUERADE nutzen, denn sein Zweck ist genau die Adressen zu maskieren.
Ich habe ein paar Tests gemacht und folgendes bringt die Pakete zum Ziel:
- 1.2.3.4 ist die IP des Rechners, der eine SSH-Verbindung starten darf - 192.168.10.2 ist die IP meines Rechners - 2.3.4.5 ist die öffentliche IP des Routers (also die IP der PPP-Schnittstelle)
/sbin/iptables -A FORWARD -p tcp --dport 22 -j ACCEPT /sbin/iptables -t nat -A PREROUTING -p tcp -s 1.2.3.4 --dport 22022 -j DNAT --to-destination 192.168.10.2:22 /sbin/iptables -t nat -A POSTROUTING -s 192.168.10.2 -o dsl0 -j SNAT --to-source 2.3.4.5
Das Problem ist, dass ich in der SNAT die IP der PPP-Schnittstelle angeben muss, und diese ändert sich... Schon gut, ich konnte ein Skript basteln, das beim Starten der PPP-Verbindung die Regel umschreibt, aber wenn eine bessere Lösung gäbe, wäre es mir lieber...
Nun die Frage: gibt es eine bessere (= einfachere) Lösung?
Besten Dank Luca Bertoncello (lucabert@lucabert.de)
Luca Bertoncello lucabert@lucabert.de (Mo 29 Jan 2018 09:07:04 CET): …
Das Problem ist, dass ich in der SNAT die IP der PPP-Schnittstelle angeben muss, und diese ändert sich... Schon gut, ich konnte ein Skript basteln, das beim Starten der PPP-Verbindung die Regel umschreibt, aber wenn eine bessere Lösung gäbe, wäre es mir lieber...
Du suchst -j MASQUERADE
Zitat von Heiko Schlittermann hs@schlittermann.de:
Hallo Heiko,
Du suchst -j MASQUERADE
Eben nicht, denn damit kann ich am Ziel-Rechner nur die IP der Firewall sehen, und nicht die IP des Rechners, der die Anfrage schickt, was aber genau bei Ziel ist...
Um klar zu sagen (Beispiel):
- 1.2.3.4 ist die IP des Rechners, der eine SSH-Verbindung starten darf - 192.168.10.1 ist die IP der Firewall - 192.168.10.2 ist die IP meines Rechners - 2.3.4.5 ist die öffentliche IP des Routers (also die IP der PPP-Schnittstelle)
Wenn 1.2.3.4 eine SSH-Verbindung zum 2.3.4.5:22022 startet, am Rechner 192.168.10.2 will ich sehen, dass die Anfrage vom 1.2.3.4 kommt und nicht von 192.168.10.1.
Habe ich mein Problem erklärt?
Grüße Luca Bertoncello (lucabert@lucabert.de)
Luca Bertoncello lucabert@lucabert.de (Mo 29 Jan 2018 09:18:54 CET): …
Eben nicht, denn damit kann ich am Ziel-Rechner nur die IP der Firewall sehen, und nicht die IP des Rechners, der die Anfrage schickt, was aber genau bei Ziel ist...
Gut, dann habe ich zu schnell gelesen. Sorry. Also ziehe ich meine Antwort zurück. Und lese Deine Frage noch mal.
Am Montag, 29. Januar 2018, 09:18:54 CET schrieb Luca Bertoncello:
Zitat von Heiko Schlittermann hs@schlittermann.de:
Hallo Heiko,
Du suchst -j MASQUERADE
Eben nicht, denn damit kann ich am Ziel-Rechner nur die IP der Firewall sehen, und nicht die IP des Rechners, der die Anfrage schickt, was aber genau bei Ziel ist...
Um klar zu sagen (Beispiel):
- 1.2.3.4 ist die IP des Rechners, der eine SSH-Verbindung starten darf
- 192.168.10.1 ist die IP der Firewall
- 192.168.10.2 ist die IP meines Rechners
- 2.3.4.5 ist die öffentliche IP des Routers (also die IP der
PPP-Schnittstelle)
Wenn 1.2.3.4 eine SSH-Verbindung zum 2.3.4.5:22022 startet, am Rechner 192.168.10.2 will ich sehen, dass die Anfrage vom 1.2.3.4 kommt und nicht von 192.168.10.1.
Habe ich mein Problem erklärt?
Grüße Luca Bertoncello (lucabert@lucabert.de)
Hallo Luca,
ich denke, dass sich Dein Problem im IPV4-Space nicht lösen läßt. Stichwort: Netmask der jeweiligen Interfaces > 0.0.0.0 . Dafür sollte man "globales" IPv6 haben und nutzen (können).
Ich finde es auch ein wenig widersinnig, sich bei ssh von festen IP(V4!)-Adressen abhängig zu machen. Schlüssel (keine Passwörter) innerhalb ssh sollten das Mittel der Authentifizierung sein. Wenn das erfolgreich ist, wozu soll dann noch Kenntnis der Partner-IP wichtig sein? (Und eine iptables-Regel, die die ssh-Penetration-Tests diverser Script-Kiddies gehörig limitiert, ist einfach zu erstellen.)
Viele Grüße! Bernhard
Bernhard Schiffner bernhard.schiffner@gmx.net schrieb:
Hallo
ich denke, dass sich Dein Problem im IPV4-Space nicht lösen läßt. Stichwort: Netmask der jeweiligen Interfaces > 0.0.0.0 . Dafür sollte man "globales" IPv6 haben und nutzen (können).
Ich finde es auch ein wenig widersinnig, sich bei ssh von festen IP(V4!)-Adressen abhängig zu machen. Schlüssel (keine Passwörter) innerhalb ssh sollten das Mittel der Authentifizierung sein. Wenn das erfolgreich ist, wozu soll dann noch Kenntnis der Partner-IP wichtig sein? (Und eine iptables-Regel, die die ssh-Penetration-Tests diverser Script-Kiddies gehörig limitiert, ist einfach zu erstellen.)
SSH ist nur __EIN__ Teil der Geschichte... Hier könnte ich problemlos auf die externe IP verzichten, aber für HTTP/HTTPs sicher nicht. Da will ich auf alle Fälle wissen, wer die Seite abruft...
Ich habe ein paar Experimente mit SNAT gemacht und scheint nicht zu schlecht zu funktionieren, muss aber weiter experimentieren.
Grüße Luca Bertoncello (lucabert@lucabert.de)
...
Ich habe ein paar Experimente mit SNAT gemacht und scheint nicht zu schlecht zu funktionieren, muss aber weiter experimentieren.
Grüße Luca Bertoncello (lucabert@lucabert.de)
Ganz anderer Gedanke: Kann man dazu nicht (selbst) IPV4 in IPV6 "einbringen"? Etwa so: externe IPV4 kontaktiert Dein Gateway, dieses "SNATed" in eine [globale|lokale] IPv6:\64+(0x00000000+IPV4), die geht dann über das lokale Netz an ssh, apache & Co. und dort steht dann die IPV4-Ursprungsadresse für weitere Verwendung zur Verfügung ...
Bernhard
Bernhard Schiffner bernhard.schiffner@gmx.net schrieb:
Kann man dazu nicht (selbst) IPV4 in IPV6 "einbringen"? Etwa so: externe IPV4 kontaktiert Dein Gateway, dieses "SNATed" in eine [globale|lokale] IPv6:\64+(0x00000000+IPV4), die geht dann über das lokale Netz an ssh, apache & Co. und dort steht dann die IPV4-Ursprungsadresse für weitere Verwendung zur Verfügung ...
1) Ich weiß nicht wirklich, wie ich das machen könnte... 2) Da die Telekom mir eine ___DYNAMISCHE__ /64-Netz vergibt, würde das bedeuten, dass jedes Mal dass die DSL-Leitung unterbrochen wird, muss die Firewall "neu gebaut werden".
Grüße Luca Bertoncello (lucabert@lucabert.de)
Am Montag, 29. Januar 2018, 20:37:30 CET schrieb Luca Bertoncello:
Bernhard Schiffner bernhard.schiffner@gmx.net schrieb:
Kann man dazu nicht (selbst) IPV4 in IPV6 "einbringen"? Etwa so: externe IPV4 kontaktiert Dein Gateway, dieses "SNATed" in eine [globale|lokale] IPv6:\64+(0x00000000+IPV4), die geht dann über das lokale Netz an ssh, apache & Co. und dort steht dann die IPV4-Ursprungsadresse für weitere Verwendung zur Verfügung ...
- Ich weiß nicht wirklich, wie ich das machen könnte...
- Da die Telekom mir eine ___DYNAMISCHE__ /64-Netz vergibt, würde das
bedeuten, dass jedes Mal dass die DSL-Leitung unterbrochen wird, muss die Firewall "neu gebaut werden".
Grüße Luca Bertoncello (lucabert@lucabert.de)
http://linux-hacks.blogspot.it/2008/02/howto-ipv6-ipv6-tunnel-and-ip4-ipv6.h... (Siehe 2. Hälfte dort. Das ist also keine neue Fragestellung)
Das "Problem" für die Interfaces bei IPV6 ist, dass sie meistens mehrere IP-Adressen haben. Eine ist die lokale, eine andere ist die oben dynamisch zugewiesene, eine weitere z.B. die statisch für den Tunnel zugewiesene usw. Damit sind sind wir bei der konkreten Implementierung, und ich habe sowas noch nie gemacht. (Konrad fragen?)
Bernhard
On Mon, January 29, 2018 21:17, Bernhard Schiffner wrote:
http://linux-hacks.blogspot.it/2008/02/howto-ipv6-ipv6-tunnel-and-ip4-ipv6.h... (Siehe 2. Hälfte dort. Das ist also keine neue Fragestellung)
Wenn es irgendwie geht will man Tunnel eigentlich vermeiden.
Man will auch IPv4 und IPv6 separat verwalten. Das Vermischen der beiden verursacht nur unnötig Kopfweh.
Jedes Problem was man versuchen könnte mit NAT(*), Protokoll-Übersetzungen oder lokalen Tunneln zu lösen hat wahrscheinlich elegantere und bessere Lösungen.
(*) Merke: der Fakt dass Millionen Fliegen Sch***e fressen ist kein guter Indikator dafür dass es ein empfehlenswertes Lebensmittel ist. :-P
Das "Problem" für die Interfaces bei IPV6 ist, dass sie meistens mehrere IP-Adressen haben. Eine ist die lokale, eine andere ist die oben dynamisch zugewiesene, eine weitere z.B. die statisch für den Tunnel zugewiesene usw.
Du hast mindestens eine (fe80::/64), die aber nur auf dem jeweiligen Kabel nutzbar ist (Link-Local). Die wird eigentlich nur für automatisch ablaufende streng lokale Prozesse benutzt (SLAAC, DHCP, mDNS).
Damit Du ordentlich arbeiten kannst muss mindestens eine weitere zugewiesen werden:
a) ULA (Unique Local Address) aus dem Bereich fd00::/8 - das ist das Äquivalent von 192.168.*.*/16. Es gibt aber keine standardisierte Variante die öffentlich zu routen (zum Glück!). Sie sind nur dazu da innerhalb einer Organisation stabile Adressen zu haben auch wenn der Provider neue zuweist.
b) Öffentliche Adressen vom Provider oder per eigenem AS.
Die meisten Organisationen mit IPv6 intern sollten beides haben.
Wenn Du mit einem anderen Rechner kommunizierst ist Deine Absender-Adresse diejenige mit dem längsten gemeinsamen Prefix - das Interface dieser Adresse bekommt (bei normalem Routing) auch den Traffic.
Damit sind sind wir bei der konkreten Implementierung, und ich habe sowas noch nie gemacht. (Konrad fragen?)
Wie gesagt: NAT, Protocol-Translation, Tunnelchen und andere Schweinereien dieser Art will man vermeiden, wegen Kopfschmerzgefahr und wegen der Halsschmerzen, die die unausweichlichen Schreianfälle verursachen werden... ;-)
Konrad
Hi,
On Mon, January 29, 2018 19:16, Luca Bertoncello wrote:
SSH ist nur __EIN__ Teil der Geschichte... Hier könnte ich problemlos auf die externe IP verzichten, aber für HTTP/HTTPs sicher nicht. Da will ich auf alle Fälle wissen, wer die Seite abruft...
Mal aus Security-Sicht gesprochen: IP Adressen sind kein Authentifikationsmerkmal, weil fälschbar. Punkt. Aus. Ende der Diskussion.
SSH: arbeite mit Keys, keine Passwortauth. Passwortauth ist böse!
HTTP: nur für öffentliche Informationen, die jeder wissen darf. Kein Schreibzugriff. HTTP im Intranet kann man gerade noch erlauben wenn es aus irgendwelchen Gründen keine andere Möglichkeit gibt.
HTTPS: Client-Zertifikate, sichere Passworte und/oder Token (OTP oder U2F). Je nach Paranoia-Level.
Konrad
lug-dd@mailman.schlittermann.de
-
Bernhard Schiffner -
Heiko Schlittermann -
Konrad Rosenbaum -
Luca Bertoncello