Interesse an statischen öffentlichen IP Adressen ?

NiclasM

NiclasM

Enthusiast
Thread Starter
Mitglied seit
06.02.2007
Beiträge
4.331
Ort
Dortmund
Hallo Zusammen,

Ich habe lange Zeit daran gearbeitet wie ich zu Hause eine Öffentliche Adresse oder mehrere bekommen kann, ohne dafür viel zu Zahlen. Nach einigen Cisco Kursen und Zertifizierungen habe ich dann jetzt ein gutes Konstrukt aufgebaut. Meine Frage an euch, hättet Ihr Interesse öffentliche Adressen zu mieten, und per VPN einfach nutzen zu können?

Oder nutzt Ihr bereits einen Dienst dafür, wenn ja wie viel Zahlt Ihr etwa dafür?

Grüße
 
Zuletzt bearbeitet:
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Mir ist kein Festnetz Anbieter bekannt der dem Kunden keine oeffentliche IP-Adresse bereitstellt. Bei manchen mag es eventuell nur oeffentliche IPv6 Adressen geben aber du hast ja eine recht breite Aussage getroffen.

Warum sollte ich meinen gesamten internet Traffic ueber dein VPN leiten?
Was macht dich besser als all die anderen VPN anbieter?

Warum sollte Ich mir nicht einfach einen kleinen VServer mieten und selber einen VPN Server oder was auch immer einrichten?
 
Bei VServern bekommet du oft nur eine IP, und musst SNAT und DNAT einsetzen. Wenn der VServer mehrere Adressen unterstützt müssen diese als Interface eingetragen sein, sonst landen die Frames nicht bei dir.

Ob durch das VPN oder nicht, ist vom Datenschutz her total irrelevant. Denn ich spiele in dem Szenario auch nur ISP und leite die Pakete weiter zu meinem Peering Partner. So oder so durchläuft dein Traffic zich Instanzen von Anbietern.

Bei Unitymedia benötigt man einen Business Anschluss und etwa 10€ für die Adresse zusätzlich. Bei anderen Anbietern bin ich ähnliches gewohnt, und das finde ich zu meist ziemlich teuer.

Achja, um das noch mal zu konkretisieren, ich meine Statische Öffentliche Adressen oder Blöcke...!
 
Und woher hast du nen entsprechenden Addressblock bekommen?

Mal davon abgesehen gibts ja auch noch weitere Einschränkungen, bei Unitymedia z.B. wird mit DS-Lite gearbeitet und das CGN verhindert eine stabile VPN von meinem Anschluss aus zu einem IPv4 VPN-Knoten.

Mit IPv6 braucht aber kein Mensch mehr einen mietbaren VPN-Endpunkt, schließlich hat dann ja jeder eine dauernd aktive, öffentliche Adresse...

Sorry ich seh hier aber den Sinn nicht?

Edit:

Wenn du eine oder mehrere öffentliche IPv4 Adressen haben willst, miet dir die einfach beim Provider.
 
Zuletzt bearbeitet:
Bei IPv6 wechselt dein /56 Block auch alle x Tage. Also macht auch kein Sinn.

Ja es ist möglich mir für 40€ im Monat mir mein Provider 5 IPs zu mieten. Aber kommt es nur mir so vor oder ist das teuer?

Was ich Preislich angemessen fände wäre 1-2 EUR pro IP pro Monat.

Ist nicht so dass ich das jetzt anbieten wollte, eher ne Interessenfrage...
 
Zuletzt bearbeitet:
Wieso wechselt der Block denn bei IPv6? Vorgesehen ist das so nicht, einige Provider tun das zwar aber lange nicht alle. Das Thema Datenschutz zumindest wird ja eh über die Privacy Extensions realisiert/implementiert.

5 IPs für 40€? Klingt ganz fair, wie du dann aber 1-2 € pro IP/Monat kalkuliert hast versteh ich nicht ;)
 
l0n schrieb:
Das Thema Datenschutz zumindest wird ja eh über die Privacy Extensions realisiert/implementiert.
Zum Vergrößern anklicken....

Um nicht wiedererkennbar zu sein, müssen beide Adressteile regelmäßig gewechselt werden, die Privacy Extensions alleine reichen nicht aus.
 
NiclasM: dafür braucht man kein Cisco. Ich mache das mit einer Firewall auf einem vServer. Jede weitere IP Adresse $1 pro Monat (aber wozu mehr als 1). Das wirst du vermutlich ähnlich regeln.
 
Ich habe das eher darauf bezogen, dass ich mich mit Routing stärker beschäftigt habe. Ich habe halt mehr als ein dienst den ich auf TCP/443 laufen lassen möchte.
Ich mach das Routing auch komplett mit Linux, also ohne Cisco :wink:.

Ich habe bei OVH einen EG-16 Server, auf den ich einen /24er Block maximal bekommen kann. Früher habe ich das auch mit VServern gemacht, jedoch ist es in der neuen VPS Reihe nicht mehr möglich, die Frames auf Layer 2 Ebene, die an die zusätzlichen Adressen gehen zu erhalten. Nur wenn die IP dem VPS zugewiesen ist, kommt der Traffic an. Deshalb bin ich zu dem Server gewechselt.

Ich habe dann über Quagga und OSPF v2 den Block oder einzelne Adressen über meine VPN Topology geroutet. Jeder Router auf dem Rückweg zum OVH Server, habe ich über iptables eine zweite Routing Tabelle erstellt, mit der Default Route zurück zum OVH Server über die jeweiligen Next Hops.

Am letzten Router, der als Gateway für den Standort fungiert, habe ich in Zebra eine statische Route gesetzt auf das Interface wo die IP genutzt werden soll.

Hoffe ist verständlich einigermaßen. Bin jetzt damit sehr zufrieden, weil ich keine öffentliche Adresse für das Interne weiterleiten benötige. Das VPN ist über OpenVPN Redundant aufgebaut mit ECMP Multipath.
Die Gateway Router in den jeweiligen Standorten sind per VRRP als FHRP ausgestattet.

Ich möchte jedoch bald auf Bird wechseln, da das Exportieren der Routen, inkls. der Rückrouten automatisch geht. Quagga kann das leider nicht.
Zuguter letzt habe ich natürlich IP Routing Rules verwendet, um den Traffic von der öffentlichen Adresse über die zusätzliche Routing Tabelle zu leiten.
 
Mit der Sophos UTM lässt sich das ziemlich einfach & komfortabel abbilden.
Wozu hast du OSPF eim Einsatz? redundantes ECMP Multipath für die VPN Tunnel brauchst du für größere Firmen die auch redundante Internet Leitungen haben. Für Homeuser alles relativ uninteressant.

l0n: Mit der Sophos UTM kannst du per IPsec & IPv6 einen Tunnel aufbauen und dir dadurch eine IPv4 wieder "reinholen". Leider geht das nur für Site2Site nicht für RED Verbindungen (Falls du dich schon mal damit beschäftigt hattest)
 
OSPF um alle Subnetze automatisch zu Routern... :hmm:
Ich habe nicht nur mein Netzwerk hier zu Hause.

Zudem OSPF weil es mir das Routing vereinfacht, und ich nicht alles von Hand eintragen muss. Redundantes ECMP Multipath - für größere Firmen ja, aber ich - weil ich's kann.

Welche Funktion ist das aus der Sophos?
Also kannst du deiner Sophos zu Hause auf einem Interface eine Statische IPv4 Adresse zuweisen, die bei deiner (z.B.) Sophos in der Cloud anliegt?
 
letztendlich ist es NAT was über die Sophos läuft. Direkt die IPv4 auf das Interface legen kann ich (so) nicht.
Das du das OSPF für für andere Subnetze verwendest hattest du nicht erwähnt, daher interessierte es mich wozu das hier nötig war.

Letztendlich wäre jetzt noch interessant ob die IP die du zuhause am Router hast komplett durchgeroutet wird (inkl. aller Protokolle wie z.B. 'protocol 41' oder ein NAT stattfindet. Wobei ich meine rausgelesen zu haben, dass wohl spezielle Routerhardware notwendig ist?

Mach doch eine Anleitung, interessant ist sowas immer, gerade wenn mehr CGN Anschlüsse ohne IPv4 Funktion aus dem Boden schießen.
 
Puh. Eine Anleitung kann ich gerne machen.

Spezielle Routerhardware ist nicht nötig. Ich mache alles mit Linux.

Das schöne ist, aus meiner Sicht auch das perfekte Setup, dass die IP zu Hause, bzw. egal wo komplett durchgereicht wird. Als Router nutze ich dann teilweise auch Sophos UTM. Deshalb war es mir so wichtig KEIN NAT zu nutzen. Ich benötige den kompletten Header und versuche halt immer meine Lösungen so günstig wie möglich aufzubauen, und dennoch das ganze Professionel zu halten was die Protokolle angeht. Wenn man zu Hause eine Statische Adresse hätte, wäre ein einfacher GRE Tunnel noch schöner / einfacher aber naja. Da tut sich nicht viel.

Ich mache mal gleich ein Schema, um genau aufzuzeigen wie ich das mache.


Edit:
Bin mit IPSec nicht so total vertraut, habe über die Sophos den L2TP IPSec Remote Access mit meinem iPhone gerade getestet. Dort keine Probleme.
 
Zuletzt bearbeitet:
Einen Fehler hat dein Vorhaben:

Was nützt Dir ein /24er Subnet ohne 10G Verbindung?

Da können die Clients zur Hauptzeit aber erstmal die Kaffeemaschine anwerfen, vor Allem weil die betroffenen ipv6 Kunden zu 95% Kabelkunden mit dicken Leitungskapazitäten jenseits der 30 mbit sein werden.
Die 500mbit/s kriegst du im Extremfall mit 3 Clients ausgelastet.

Die einzige Alternative wäre es den Server nicht als default Gateway zu pushen, aber dann kriegt jeder mäßig erfahrene Kunde die Krise beim Routing.

Zumindest wenn der Tunnel nicht direkt vom Endgerät hergestellt wird.
 
Zuletzt bearbeitet:
Ich habe es so Konfiguriert, dass nicht alle Anfragen über die Öffentliche Adresse laufen. Ich differenziere, zwischen langweiligem User Traffic, und Server Traffic, bzw. den Sachen die auch genattet werden sollen.

D.h. Clients laufen am Router an, und gehen über die Standardleistung, Cable, VDSL. Anfragen die an den Terminal Server oder Exchange OWA gehen, laufen über das VPN Routing. Somit schon mal einiges gespart. Zudem nicht jeder eine Französische IP haben möchte, da Google etc. versuchen dir immer die Französische Seite unterzujubeln. In meinem Fall ist OVH halt ein Französisches BGP AS, und der RIPE Block ist halt auf die Registriert.

Selbst wenn - falls man das Kommerziell anbieten wollen würde (was ich aktuell nicht Plane), kannst du gegen das Entsprechende Kleingeld auch 10 Gbps bekommen. Ich habe aktuell 1 Gbps (OVH <-- Internet) und 500 Mbps (Burst 1 Gbps) (OVH --> Internet).
 
Zuletzt bearbeitet:
Ich habe es so Konfiguriert, dass nicht alle Anfragen über die Öffentliche Adresse laufen. Ich differenziere, zwischen langweiligem User Traffic, und Server Traffic, bzw. den Sachen die auch genattet werden sollen.
Zum Vergrößern anklicken....
Interessant, aber wie willst du serverseitig dem Client seine Routingtabellen nach Protokollen sortiert pushen?
Gut bei openvpn Verbindungen z.B. geht das, aber meines Wissens auch nur nach Zieladressen und nicht nach Protokollen.

(Das soll nicht heißen, dass es nicht geht. Mir fällt aber auf Anhieb kein Weg ein wie sowas funktionieren sollte)

Zudem finde ich sollte jeder Client selbst die Möglichkeit haben sein Routing zu festzulegen. Dafür bräuchte es ein Webif mit direktem Zugriff auf die NAT Einstellungen der eigenen IP.
Nicht ganz einfach sowas zu implementieren, zumindest nicht wenn es sicher sein soll.

Selbst wenn - falls man das Kommerziell anbieten wollen würde (was ich aktuell nicht Plane), kannst du gegen das Entsprechende Kleingeld auch 10 Gbps bekommen.
Zum Vergrößern anklicken....
Ja das geht ab 250 Euro aufwärts im Monat.

Alleine um die Serverkosten zu stemmen bräuchtest du 50 dauerhafte Interessenten, denen sowas 5 Euro im Monat wert wäre. (Und bei der Summe würde ich lieber gleich 10 Euro für eine native ipv4 beim ISP zahlen)
 
Zuletzt bearbeitet:
mal von dem ganzen 10G und /24 IP Netz abgesehen (das braucht kein Heim User zuhause) würde es mich dann trotzdem interessieren, wie du es ohne NAT über VPN direkt durchreichst.
Hast du dann an der Linux Maschine ein zusätzliches Interface wo dann wieder die Firewall drankommt und dort die öffentliche IP bekommt?
 
hab das mit der öffentlichen IP Adresse über Sophos & RED mal per Bride getestet. Das funktioniert soweit super, allerdings scheint z.B. IP Protocol 41 nicht durchgereicht zu werden (schade eigentlich).

Zumindest kommt so eine externe IPv4 die am WAN port meiner vServer Sophos "hängt" direkt auf ein (virtuelles) Interface meiner Sophos an. Kein NAT notwendig ist auch chik.
 
Tr4c3rt: nein, ohne NAT. Wie gesagt, Interface gebridged und die zusätzliche IP Adresse auf dem Red Interface der Sophos daheim gelegt. D.h. ich sehe auch - direkt - von welcher IP Adresse die Anfragen herkommen ;) Bei NAT würde ma ja nur die IP der Sophos auf dem vServer sehen.
 
Ist bei zusätzlichen Adressen auch der sinnvollste Weg.
Schade, dass man Sophos keinen Vollzugriff auf die virtuellen Devices hat.
So kann man keine tun/tap Devices brücken und ist quasi gezwungen an der Zieladresse auch wieder eine UTM zu platzieren.

Ohne RED geht das ja nicht :-(

Ich bin mal gespannt was Niclas zum Routing sagt...
 
es geht auch ohne RED mit OpenVPN und dann die interfaces bridgen. Aber habe ich noch nicht gemacht, sollte aber auch nicht zu schwer sein.
 
Da eine Anleitung vorerst zu lange dauern würde, das ganze in Kurzformat.


Folgende Konfiguration auf meinem Server im RZ.
Kernel Optionen:
Code: 
root@public-pop01:~# sysctl -p
net.ipv4.conf.default.rp_filter = 0
net.ipv4.conf.all.rp_filter = 0
net.ipv4.ip_forward = 1

Routing Tabelle auf dem Server (srv-pop01)

Code: 
[...]
51.254.189.32/28  proto zebra  metric 20
        nexthop via 10.255.244.16  dev tun-s2s-vpn05 weight 1
        nexthop via 10.255.242.16  dev tun-s2s-vpn03 weight 1
        nexthop via 10.255.240.16  dev tun-s2s-vpn01 weight 1
        nexthop via 10.255.241.16  dev tun-s2s-vpn02 weight 1
        nexthop via 10.255.243.16  dev tun-s2s-vpn04 weight 1
[...]


Routing Eintrag auf dem private-pop01 (Linux VM zu Hause):

Code: 
[...]
ip route 51.0.0.203/32 eth1
ip route 51.0.0.32/28 eth1
[...]


Über iproute2 habe ich eine weitere Routing Tabelle definiert auf dme private-pop01.
Code: 
root@private-pop01-gw01:~# cat /etc/iproute2/rt_tables
#
# reserved values
#
255     local
254     main
253     default
0       unspec
#
# local
#
#1      inr.ruhep
1 public-pop01

In der Routing Tabelle 1 finden sich folgende Eintragungen.

Code: 
root@private-pop01-gw01:~# ip route show table 1
default
        nexthop via 10.255.240.18  dev tun-s2s-vpn01 weight 1
        nexthop via 10.255.241.18  dev tun-s2s-vpn02 weight 1
        nexthop via 10.255.242.18  dev tun-s2s-vpn03 weight 1
        nexthop via 10.255.243.18  dev tun-s2s-vpn04 weight 1
        nexthop via 10.255.244.18  dev tun-s2s-vpn05 weight 1


Nachdem die VPN Verbindung aufgebaut ist, wird per Multipath das default Gateway innerhalb der zweiten Routing Tabelle definiert.

Code: 
#!/bin/sh
ip route add default table 1 \
nexthop via 10.255.240.18 dev tun-s2s-vpn01 weight 1 \
nexthop via 10.255.241.18 dev tun-s2s-vpn02 weight 1 \
nexthop via 10.255.242.18 dev tun-s2s-vpn03 weight 1 \
nexthop via 10.255.243.18 dev tun-s2s-vpn04 weight 1 \
nexthop via 10.255.244.18 dev tun-s2s-vpn05 weight 1

Zu guter letzt wird über die IP Rules definiert, dass Verbindungen von den öffentlichen Adressen über die zusätzliche Routing Tabelle laufen soll.

Code: 
[...]
ip rule add from 51.0.0.203/32 table public-pop01
ip rule add from 51.0.0.32/28 table public-pop01
[...]


Auf den jeweiligen VPN Servern (da wo tun-s2s-vpn01 --> 05 steht.) ist im Grunde das gleich leicht Abgeändert konfiguriert. Traffic der von der Öffentlichen IP Adresse kommt, soll über die Point-to-Point Verbindung in Richtung RZ Server geschoben werden.

Zuguter letzt, bekommt der Server im RZ die Pakete, und leitet Sie seinem entsprechendem Standard Gateway weiter.
Ankommende Pakete leitet der Server entsprechend seiner Routing Tabelle weiter. Da der Private Pop einen Statischen Eintrag hat, dass auf eth1 sich die Adressen befinden, leitet er Sie durchs VPN weiter. Alles was Zurück gehen soll, muss über die Ip Rules und andere Routing Tabelle laufen, da sonst das Standard Gateway des jeweiligen Routers genutzt werden würde. Das ist notwendig, da sonst Person A etwas zu Person B sagt, Person A jedoch die Antwort von Person C bekommen würde. Und die Antwort abweisen würde, da Sie von Person B erwartet werden würde.


Adressen und Einträge teilweise verfälscht.
 
Also erfolgt das Routing doch clientseitig.
Ergo massentauglich ist das Ganze nicht...
 
Zuletzt bearbeitet:
Wenn du dem Client via OpenVPN / auf ein Interface die öffentliche Adresse zuweist, brauchst du kein Clientseitiges Routing.
 
Das mit der Sophos ist in 10 Minuten eingerichtet und funktioniert wunderbar solange man eine zweite IP Adresse hat.
Günstigster vServer Anbieter den ich finden konnte kostet $6/Monat inkl. 2 IPv4 Adressen und 1 TB Traffic.
 
ohne NAT, ja, wie gesagt, Bridge auf das WAN Interface und daheim dann die zusätzliche IPv4 zuweisen. Funktioniert.
 
Wenn du dem Client via OpenVPN / auf ein Interface die öffentliche Adresse zuweist, brauchst du kein Clientseitiges Routing.
Zum Vergrößern anklicken....
???
Puh da fehlen mir wohl doch irgendwie die openvpn Hintergründe.
Wie richte ich denn mit openvpn auf dem Client ein zweites Interface ein?

Und selbst wenn das steht: Der Client wüsste immer noch nicht für welche Protokolle er über welches Gateway rausgehen soll.
 
Anmelden, um zu antworten.

Ähnliche Themen

M4st3rM
Mehrere FitzBoxen mit öffentlichem Wireguard Server vernetzen
Antworten
5
Aufrufe
607
Luxxiator
L
Yargen
[User-Review] Lesertest AVerMedia LIVE GAMER 4k 2.1 GC575
Antworten
7
Aufrufe
796
Yargen
Yargen
xmogelx
[User-Review] Lesertest mit ADATA/XPG und ASUS - XPG Invader X BTF - ASUS TUF Gaming Z790-BTF WiFi
Antworten
0
Aufrufe
190
xmogelx
xmogelx
Sinush
[User-Review] Lesertest Arctic P12 PWM PST A-RGB
Antworten
6
Aufrufe
1K
Sinush
Sinush
patrickbuhr
[User-Review] MSI MPG 271QRXDE QD-OLED
Antworten
11
Aufrufe
1K
patrickbuhr
patrickbuhr
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh