IPv6 Adressen für Jails vergeben

ghostfish

Well-Known Member
Hallo,

ich würde gerne einen Webserver innerhalb einer Jail im Heimnetz betreiben. Da ich von Vodafone keine öffentliche IPv4-Adresse erhalte, muss ich es über IPv6 probieren. Die Idee wäre es, am Router ein Port Forwarding auf die Jails-Adresse für 443 einzurichten.

Leider kenne ich mich mit IPv6 nicht aus, sodass ich nicht weiß, ob mein Ansatz funktionieren kann. Ist es möglich, meinem FreeBSD-Host beispielsweise fe80::::::1 zu geben und die Jails dann entsprechend hoch zu zählen, solange ich den Link Local Prefix "fe8" verwende?

Wenn der Webserver einen Interface-Alias mit der Adresse fe80::::::2 erhält, würde ich dann auf dem Router einen IPv6 Host Exposure / Port Forwarding für 443 auf diese Adresse einrichten. Ist das zu einfach gedacht, oder könnte das so funktionieren?

Vielen Dank im Voraus!
 
Das link-local Prefix ist fe80::/10. Dabei ist es jedoch üblich es als fe80::/64 zu behandeln und die mittleren Bits auf 0 zu lassen.

Das Problem ist haarig, weil Jails (jedenfalls solche ohne VNET) ihre IP Adressen nicht zur Laufzeit ändern können. Solltest du ihnen also öffentliche IPv6 Adressen aus dem /64 geben so müsstest du sie bei jedesmal neustarten um die Adressen zu ändern. Link-local Adressen ändern sich zwar nicht, aber sind halt bloß direkt auf dem Link gültig. Du könntest dir ULAs schnappen und die verteilen, aber dann brauchst du noch immer nen Reverse Proxy z.B. nen HAProxy auf dem Hostsystem. Der braucht kaum Ressourcen und hat eine ziemlich kleine Angriffsfläche, aber es ist alles etwas lästig aufzusetzen.

Ein anderer, ebenfalls komplizierter Ansatz wäre es deinen Host als Router zu konfigurieren und dir von dem Plastikrouter nen /64 delegieren zu lassen z.B. mit dhcpcd und dieses auf einer Bridge zu verteilen an VNET Jails zu verteilen die dort über epair(4) Interfaces hängen. Die Jails müssten dann allerdings ihren eigenen IP Stack verwalten und sich per SLAAC oder DHCPv6 ihre Adressen holen und dynamisches DNS Updaten.

Alles Scheisse. Der Ausweg wären stabile globale Adressen, aber die bekommt man zuhause nicht ohne nen VPN Tunnel (nicht den Warezblödsinn) oder viel Kohle auszugeben für nen Geschäftskundenvertrag, wenn der überhaupt mit nativem IPv6 verfügbar ist seufz.
 
Vielen Dank für deine ausführliche Antwort!

Ich verstehe nicht alles, aber das ist insgesamt sehr ernüchternd.. dann werde ich zunächst mal nach der VPN-Tunnel Lösung suchen, die hört sich am einfachsten an und mich mal mit ULAs und HAProxies auseinander setzen. Nochmals vielen Dank, das hat mir schon mal weiter geholfen! :)
 
Der Ausweg wären stabile globale Adressen, aber die bekommt man zuhause nicht ohne nen VPN Tunnel (nicht den Warezblödsinn) oder viel Kohle auszugeben für nen Geschäftskundenvertrag, wenn der überhaupt mit nativem IPv6 verfügbar ist
Finde ich ja irgendwie lustig. Weil früher wurde uns erzählt, das feste IP bei IPv4 eben so schwierig ist weil da Adressen ein knappes Gut sind, aber mit IPv6 das alles kein Problem mehr sein wird.
Jetzt haben wir (so langsam) IPv6 und es wird die letztlich gleiche Sch**ße wie bei IPv4 abgezogen. Gut. Grundsätzlich ist es ja auch gar nicht verkehrt, das man als Privatkunde ein dynamischen Präfix kriegt. So rein schon aus Privacy-Gründen. Warum das dann aber dennoch ne Hürde ist auf Anfrage nen festen Präfix zu bekommen ist nur mit ähm ... Geschäftssinn (a-ka Geldschneiderei) zu erklären.
 
Das ist in der Tat so beschissen und das richtige Wort dafür. :)

Am allereinfachsten wäre es, den Provider zu wechseln. Ich kann dir aber nicht sagen, welcher jetzt die Zwecke noch erfüllt oder zumindest auf Anfrage was gangbar macht, ohne dich in einen Business-Tarif mit Mondpreisen zu drängen.
Da müsste man mal in den jeweiligen Userforen nachschlagen, bist nicht alleine damit.

Ansonsten wegen VPN: irgendwo einen vserver mieten, damit bekommst du die feste IP und darauf setzt du deinen reverse proxy. Zum vserver baust du dann deinen Tunnel auf und somit erreicht der reverse proxy über interne IPs (ipv4,ipv6 wie du willst) deine jail.
 
Vielen Dank für die hilfreichen Ansätze, ich werde das mit dem VPN und dem vserver testen (mit meinem Provider hatte ich zuletzt genug Probleme, da möchte ich ungern weitere Änderungen erkämpfen).

Sofern möglich, würde ich Free- oder OpenBSD als OS auf dem vserver einsetzen, ansonsten werde ich auf Debian 10 ausweichen, weil ich das im Standardpaket schon gesehen habe. Gibt es eine besondere Sicherheitsanforderung an das System in der vorgesehenen Rolle, oder könnte ich das in der Standardkonfiguration laufen lassen? Wahrscheinlich wäre es gut, alle Ports bis auf 22, 443 und den des VPNs zu schließen (sofern etwas offen wäre).

Wäre Wireguard eine Option für den Tunnel? IPsec soll ja etwas komplexer und daher für Laien wie mich fehleranfälliger sein.. auf der Wireguard-Homepage ist ein Beispiel aufgeführt (ich verwende nur den Server-Part und nur den ersten Peer):

Code:
[Interface]
PrivateKey = yAnz5TF+lXXJte14tji3zlMNq+hd2rYUIgJBgB3fBmk=
ListenPort = 51820

[Peer]
PublicKey = xTIBA5rboUvnH4htodjb6e697QjLERt1NAB4mZqp8Dg=
AllowedIPs = 10.192.122.3/32, 10.192.124.1/24

Um den Tunnel aufzubauen, würde ich nur im Peer-Eintrag den Public Key meiner Jail sowie die Adresse innerhalb des Heimnetzes (sagen wir 192.168.0.42/0) eintragen?

Und bräuchte ich eine gesonderte Software für die Funktion des Reverse Proxies, oder könnte ich mit pf alle Anfragen auf dem 443er Port auf die unter "Peer" hinterlegte Adresse weiterleiten? (Würde das eigentlich grundsätzlich gehen? Also eine Adresse, die ja nur über NAT hinter meinem Router existiert, als Ziel eintragen?)

Vermutlich denke ich schon wieder viel zu einfach..

Über Hinweise wäre ich sehr dankbar! :)
 
Sofern möglich, würde ich Free- oder OpenBSD als OS auf dem vserver einsetzen, ansonsten werde ich auf Debian 10 ausweichen, weil ich das im Standardpaket schon gesehen habe.
Naturgemäß bietet nicht jeder Hoster *BSD standardmäßig an, aber auch diese gibt es. Und welche, wo du eigene ISOs hochladen kannst.

Gibt es eine besondere Sicherheitsanforderung an das System in der vorgesehenen Rolle, oder könnte ich das in der Standardkonfiguration laufen lassen?
Was meinst du mit Standardkonfiguration? Sobald man was öffentlich erreichbar macht, sollte man das immer so sicher wie möglich gestalten. Lektüre dazu: http://serverzeit.de/tutorials/admins-haften

Je nachdem was du hosten willst auf dem Webserver, kannst du dir ja überlegen, ob du den Webserver nicht gleich direkt auf dem vserver laufen lässt.
Den 'verlängerten Arm' mit dem VPN/reverse proxy macht man bei solchen doofen IP-Konstellationen oder wenn man viele Daten hat und das Hostingpaket dadurch unbezahlbar werden würde.

Ich kenne wireguard nicht, aber jedes VPN wird den Zweck erfüllen. OpenVPN geht auch sehr gut.

Und bräuchte ich eine gesonderte Software für die Funktion des Reverse Proxies, oder könnte ich mit pf alle Anfragen auf dem 443er Port auf die unter "Peer" hinterlegte Adresse weiterleiten? (Würde das eigentlich grundsätzlich gehen? Also eine Adresse, die ja nur über NAT hinter meinem Router existiert, als Ziel eintragen?)
Geht alles. :)
 
Naturgemäß bietet nicht jeder Hoster *BSD standardmäßig an, aber auch diese gibt es. Und welche, wo du eigene ISOs hochladen kannst.
Hoster gibt es viele. In der Holzklasse sind Digital Ocean (nur FreeBSD offiziell, OpenBSD über Community Support) und Vultr (FreeBSD und OpenBSD offiziell) zu empfehlen. Billig, keine Vertragslaufzeit und technisch durchaus okay.
 
Wäre Wireguard eine Option für den Tunnel? IPsec soll ja etwas komplexer und daher für Laien wie mich fehleranfälliger sein.. auf der Wireguard-Homepage ist ein Beispiel aufgeführt (ich verwende nur den Server-Part und nur den ersten Peer):
Ich verwende Wireguard um meinen Server hier bei mir mit dem Server an einem anderen Standort zu verbinden. Bei stehen in einem privaten LAN, also hinter einem Router mit NAT.

Die Konfiguration sieht wie folgt aus.
Server A:
Code:
[Interface]
Address = 192.168.200.2/24
PrivateKey = abcdef1234....
ListenPort = 51820

[Peer]
PublicKey = qwertz6789....
AllowedIPs = 192.168.200.0/24
Endpoint = dyndns-name.example.com:51820

Server B (mit Portfreigabe am Router):
Code:
[Interface]
Address = 192.168.200.1/24
PrivateKey = yxcvbb3456.....
ListenPort = 51820

[Peer]
PublicKey = ghjkl8524.....
AllowedIPs = 192.168.200.0/24

Das sollte also bei dir recht ähnlich sein. Nachdem ich die Verbindung immer nur von einer Seite her aufbauen kann, nämlich vom Server A aus, habe ich dort auch noch ein Skript im crontab stehen. Das von Zeit zu Zeit die Verbindung prüft und bei Bedarf neu aufbaut. Aber das müsste bei dir nicht notwendig sein, da deine Serverseite ja permanent ist.
 
Nochmals vielen Dank für die Unterstützung! :)

Den Artikel auf serverzeit.de habe ich gelesen, allerdings wird dort nicht auf konkrete Maßnahmen zur Absicherung eingegangen. Ich habe jetzt einen vserver auf Vultr einrichten lassen (vielen Dank Yamagi und derOliver für die Auswahl möglicher Hoster :) ) und dort OpenBSD 6.8 gewählt. Ich habe dann direkt syspatch ausgeführt und den SSH-Login auf PubKey beschränkt. Ist das für den vorgesehenen Betrieb ausreichend, oder gibt es eventuell Empfehlungen zur besseren Absicherung?

Nach meinem Verständnis definiere ich die Wireguard-Schnittstellen, indem ich in /etc/ die Datei "hostname.wg0" erstelle und diese dann mit dem Inhalt ähnlich des Beispiels von pchris befülle. Auf diesem Weg könnte ich dann wahrscheinlich zukünftig auch weitere Wireguard-Schnittstellen definieren, um sie auf einem anderen Port beispielsweise mit einer Teamspeak-Jail zu verbinden.

Bei der pf-Konfiguration tue ich mich etwas schwer..
Code:
pass in on vio0 proto tcp from any port 443 nat-to wg0
  • vio0 ist die Schnittstelle, der die öffentliche IP des vservers zugewiesen ist.
  • bei "from any" weiß ich nicht, ob ich den Port einschränken darf; das wäre mein Ansatz um sicherzustellen, dass nur Webanfragen an den Webserver geleitet werden
  • ist das "nat-to" hier richtig? Oder genügt ein "to", weil der vserver ja nur an die Schnittstelle verweist?
Ich habe das so aus verschiedenen Beispielen zusammen getragen und würde es so auch ausprobieren, aber falls ganz grobe Schnitzer auffallen, bin ich für Hinweise dankbar! :)
 
Das "from any" kann entfallen, da es voreingestellt ist. Wenn der VServer den Endpunkt darstellt, dann ist nat nicht notwendig.

Code:
pass in on vio0 proto tcp to wg0 port 443
 
Vielen Dank jmt für die Erklärung! :)

Nach einigen erfolglosen Tests habe ich mich dazu entschieden, erstmal die wahrscheinlich einfachste Lösung über OpenSSH zu wählen, bis ich mir ein paar Grundlagen zu den Themen Wireguard und pf angeeignet habe.

Ein kurzer Test der Remote Port Forwarding Funktion hat für mich funktioniert:
Code:
ssh -R <remotePort>:localhost:<localPort> <user>@<publicIPvserver>

Nochmals vielen Dank an alle für die vielen hilfreichen Antworten!
 
Zurück
Oben