vHost als privater Tunnelbroker - DS-Light

[ChJEhDza]

Hallo zusammen,

ich hab leider neudings das Problem, dass mein Raspberry PI hinter einem IPv6 only bzw. DS-Lite steckt.

(Leider ist das mit den Glasanschluss, welchen ich gerade bekommen habe, keine öffentliche IPv4 mehr ermöglicht. Ich erhalte nur noch 100er IPv4)

Beim alten DSL-Anbieter konnte ich den PI noch quasi komplett ans Netz bringen.

Diesen Zustand möchte ich wiederherstellen. Dazu habe ich mir bereits einen vHost und echter IP mit Debian angemietet.

Auf diesem läuft Momentan bisher die Applikation 6tunnel welche die TCP-IPv4 Pakete an meinen IPv6 Host weiterleitet.

Das klappt aber recht gut, doch hat es den Nachteil, das auf dem PI alles nur noch von meiner eigenen fester IPv4 stammt.

Ich kann somit nicht mehr "böse" IPs blocken bzw. anschliessen.


Wie könnte ich quasi eine komplette IP-Brücke bauen, welche sämtliche Eingänge auf dem vHost an meinen PI weiterreicht, welche auch die richtigen Absender/Quell-IPs wieder mitbekommt?

[Tintom]

Verständnisfrage: Was hindert dich daran anstelle von IPv4 nun IPv6 auf dem Raspberry zu nutzen?

[ChJEhDza]

Verständnisfrage: Was hindert dich daran anstelle von IPv4 nun IPv6 auf dem Raspberry zu nutzen?

vier Gründe:

- alle Inkl. Server sind IPv4 only. Wo so einer Machine kommt man leider nicht auf eine IPv6 - Bitte das mit den Mitarbeitern dort klären
- deshalb holte ich mir bei einem an vRoot bei einem Berlin Anbieter. Hier bekommt man noch echtes IPv4 und IPv6 ***
- @Arbeit ist leider noch nicht IPv6 in den PfSensen aktiviert. Da "kämpfe" ich noch, dass das endlich mal aktiviert wird. Doch die Verwaltung von IPv6 ist deutlich schwerer durchzzubekommen, als gedacht.
- und Daheim gibts noch noch IPv6 via Glas.


Deshalb muss ich am *** einen Tunnel bauen

[schorsch_76]

Ich hab etwas ähnliches im EInsatz (allerdings nur für den MTA).

Ich würde eine IPsec (oder anderen) Tunnel zwischen dem Heimnetz und dem vhost aufbauen. Der Tunnel ist dann das Default Gateway deines Netzes. Von außen ist die v4 des vhost erreichbar und kann per DNAT auf den entsprechenden internen Server weitergeleitet werden.

Machen wir uns nichts vor: Eine private öffentliche IPv4 wird immer weniger die Norm werden. Nur noch große Anbieter haben große Pools um das ihren Kunden bieten zu können. Meine Kollegen haben auch Glasfaser im Haus von der Telekom. Soweit ich weis auch eine öffentliche IPv4. Vielleicht können die dir da noch eine öffentliche IPv4 bieten. Fragen kostet nicht viel ...

ALLERDINGS: Wenn der vhost dein Default Gateway ist, ist deine öffentliche IP immer die des vhosts.

[schorsch_76]

Ich denke das hier ist der Hintergrund ...

https://www.aipi.de/ipv4_adressen.html

[uname]

Ich würde mal meinen Internetprovider fragen, ob ich nicht (evtl. gegen Geld) eine IPv4 bekommen könnte. Dein genutztes Verfahren ist Mist.
Ich bin kein großer Tunnelbauer. Aber mal meine Idee nur mit SSH. Da findet man dann vielleicht auch schneller die Fehler.

a.) Pi baut SSH-Verbindung zum Internet-Server auf inkl. SSL Remote Port Forwarding
(etwa so: ssh -t -N -R 2222:localhost:22 user@Internet-Server, Server:localhost:2222 auf Pi:localhost:22)
b.) weltweiter Port Internet-Server auf Internet-Server:localhost:2222
(-> Server:all:443 auf Server:localhost:2222, leider weiß ich nicht, ob das irgendwie mit Local SSH Port Forwarding geht)

Weiß jemand mehr, wie man b.) konfiguriert? Ich habe gerade kein Testsystem.
Ich habe früher nur immer den Teil a.) genutzt.

[ChJEhDza]

Ich würde mal meinen Internetprovider fragen, ob ich nicht (evtl. gegen Geld) eine IPv4 bekommen könnte.

Das tat ich natürlich. Mehrer "Beraten" sagten mir, das gibt es nicht. Wir haben keine IPv4 Adressen.

Gut, der Glasanschluss läuft als "Normalo" super. Und der Preis ist auch TOP 1000/500 für knapp 80€. Pingzeiten nah der 14-16ms (was fast die gleichen Werte wie auf dem vHost sind). Aber leider kein echtes IPv4 :-/

Code: Alles auswählen

ping 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
64 bytes from 1.1.1.1: icmp_seq=1 ttl=59 time=15.9 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=59 time=15.5 ms
64 bytes from 1.1.1.1: icmp_seq=3 ttl=59 time=15.2 ms
64 bytes from 1.1.1.1: icmp_seq=4 ttl=59 time=15.6 ms
64 bytes from 1.1.1.1: icmp_seq=5 ttl=59 time=15.1 ms
64 bytes from 1.1.1.1: icmp_seq=6 ttl=59 time=14.7 ms
64 bytes from 1.1.1.1: icmp_seq=7 ttl=59 time=14.0 ms
64 bytes from 1.1.1.1: icmp_seq=8 ttl=59 time=14.6 ms

(Nur der Provider auf Arbeit, welcher 800€ im Monat kostet, schafft sogar (im Glücksfall) 9ms.)

Dann haben ich mit mehreren Provider kontakt aufgenommen: alle können da nichts machen. Den schwarzen Peter haben die aber unserer Bundesregierung zugeschoben, die sowas bei Neubauten leider zulassen.

Dann erfragte ich nach den Tunnelbroker. Doch niemand bietet sowas an.

Recheriere ich nach einem Tunnelbrokern, geht es immer nur um IPv4 zu IPv6 Tunnelbroker. Doch ich brauche ja genau das Gegenteil. Doch da gibt es nicht.

Dein genutztes Verfahren ist Mist.

Ich weiss, 6tunnel ist keine Dauerlösung. Den Tipp fand ich aber auch im talk.
Ein Übergang, aber keine Dauerlösung.

Ich bin kein großer Tunnelbauer. Aber mal meine Idee nur mit SSH. Da findet man dann vielleicht auch schneller die Fehler.

Ja das wäre effizenter. An so einer Lösung habe ich schon gedacht, doch dann fallen lassen - Grund: kann es kein UDP.
Wenn aber nichts anderes geht, werde ich es aber wohl so durchführen müssen. Doch ich glaube auch so wird die Quell-IP nicht übertragen.
Doch hier könnte man vielleicht vServer-Seitig evtl. besser loggen.

a.) Pi baut SSH-Verbindung zum Internet-Server auf inkl. SSL Remote Port Forwarding
(etwa so: ssh -t -N -R 2222:localhost:22 user@Internet-Server, Server:localhost:2222 auf Pi:localhost:22)
b.) weltweiter Port Internet-Server auf Internet-Server:localhost:2222
(-> Server:all:443 auf Server:localhost:2222, leider weiß ich nicht, ob das irgendwie mit Local SSH Port Forwarding geht)

Weiß jemand mehr, wie man b.) konfiguriert? Ich habe gerade kein Testsystem.
Ich habe früher nur immer den Teil a.) genutzt.

[Tintom]

Ja das wäre effizenter. An so einer Lösung habe ich schon gedacht, doch dann fallen lassen - Grund: kann es kein UDP.

Dem ssh-Tunnel ist es meines Wissens nach egal was du da wie für Daten durchschiebst. Hier baut einer etwas mit nc.

[MSfree]

Dem ssh-Tunnel ist es meines Wissens nach egal was du da wie für Daten durchschiebst.

SSH Port Forwarding funktioniert meines Wissens nur mit TCP. SSH kann allerdings auch als VPN genutzt werden, in dem man es an ein tun-Device bindet. Darüber ginge dann auch UDP. Auf die Uneffizienz, UDP-Pakete über eine TCP-Verbindung zu schicken, brauche ich wohl nicht hinzuweisen.

[uname]

Ich glaube es wurde noch nicht vorgeschlagen. Aber vielleicht kann man ja auch openVPN verwenden.

Im übrigen gibt es genug IPv4-Adressen. Wahrscheinlich wollen die Provider nur nicht, dass man das Rechenzentrum ins eigene Wohnzimmer stellt. Anwender sollen für Bandbreite bezahlen, die sie nach Möglichkeit nie nutzen. Viele Geräte unterstützen ja mittlerweile auch IPv6. Aber zuverlässig ist das natürlich nicht. Z. B. beim Zugriff über Firmennetzwerke (Proxy) wird meist nur IPv4 verwendet.

[Tintom]

Dem ssh-Tunnel ist es meines Wissens nach egal was du da wie für Daten durchschiebst.

SSH Port Forwarding funktioniert meines Wissens nur mit TCP.

Ich meinte innerhalb des Tunnels ist es ssh relativ egal was dort übertragen wird. Klar ist das ineffizient, aber die effizienten Lösungen wurden schon allesamt ausgeschlossen.

[uname]

Bei SSH gibt es auch die Option -w für tun:

Code: Alles auswählen

-w local_tun[:remote_tun]
    Requests tunnel device forwarding with the specified tun(4) devices between the client (local_tun) and the server (remote_tun).

    The devices may be specified by numerical ID or the keyword “any”, which uses the next available tunnel device. If remote_tun is not specified, it defaults to “any”. See also the Tunnel and TunnelDevice directives in ssh_config(5).

    If the Tunnel directive is unset, it will be set to the default tunnel mode, which is “point-to-point”. If a different Tunnel forwarding mode it desired, then it should be specified before -w.

Quelle: https://man.openbsd.org/ssh