Öffentliche Feste IP per VPN weiterleiten
Guten Tag,
Ich stehe gerade irgendwie auf dem Schlauch.
Ich habe von unserem Provider verschiedene Feste Public Ips bekommen.
Ich habe diese IPs nicht einem Interface auf dem Server zugewiesen.
Denn ich würde gerne die festen Ips als VPN-Client Adresse vergeben.
Hintergrund:
Ich habe Standorte die haben nur eine Dynamic IP. Und ich wollte gerne per VPN den Standorten damit eine Öffentliche feste Ip zu kommen lassen.
Nur habe ich leider keine Idee, wie ich die Feste Adresse in den Remote Bereich bekomme. Da die Local Adress ja das gleiche Netz sein muss. Da ich aber Public Ips aus verschiedenen Netzen habe...
Vielleicht jemand ne Idee? Ich wollte das so realisieren wie der Anbieter portunity.
Einfach IP setzten hat nicht funktioniert, wäre ja auch zu einfach gewesen.
Denn der Server kann diese ja am eth0 beziehen, wenn ich Sie zuweisen würde.
Also dachte Ich kann der VPN Client sich diese vergeben, da der Server ja diese bekommen könnte...
Aber falsch gedacht, so einfach ist das dann wohl doch nicht
lport 1194
rport 1194
ifconfig 37.157.x.x 0.0.0.0
secret system/vpn-key
comp-lzo
dev tap
float
keepalive 10 60
ping-timer-rem
resolv-retry infinite
Würde mich freuen, wenn mir jemand helfen könnte.
Vielen Dank!
Liebe Grüße Bonkersdeluxe1
Ich stehe gerade irgendwie auf dem Schlauch.
Ich habe von unserem Provider verschiedene Feste Public Ips bekommen.
Ich habe diese IPs nicht einem Interface auf dem Server zugewiesen.
Denn ich würde gerne die festen Ips als VPN-Client Adresse vergeben.
Hintergrund:
Ich habe Standorte die haben nur eine Dynamic IP. Und ich wollte gerne per VPN den Standorten damit eine Öffentliche feste Ip zu kommen lassen.
Nur habe ich leider keine Idee, wie ich die Feste Adresse in den Remote Bereich bekomme. Da die Local Adress ja das gleiche Netz sein muss. Da ich aber Public Ips aus verschiedenen Netzen habe...
Vielleicht jemand ne Idee? Ich wollte das so realisieren wie der Anbieter portunity.
Einfach IP setzten hat nicht funktioniert, wäre ja auch zu einfach gewesen.
Denn der Server kann diese ja am eth0 beziehen, wenn ich Sie zuweisen würde.
Also dachte Ich kann der VPN Client sich diese vergeben, da der Server ja diese bekommen könnte...
Aber falsch gedacht, so einfach ist das dann wohl doch nicht
lport 1194
rport 1194
ifconfig 37.157.x.x 0.0.0.0
secret system/vpn-key
comp-lzo
dev tap
float
keepalive 10 60
ping-timer-rem
resolv-retry infinite
Würde mich freuen, wenn mir jemand helfen könnte.
Vielen Dank!
Liebe Grüße Bonkersdeluxe1
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 458016
Url: https://administrator.de/forum/oeffentliche-feste-ip-per-vpn-weiterleiten-458016.html
Ausgedruckt am: 19.04.2025 um 11:04 Uhr
10 Kommentare
Neuester Kommentar
Hallo,
Feste IPs oder sind es Dynamische?

Gruß,
Peter
Feste IPs oder sind es Dynamische?
Denn ich würde gerne die festen Ips als VPN-Client Adresse vergeben.
Die von deinem ISP am ende deiner/seiner Drähte rauskommen?Ich habe Standorte die haben nur eine Dynamic IP. Und ich wollte gerne per VPN den Standorten damit eine Öffentliche feste Ip zu kommen lassen.
So So, und wie wird dann sichergestellt das eine IP nu ein einziges mal Existiert bzw. genutzt wird? Im Internet gilt das gleiche wie in dein LAN. Ein IP nur einmal zuordnen.Nur habe ich leider keine Idee, wie ich die Feste Adresse in den Remote Bereich bekomme.
Frag doch mal bei Portunity nach was die wie gebaut und umgesetzt haben, welche Konfigurationen die nutzen usw. Also dachte Ich kann der VPN Client sich diese vergeben, da der Server ja diese bekommen könnte...
Aber falsch gedacht, so einfach ist das dann wohl doch nicht
OKAber falsch gedacht, so einfach ist das dann wohl doch nicht
Gruß,
Peter

Stichwort 1 to 1 NAT, über iptables schnell gemacht.
http://www.cahilig.net/2010/10/28/how-enable-11-nat-iptables
http://www.cahilig.net/2010/10/28/how-enable-11-nat-iptables

Das geht auch, du verlierst eben nur ein paar Adressen mehr
https://forums.openvpn.net/viewtopic.php?t=12080
https://forums.openvpn.net/viewtopic.php?t=12080
Das geht auch ohne dass man Adressen verliert oder NAT machen muss. Letzteres ist ja mit IPv6 ohnehin hinfällig, also sollte man ohnehin bereits jetzt lieber aufhören irgendwelche Probleme mit NAT statt mit anständigem Routing zu lösen 
Meine Empfehlung ist:
Lasse den OpenVPN private IP-Adressen verteilen. Dann lege statische /32-Routen für die öffentlichen Adressen an und lasse den Next-Hop auf die OpenVPN-Gegenstelle zeigen.
Am Client muss diese IP-Adresse ebenfalls noch manuell auf das Interface mit drauf gebunden werden (z.B. mittels "up"-Script).
Beispiel:
Du bekommst vom Provider das Netz 203.0.113.0/28 geroutet.
Dann kannst du z.B. die Hostadresse 203.0.113.5 an den OpenVPN-Client mit der IP 192.168.200.5 routen, indem du eine Route anlegst:
Route: 203.0.113.5 /32
Next-Hop: 192.168.200.5
Unter Linux bspw. mit:
Zusätzlich muss dein OpenVPN-Server Proxy-ARP machen, da sonst dein Provider-Router nicht weiß, wo der die Pakete hin schicken muss.
Unter Linux wird das über den sysctl-Schlüssel "net.ipv4.conf.eth0.proxy_arp = 1" gelöst.
"eth0" muss natürlich ggf. durch die zum Provider-Router zeigende Netzwerkkarte ersetzt werden.
Wie und ob das unter anderen System funktioniert, überlasse ich denen, die diese anderen Systeme administrieren
Jetzt wird es ein wenig hakelig: Damit OpenVPN wirklich weiß, wo die Route hinzeigen soll, musst du ggf. im OpenVPN-Server selbst ebenfalls noch eine Route setzen.
Dies geschieht dort über die "iroute"-Option. Wie dies genau funktioniert ist am besten in der OpenVPN-Dokumentation nachzulesen.
Alternativ, wenn es nur sehr wenig Clients sind, kannst du auch einfach den OpenVPN im TAP-Mode laufen lassen. Dann hast du reines Ethernet-Bridging auf Layer 2 und kannst auch ohne iroutes beliebige Routen anlegen.
Wichtig ist am Ende nur, dass du irgendein internes IP-Netz auf der OpenVPN-Verbindung benutzt, da dies als Transfernetz für die öffentlichen IPs verwendet wird.
Denke aber daran, dass das gesamte Traffic, ein- wie ausgehend, auf diesen öffentlichen IPs durch die eine Leitung durch fließt.
Das bedeutet, dass die Außenstellen ebenfalls offline sind, wenn diese eine Leitung mal ausfällt. Und natürlich belegt es entsprechend die Bandbreite ein- wie ausgehend
Meine Empfehlung ist:
Lasse den OpenVPN private IP-Adressen verteilen. Dann lege statische /32-Routen für die öffentlichen Adressen an und lasse den Next-Hop auf die OpenVPN-Gegenstelle zeigen.
Am Client muss diese IP-Adresse ebenfalls noch manuell auf das Interface mit drauf gebunden werden (z.B. mittels "up"-Script).
Beispiel:
Du bekommst vom Provider das Netz 203.0.113.0/28 geroutet.
Dann kannst du z.B. die Hostadresse 203.0.113.5 an den OpenVPN-Client mit der IP 192.168.200.5 routen, indem du eine Route anlegst:
Route: 203.0.113.5 /32
Next-Hop: 192.168.200.5
Unter Linux bspw. mit:
ip -4 route add 203.0.113.5/32 via 192.168.200.5
Zusätzlich muss dein OpenVPN-Server Proxy-ARP machen, da sonst dein Provider-Router nicht weiß, wo der die Pakete hin schicken muss.
Unter Linux wird das über den sysctl-Schlüssel "net.ipv4.conf.eth0.proxy_arp = 1" gelöst.
"eth0" muss natürlich ggf. durch die zum Provider-Router zeigende Netzwerkkarte ersetzt werden.
Wie und ob das unter anderen System funktioniert, überlasse ich denen, die diese anderen Systeme administrieren
Jetzt wird es ein wenig hakelig: Damit OpenVPN wirklich weiß, wo die Route hinzeigen soll, musst du ggf. im OpenVPN-Server selbst ebenfalls noch eine Route setzen.
Dies geschieht dort über die "iroute"-Option. Wie dies genau funktioniert ist am besten in der OpenVPN-Dokumentation nachzulesen.
Alternativ, wenn es nur sehr wenig Clients sind, kannst du auch einfach den OpenVPN im TAP-Mode laufen lassen. Dann hast du reines Ethernet-Bridging auf Layer 2 und kannst auch ohne iroutes beliebige Routen anlegen.
Wichtig ist am Ende nur, dass du irgendein internes IP-Netz auf der OpenVPN-Verbindung benutzt, da dies als Transfernetz für die öffentlichen IPs verwendet wird.
Denke aber daran, dass das gesamte Traffic, ein- wie ausgehend, auf diesen öffentlichen IPs durch die eine Leitung durch fließt.
Das bedeutet, dass die Außenstellen ebenfalls offline sind, wenn diese eine Leitung mal ausfällt. Und natürlich belegt es entsprechend die Bandbreite ein- wie ausgehend
Vielleicht jemand ne Idee?
Ja !Du denkst vielzu kompliziert !
- Auf dem festen IP Subnetz richtest du einen VPN Server ein und machst einen Site to Site VPN Verbindung
- Clients wählen sich auf der festen IP Site ein und haben so Zugang zu allen Dynamic VPN Sites
- Fertisch
Du kannst nicht die festen Provider IPs einer Site über irgendein VPN einer anderen Site zur Verfüging stellen.
Moin,
Du hast ein falsches Verständnis von IP-Netzen und Routing.
Du kannst natürlich die IP-Adressen an den Standorten irgendwo eintragen, aber das wird nicht funktionieren, weil alles zum Hauptstandort geroutet wird.
Du kannst aber natürlich VPNs zu dem Hauptstandort machen und dort Deinen VPN-Router oder Deine Firewall anweisen, daß die der jeweiligen IP-Adresse einen exposed Host in der Außenstelle zuordnet..
Der gesamte Trafic läuft aber trotzdem über die Hauptstelle.
Wenn Du explizit feste IP-Adressen für die Außenstellen brauchst, solltest Du mit Geldscheinen nach dem jeweiligen Provider werfen. Dann richten die Dir das ein.
lks
Du hast ein falsches Verständnis von IP-Netzen und Routing.
Du kannst natürlich die IP-Adressen an den Standorten irgendwo eintragen, aber das wird nicht funktionieren, weil alles zum Hauptstandort geroutet wird.
Du kannst aber natürlich VPNs zu dem Hauptstandort machen und dort Deinen VPN-Router oder Deine Firewall anweisen, daß die der jeweiligen IP-Adresse einen exposed Host in der Außenstelle zuordnet..
Der gesamte Trafic läuft aber trotzdem über die Hauptstelle.
Wenn Du explizit feste IP-Adressen für die Außenstellen brauchst, solltest Du mit Geldscheinen nach dem jeweiligen Provider werfen. Dann richten die Dir das ein.
lks
Hallo LordGurke,
an sich kann das so funktionieren, allerdings erlaubt nicht jeder Provider ProxyARP bzw. ARP mit verschiedenen MAC Adressen an einem Interface.
Natürlich ist Routing die bessere Alternative aber ich hatte das auch mal ausprobiert und es hat leider nicht funktioniert, da mein Provider nur eine MAC Adresse an meinem Interface zuließ.
Dann wäre NATen (Exposed Host / 1:1 NAT) tatsächlich die geschicktere Alternative.
Aber wenn man unbedingt feste IPs an diversen Standorten benötigt (warum eigentlich?) @bonkersdeluxe1, sollte man tatsächlich den Provider mal fragen, ob der nicht welche herausrückt, kostet natürlich a bissl was, aber das ist definitiv die beste Variante, da du dich dann nicht ums Routing kümmern musst (Denn der Provider hat damit jahrelange Erfahrung und macht das vermutlich etwas professioneller
Außerdem musst du dich nicht um Fehlerbehebung beim Routing kümmern.
Insofern schließe ich mich aqui und Lochkartenstanzer an: entweder du erledigst die VPN-Einwahl über den Hauptstandort mit den festen IPs und erledigst dein internes Routing zu den Standorten selbst (da hast du ja dann quasi "feste" IPs, auch wenns "nur" LAN-IPs sind) oder du fragst deinen Provider nach öffentlichen Adressen...
Grüße
Ketanest
an sich kann das so funktionieren, allerdings erlaubt nicht jeder Provider ProxyARP bzw. ARP mit verschiedenen MAC Adressen an einem Interface.
Natürlich ist Routing die bessere Alternative aber ich hatte das auch mal ausprobiert und es hat leider nicht funktioniert, da mein Provider nur eine MAC Adresse an meinem Interface zuließ.
Dann wäre NATen (Exposed Host / 1:1 NAT) tatsächlich die geschicktere Alternative.
Aber wenn man unbedingt feste IPs an diversen Standorten benötigt (warum eigentlich?) @bonkersdeluxe1, sollte man tatsächlich den Provider mal fragen, ob der nicht welche herausrückt, kostet natürlich a bissl was, aber das ist definitiv die beste Variante, da du dich dann nicht ums Routing kümmern musst (Denn der Provider hat damit jahrelange Erfahrung und macht das vermutlich etwas professioneller
Insofern schließe ich mich aqui und Lochkartenstanzer an: entweder du erledigst die VPN-Einwahl über den Hauptstandort mit den festen IPs und erledigst dein internes Routing zu den Standorten selbst (da hast du ja dann quasi "feste" IPs, auch wenns "nur" LAN-IPs sind) oder du fragst deinen Provider nach öffentlichen Adressen...
Grüße
Ketanest
Zitat von @ketanest112:
Hallo LordGurke,
an sich kann das so funktionieren, allerdings erlaubt nicht jeder Provider ProxyARP bzw. ARP mit verschiedenen MAC Adressen an einem Interface.
Natürlich ist Routing die bessere Alternative aber ich hatte das auch mal ausprobiert und es hat leider nicht funktioniert, da mein Provider nur eine MAC Adresse an meinem Interface zuließ.
Dann wäre NATen (Exposed Host / 1:1 NAT) tatsächlich die geschicktere Alternative.
Hallo LordGurke,
an sich kann das so funktionieren, allerdings erlaubt nicht jeder Provider ProxyARP bzw. ARP mit verschiedenen MAC Adressen an einem Interface.
Natürlich ist Routing die bessere Alternative aber ich hatte das auch mal ausprobiert und es hat leider nicht funktioniert, da mein Provider nur eine MAC Adresse an meinem Interface zuließ.
Dann wäre NATen (Exposed Host / 1:1 NAT) tatsächlich die geschicktere Alternative.
Wenn der OpenVPN-Server ProxyARP macht (sich also für ARP-Anfragen vom Provider-Router zuständig meldet) sieht der Provider ja exakt eine MAC-Adresse für alle IP-Adressen - nämlich die des OpenVPN-Servers
Wenn du 1:1-NAT machst passiert im Grunde exakt das gleiche...
Aber wie ich ja auch schon erwähnt habe ist das ganze eher stabil wie ein Joghurtbecher und nur bedingt zu empfehlen.
Wenn man das aber als mögliches Failover-Szenario betrachtet, z.B. für Leitungsausfall einer Außenstelle, die dann per LTE online ist und per OpenVPN eine öffentliche IP erhält um erreichbar zu sein, finde ich das durchaus geeignet.