offizielle IPs durch einen IPoIP Tunnel routen

[ViennaAustria]

Hallo!

Ich habe zuhause einen Breitbandanschluss mit einer IP Adresse - wie vermutlich viele von Euch. Da mein Provider jedoch ein paar Ports blockt (Kabelanschluss: daher keine Windows-Dateiverbindungen von/nach Aussen und auch kein SNMP), mir jedoch anderswo ausreichend offizielle IP Adressen zur Verfügung stehen, kam ich auf die Idee, mir einfach einen 16er Block offizieller IP Adressen in mein LAN zu tunneln, anstatt wie zuvor mit privaten IP Adressen 192.168.x.y und NAT zu arbeiten.

Das funktioniert sehr gut, mit einer einzigen Ausnahme. Und das bekomm' ich über iproute2/iptables einfach nicht hin!

Mein Netz auf der Linux Firewall sieht so aus:

eth0: WAN/Internet mit einer offiziellen IP vom Provider
eth1: LAN mit "meinen" offiziellen IP Adressen a.b.c.0/28
tunl1: Tunnel zu einem Gegenüber im Internet, das die a.b.c.0/28 Adressen hin-geroutet bekommt

Ich baue den Tunnel mit 192.168.123.x Adressen für die beiden Tunnel-Endpunkte auf

auf meiner Seite:
iptunnel add tunl1 mode ipip local 192.168.123.2 remote 192.168.123.1
ifconfig tunl1 192.168.123.2 pointopoint 192.168.123.1 up

auf der anderen Seite:
iptunnel add tunl1 mode ipip local 192.168.123.1 remote 192.168.123.2
ifconfig tunl1 192.168.123.1 pointopoint 192.168.123.2 up

und schicke den gesamten Traffic vom LAN mittels

auf meiner Seite:
ip rule add from a.b.c.0/28 table tunnel
ip route add to a.b.c.0/28 dev eth1 table tunnel
ip route add default via 192.168.123.1 src a.b.c.1 table tunnel
ip route flush cache

auf der anderen Seite:
ip route add a.b.c.0/28 via 192.168.123.2

durch den Tunnel. Wie schon gesagt funktioniert das perfekt - aber nur für meine Clients am LAN (also die IP Adressen a.b.c.2 bis a.b.c.14) und nicht für die Firewall selbst (a.b.c.1). Nachdem ich mittlerweile nur mehr mit meinem Linux Rechner arbeite und im LAN nur mehr andere Gadgets habe, möchte ich auch von der Firewall mit "meiner" offiziellen IP a.b.c.1 rausgehen und nicht mit der vom Provider.

Wie konfigurier' ich das?

Da die Default-Route ja zum Gateway meines Providers zeigt (und nicht in den Tunnel), gehen auch alle Pakete von der Firewall mit meiner Provider-IP raus und nicht mit der LAN IP a.b.c.1 durch den Tunnel.

Klar, dass ich den Traffic zu meine Tunnel-Ende nicht maskieren darf, sonst würde der Tunnel durch den Tunnel gehen wollen und das klappt nicht mal bei einer Klein'schen Flasche... Dafür hab ich aber schon Lösungen mit einer fixen Rute und/oder entsprechenden Einträgen in `iptables´ für's Tunnelende mit ACCEPT. Also daran habe ich bei meinen Experimenten gedacht.

Aber an welcher Stelle kann ich den restlichen Traffic von meiner Firewall weg überhaupt beeinflussen? Das sind ja wohl nur die OUTPUT Tables, in denen ich aber kein SNAT machen kann, um die Provider-IP in meine a.b.c.1 IP umzuwandeln. Und in der POSTROTING Table, wo ich die Source IP ändern könnte, bin ich ja bereits "hinter" der Routing-Entscheidung, dass die Pakete über eth0 an den Gateway meines Providers gehen und nicht durch den Tunnel zu meinem Gateway (eben post Routing).

Ich muss also

1. die Source-IP von der meines Providers auf a.b.c.1 ändern, sowie
2. das Routingziel vom Gateway meines Providers auf den Tunnelendpunkt 192.168.123.1 umdrehen

Ich seh mich nicht durch.


Alternativ hatte ich anfangs einen IPsec Tunnel mit FreeS/WAN aufgebaut. Das ging ganz gut und hat auch implizit mein Problem gelöst, weil sich IPsec komplett über die Default-Route setzt und auch die Pakete von meiner Firewall ins Internet mit meiner IP a.b.c.1 weg-gingen. Blöd war nur, dass der Tunnel so etwa einmal am Tag ohne erkenntlichen Grund "weg" war und sich erst nach unzähligen `rcipsec restart´ wieder aufbauen liess. Das war natürlich enervierend...

Der IPoIP Tunnel ist dagegen total stabil - nur die eigene IP vom Provider kann ich nicht auf meine um-mappen.

Bin für jeden Hinweis dankbar!

Thomas

[geronet]

Was ist wenn du zum senden ein SNAT auf deine echte IP-Adresse machst, die Pakete vom Server werden dann wieder zurück zum echten Subnet gesendet, über den Tunnel übertragen und schon sind sie wieder da?
Bin mir nicht ganz sicher ob das jetzt so funktioniert, aber ausprobieren kann man's ja mal

[ViennaAustria]

Hallo!

Was ist wenn du zum senden ein SNAT auf deine echte IP-Adresse machst, die Pakete vom Server werden dann wieder zurück zum echten Subnet gesendet, über den Tunnel übertragen und schon sind sie wieder da?

Das hatte ich ziemlich am Anfang probiert. Leider ging das nicht. Als ich mir die Ablaufdiagramme der Pakete durch Netfilter und Router angesehen habe (http://www.netfilter.org/documentati...O-3.html#ss3.2), wurde mir auch klar, warum:

SNAT kann ich nur in der POSTROUTING Chain machen, also nachdem die Routing-Entscheidung bereits getroffen wurde. D.h., die Pakete gehen dann zwar mit der richtigen IP raus, aber am falschen Interface - nämlich zum Gateway meines Providers! Der wird diese Pakete vermutlich einfach droppen.

Das hatte ich oben schon geschrieben - anscheinend aber nicht verständlich genug.

Also SNAT ist wohl nötig, aber nicht alleine. Vorher muss ich dem Router noch irgendwie sagen, dass er das Interface vom Tunnel verwenden soll und nicht den normalen Weg gehen soll und die Pakete zum Provider schickt.

Mir stinkt, dass ich das irgendwie mit Mangeling im OUTPUT und einem Tag machen muss, der dann im iproute2 und POSTROUTING ausgewertet wird - aber ich schnall einfach nicht, wie. Für Routing-Experten ist die Antwort vermutlich super-simpel...

Thomas