OPNsense Forum
International Forums => German - Deutsch => Topic started by: theq86 on January 28, 2018, 05:16:56 pm
-
Hallo,
ich würde OpenVPN gern zusätzlich über IPv6 verfügbar machen. Hat damit jemand Erfahrungen? Speziell interessiert mich: Wie bekomme ich Zugriff auf mein LAN vom VPN Client aus?
Bei IPv4 puppig einfach: Die Option Lokales IPv4-Netzwerk benutzen.
Bei IPv6 ergeben sich aber meiner Meinung nach Schwierigkeiten. Dazu muss ich sagen, dass meine IPv6 Konfiguration folgende ist:
WAN (via PPPoE): DHCPv6
Nur einen IPv6-Präfix anfordern: Ja
DHCPv6 Prefix Delegation Größe: 56
Sende einen IPv6-Präfixhinweis: Ja
Sende SOLICIT direkt: Ja
IPv4-Verbindung verwenden: Ja
LAN: Schnittstelle aufzeichen
Schnittstelle: WAN
IPv6 Präfix ID: 0
An erster Stelle eine Nebenfrage: Wozu dient genau die Präfix ID?
Jetzt zum Problem das ich denktechnisch habe:
Alle meine IPv6 Clients beziehen eine global unicast und werden über den radvd der sense konfiguriert. Da ich bei jeder Einwahl vom Provider ein neues Präfix bekomme, müsste ich den VPN Server ja jedes mal neu konfigurieren.
Wobei das ja mMn. auch sinnlos wäre, weil ich mich durch global unicasts eh direkt mit jedem meiner Rechner ohne eine VPN Verbindung connecten kann, wenn ich die entsprechenden Rules habe.
Sinn würde es machen, wenn mein LAN manuell mit unique local konfiguriert wäre. Ich wüsste sofort, welches Netz ich bei OpenVPN eintragen müsste. Ich würde dann auch den radvd oder DHCPv6 einrichten, dass es meinen Clients Adressen in meinem unique local Netz zuweist. Dann hätte ich aber gewissermaßen nix anderes als IPv4 und müsste ja dann von meinem unique local Netz auf eine unique global Adresse natten, wenn die Clients ins Internet sollen?
Eine Möglichkeit, radvd und DHCPv6 mit nem tracked Interface zu konfigurieren gibt es ja nicht. Da brauche ich statische IPs. Außerdem kann ich einem Interface auch nicht gleichzeitig ne statische unique local UND eine unique global Adresse geben, oder? Das alles verwirrt mich etwas.
Wie würdet ihr das ganze einrichten?
-
Das wird IMHO nicht wirklich sauber/gut funktioniere bzw. umsetzbar sein. Deine Konfiguration sagt schon aus, dass du kein statisches v6 Prefix im LAN hast, sondern eines, dass du via Tracking vom WAN zugewiesen bekommst, was wiederum vom Provider (oder einem vorgeschalteten Router) weiterverteilt wurde und sich im dümmsten Fall täglich aber mindestens sporadisch wechselt.
Da OpenVPN nicht wirklich eine Konfiguration kennt (zumindest soweit ich gerade weiß), dass es das Prefix einfach so ersetzt, müsste es statisch konfiguriert werden. Sobald sich also dein WAN Prefix ändert und der Provider es "aus tollen Gründen" rotiert, klappt dein VPN nicht mehr.
> An erster Stelle eine Nebenfrage: Wozu dient genau die Präfix ID?
Das hängt mit deiner WAN Konfiguration zusammen. Du bekommst via WAN und PPPoE eine IPv6 zugewiesen und zusätzlich ein /56er Prefix für dein(e) LAN(s). Da das Prefix - dank toller Providerlogik - dynamisch ist, kannst du es intern nicht fest konfigurieren. Somit hast du 256 (FF) verschiedene /64er Prefixe für dich, die aber dynamisch sind. Bei jeder neuen Einwahl wird also dein WAN ein ggf. neues /56er Prefix bekommen. Via Track Interface kann sich jetzt das LAN selbst eines der 256 Prefixe /64 zuweisen. Die ID 0 heißt, er soll das "nullte" nehmen.
Sagen wir mal du bekommst bei der Einwahl 2001:DB8:dead:de00::/56 zugewiesen, dann hast du 2001:DB8:dead:de00:: bis 2001:DB8:dead:deff:: zur Verfügung. Prefix ID 0 nimmt also 2001:DB8:dead:de00::/64 für das LAN, ID 1 wäre 2001:DB8:dead:de01:: usw.
Hast du mehrere Interfaces mit Tracking muss da dann natürlich jeweils ein anderes Prefix ran. :)
> Wie würdet ihr das ganze einrichten?
Dem Provider seinem dynamischen Mist ein High-5 geben. Ins Gesicht. Mit einem Stuhl.
Im Ernst, dieser ganze dynamische Drecksmist ist der Grund, warum niemand ordentlich mit v6 arbeiten kann (auf Clientseite) ohne sich 3x den Kopf anzubohren. Vieles (alles), wofür man v6 primär gebaut und gepusht hat, wird damit auf den Kopf gestellt und vernichtet. Es sollte kein NAT mehr geben - dank dynamischer Vergabe kann aber niemand ordentliche Prefixe konfigurieren. Mobile-IPv6 solle lustige Sachen ermöglichen - wie denn aber, wenn sich bei Verlassen des Home-Netzes ständig das Prefix für seine IP6 ändert.
Mir kommen zwei Möglichkeiten in den Sinn. Beide sind nicht optimal:
1) IPv6 Tunnel (trotz nativem DualStack) von bspw. he.net und ein statisches v6 Prefix /64 oder /48. Dann kann man alles konfigurieren wie es sich gehört und es passt.
2) intern ULAs verwenden (und brav randomisieren: http://www.hznet.de/tools/generate-rfc4193-addr ) und dann ggf. via NPt von extern auf intern Mappen, womit wir indirekt wieder bei (sowas ähnlichem wie) NAT Grütze wären, aber solang den Herren der Carrier "too big to fail" niemand mal ins Genick tritt, dass dieser Zwangstrennungs- und angebliche Privacy-Quatsch mit rotierenden IPs/IP6-Prefixen Humbug ist, wird sich da wohl in absehbarer Zeit kaum was ändern :(
Auch wenns performance-technisch nicht so schön ist, halte ich aber 1) für die saubere(re) Lösung. Trotzdem sollten Geräte in der Lage sein, sowohl link-local fe80:: als auch ULAs als auch globale IPv6 Adressen zu tragen, so war das zumindest ursprünglich konzipiert.
-
Ich gebe zu, dass der rotierende Präfix schon Grütze machen kann. Allerdings muss man aber auch ganz ehrlich sagen, dass allein der Präfix bei einem Internetanschluss zumindest den Haushalt eindeutig identifiziert, wenn der nicht randomisiert ist.
Desweiteren gehen feste IPs/Präfixe leider mit einem Whois Eintrag beim RIPE einher.
Also für Mutter, Oma usw. finde ich es schon ok, wenn sie das Präfix rotieren.
Leider bietet mein Anbieter auch auf Nachfrage kein festes Präfix, was etwas schade ist. Aber man will wohl sowas den Businesskunden teuer verkaufen.
Auf das ganze NAT Geschmarre oder NPT hab ich auch keine Lust. Also werde ich wohl IPv6 nutzen wozu man es geschaffen hat - Direkt Ende zu Ende.
-
> Allerdings muss man aber auch ganz ehrlich sagen, dass allein der Präfix bei einem Internetanschluss zumindest den Haushalt eindeutig identifiziert, wenn der nicht randomisiert ist.
Natürlich ist es eindeutig zu identifizieren - aber über den Provider. Der vergibt die IPs und Prefixe und entsprechend hat er auch die Whois Einträge. Man ist zwar per RIPE dazu angehalten, die Prefixe etc. einzutragen, allerdings auch nur wenn es über ein bestimmtes Kontingent hinaus geht. RIPE selbst hält die Provider dazu an, den Kunden /60 oder /56 zu vergeben. Nicht dynamisch. Und dazu müsste auch niemand WHOIS Einträge machen. Kann, muss aber nicht. Auch einzelne IP4 müssen nicht eingetragen werden, Subnetze à la /29 oder größer dann schon. Somit ist es einfach nur aus alter eingefahrener Sicht so. Unter der Hand hat mir einer der T-Com Techniker damals bei VDSL und Co schon gesagt, dass der ganze Zwangstrennungs-Schund (und überhaupt PPPoE) nur 2 Gründe hat. a) will man nicht, dass die Kunden (einfach) Sachen bei sich selbst hosten - das sollen sie gefälligst in der tollen Magenta Cloud machen! Und zum Zweiten sind intern ganze Abrechnungsstrukturen und Abteilungen auf dem ganzen PPP Kram gebaut, teils handgestrickt, die man nicht anfassen will. Also werden alte Strukturen einfach beibehalten, weil man es sich einfach macht. Gründe wie Privacy und Datenschutz sind vorgeschoben: der Einzige, der konkret die IP/Prefix zu Kundenzuweiseung hat ist der Provider. Und der muss - sofern nicht abrechnungstechnisch benötigt (was sie nicht werden) die Daten löschen. Somit hat man die Nachverfolgbarkeit nur dann, wenn man quasi ständig den Verkehr abhören würde und schaut, wo sich IP X einloggt. Ja, dann hat man diese Nachverfolgbarkeit. Aber: Heute ist das eh relativ egal. Wer sich Analysesysteme hinter Webseiten oder SEO Tools anschaut wird eh schon sehen, dass man auch mit rotierender IP/Prefixen heute recht gut bestimmen kann, wer wer ist im Internet. Da spielt die IP immer weniger eine Rolle als dass man Leute anhand von Klickpfaden, Verhalten, Cookies und anderer Datenspuren identifiziert. Und das geht oftmals sogar leichter als eine IP, für die man ggf. nen Richter und eine Anzeige braucht.
Sicher hätte das Vor- und Nachteile. Aber gerade bei IP6 und den darauf aufbauenden Mechanismen hat keiner damals damit gerechnet, dass die Prefixe im Ringelrein durchgerudert werden. SLAAC und Autokonfiguration, Route Announcements etc. brauchen Zeit. Und nach jedem Prefix Change dann Netzverlust zu haben, weil sich die IP6 Geräte nicht mehr finden und alle eine Zeit lang brauchen, das neue Prefix zu bekommen... das ist einfach ein Totalschaden. Wer sich heute anonym austoben will, klickt sich meist eh schnell ein VPN zusammen, den anderen wie der Mutter/Oma wärs sicher auch recht wurscht, ob ihre IP statisch ist oder nicht - die machen eh kaum was, was auffällig wäre. :)
-
Ja, was die ISPs da teilweise veranstalten ist schon unverständlich. Mein ISP hat vor kurzem viele Umstellungen vogenommen. Von heut auf morgen hatten plötzlich 90% der Kunden DS-Lite statt Full DualStack.
-
Kein Wunder, man möchte es zwar nicht an die große Glocke hängen, aber gerade die jüngeren Provider (Kabelanbieter bspw.) haben kaum mehr Adressen und können auch keine mehr beibekommen. Jeder rafft gerade so was er bekommen kann (zu vernünftigen Preisen). Und wenn die meisten nicht meckern, klappts ja.
-
Lieschen Müller bekommt davon ja gar nix mit. Aber wenn du seit eh und je VPN benutzt und forwardest und plötzlich hast du keine öffentliche IPv4 mehr dann stehst du echt wie der Ochs vorm Berg. Glücklicherweise kann man es bei meinem ISP über den Kundensupport wieder auf Dual Stack umschalten. Im Endeffekt werden für den Provider dadurch aber mehr v4 Adressen frei als vielleicht zurückgefordert werden.
Aber was dann? Der ISP wird garantiet diese v4 Adressen nicht stilllegen, sondern noch Kohle damit machen. Entweder teuer an Servermieter verkaufen oder vielleicht sogar blockweise verscherbeln. Es sollte ne Richtlinie geben, nach der freie Blöcke einfach wieder an die RiRs zurückgegeben werden damit v4 endlich mal stirbt.
-
> Im Endeffekt werden für den Provider dadurch aber mehr v4 Adressen frei als vielleicht zurückgefordert werden.
Genau, that's the plan ;)
> Aber was dann? Der ISP wird garantiet diese v4 Adressen nicht stilllegen, sondern noch Kohle damit machen.
Indirekt ja. Verkaufen eher nicht, da du sehr selten ein Subnetz freibekommst, dass dann anderweitig geroutet werden kann, aber man kann das dann ideal an die Geschäftskunden weiterverkaufen, die für sowas natürlich gutes Geld zahlen.
> Es sollte ne Richtlinie geben, nach der freie Blöcke einfach wieder an die RiRs zurückgegeben werden damit v4 endlich mal stirbt.
Gibt es. Sind auch alle entsprechend dazu angehalten und gibt es auch eine Prüfung für. Wir sind selbst RIPE Mitglied und bekommen immer mal wieder die freundliche Info, dass unser Netzblock (noch) so wahnsinnig schwer belegt ist und dass wir das entsprechend melden bzw. auf Kunden zuweisen müssen (alles was mehr als 2-3 IPs für einen Kunden sind, sollte mit eigenem inetnum Eintrag im Whois der RIPE stehen). Allerdings steht in der Richtlinie dann auch, dass Netzblöcke wenn sie über ein bestimmtes Maß befüllt sind nicht zurückgerufen werden, damit derjenige Platz für Expansion hat, da er keine Zuweisung mehr bekommen kann. Es würde sich also jeder erst den Arm abhacken als IPs zurückzugeben ;)
-
Hallo,
ich würde OpenVPN gern zusätzlich über IPv6 verfügbar machen. Hat damit jemand Erfahrungen? Speziell interessiert mich: Wie bekomme ich Zugriff auf mein LAN vom VPN Client aus?
Eigentlich ganz einfach. Zusätzlich zu der Global-Unicast-Adresse vergibst du jedem Gerät noch eine Unique Local Unicast. Diese sind statisch, und diese trägst du in deinem lokalen DNS ein.
Alle meine IPv6 Clients beziehen eine global unicast und werden über den radvd der sense konfiguriert. Da ich bei jeder Einwahl vom Provider ein neues Präfix bekomme, müsste ich den VPN Server ja jedes mal neu konfigurieren.
Genau - da OpenVPN leider keinen Präfix selbst beziehen kann, und den VPN-Clients leider auch nicht zwei Adressen zuteilen kann.
Bei OpenWrt hatte ich das bei mir so gelöst, dass bei Neueinwahl der VPN-Dienst neu gestartet wird, und dieser sich beim Starten den aktuellen Präfix holt und diesen benutzt. Die VPN-Clients werden bei Neueinwahl eh getrennt, und bekommen dann bei der nächsten Verbindung eine gültige Global Unicast.
So können die VPN-Clients auch auf die Unique Local Unicast-Adressen in deinem LAN zugreifen, die sie per DNS erhalten. Ein IPv6-NAT ist nicht nötig, da die Geräte in deinem LAN automatisch die Global Unicast verwenden, sobald sie außerhalb deines Netzwerkes Verbindungen aufbauen wollen.
Allerdings bin ich noch neu bei OPNsense und suche gerade noch die passenden Stellen, um mir sowas einzubauen.
Wobei das ja mMn. auch sinnlos wäre, weil ich mich durch global unicasts eh direkt mit jedem meiner Rechner ohne eine VPN Verbindung connecten kann, wenn ich die entsprechenden Rules habe.
Ohne VPN wären die Zugriffe erstens nicht verschlüsselt, und zweitens nicht authentifiziert. Und wenn ich von unterwegs auf meinen Kram zugreifen will, habe ich unterwegs selten statische IP-Adressen (weder v4 noch v6) um diese vorher in den Firewall-Regeln einzutragen. Daher macht das mit VPN schon Sinn, und es funktioniert auch (habs aktuell mit OpenWrt genau so laufen).
Dann hätte ich aber gewissermaßen nix anderes als IPv4 und müsste ja dann von meinem unique local Netz auf eine unique global Adresse natten, wenn die Clients ins Internet sollen?
Nein, der Trick ist, dass jedes Gerät eine Globale und eine Lokale Adresse bekommt.
Außerdem kann ich einem Interface auch nicht gleichzeitig ne statische unique local UND eine unique global Adresse geben, oder?
Eigentlich geht das. Das geht bei OpenWrt, das geht bei pfSense (dort über Virtual IPs/IP Alias), nur bei OPNsense bekomme ich das leider nicht über die GUI hin (IP-Alias erlaubt mir nur IPv4-Adressen).
-
Danke Tobias.
Die Idee, dass ich mit ULAs arbeite kam mir auch, allerdings fand ich ebensowenig eine Möglichkeit den Interfaces zusätzliche alternative IP Adressen zuzuweisen. Manuell will ich das nicht machen, da ich nicht das Risiko eingehen möchte, dass mir manuelle Interface configs zerschossen werden.
die IP Aliases finde ich interessant, kenne aber ihre genaue Funktion nicht. Es ist mir aber zumindest in der aktuellen OPNsense Version gelungen einen Alias auf eine IPv6 Adresse anzulegen.
-
Es ist mir aber zumindest in der aktuellen OPNsense Version gelungen einen Alias auf eine IPv6 Adresse anzulegen.
Wie hast du das gemacht? Bei mir sieht das so aus wie im Anhang und akzeptiert nur IPv4-Adressen.
Bei OpenWrt funktioniert das übrigens so - man definiert seinen ULA-Prefix zentral an einer Stelle, und alle Interfaces die IPv6 nutzen, bekommen dann automatisch zusätzlich diese ULA-Adresse mit der gleichen Prefix-ID wie die globale Adresse.
Ich hab das dann bei mir so gemacht:
IPv4: 192.168.90.0/24
IPv6 Global: 2001:db8:abcd:ab90::/64
IPv6 Lokal: fd67:2389:c0fb:90::/64
Und das nächste Netz hat dann überall die 91, und das nächste dann die 92.
(Die häufiger verwendeten privaten Netze versuche ich zu vermeiden, da das dann unterwegs Probleme machen kann, wenn das gleiche Netz lokal verwendet wird, wie das wo ich mich per VPN hin verbinden will. Und ebenso vermeide ich zu Hause die privaten Netze, die @work verwendet werden.)
Mal sehen, ob ich das irgendwie auch mit opnsense hinbekomme.
-
Genau in der Maske hab ich es auch gemacht und bei Address ne IPv6 Adresse eingetragen. Hat er zugelassen.
Problem ist bei der Sense nur, dass ich trotzdem den radvd oder dhcpv6 server nicht zum laufen kriege, weil die "Hauptkonfiguration" nicht statisch ist. Muss da auch noch n bissl experimentieren.
-
Ah okay, sobald er erkennt, dass es IPv6 ist, passt sich die Auswahlliste mit den Präfixlängen an. Das hatte ich nicht mitbekommen, und das /64 direkt an die IPv6 gehängt - und das ging nicht.
Aber stimmt - den DHCPv6 kann man wohl nur konfigurieren, wenn die Haupt-Adresse statisch ist.
Hier der pfsense-Thread zu dem Thema: https://forum.pfsense.org/index.php?topic=133054.msg735213#msg735213
-
Zumindest der Routing Part von DHCP6 müsste ja eigentlich klappen, oder? Als Assisted Mode?
-
Hallo,
ich würde OpenVPN gern zusätzlich über IPv6 verfügbar machen. Hat damit jemand Erfahrungen? Speziell interessiert mich: Wie bekomme ich Zugriff auf mein LAN vom VPN Client aus?
Bei IPv4 puppig einfach: Die Option Lokales IPv4-Netzwerk benutzen.
Bei IPv6 ergeben sich aber meiner Meinung nach Schwierigkeiten. Dazu muss ich sagen, dass meine IPv6 Konfiguration folgende ist:
WAN (via PPPoE): DHCPv6
Nur einen IPv6-Präfix anfordern: Ja
DHCPv6 Prefix Delegation Größe: 56
Sende einen IPv6-Präfixhinweis: Ja
Sende SOLICIT direkt: Ja
IPv4-Verbindung verwenden: Ja
LAN: Schnittstelle aufzeichen
Select (https://gfbninja.com)
Schnittstelle: WAN
IPv6 Präfix ID: 0
An erster Stelle eine Nebenfrage: Wozu dient genau die Präfix ID?
Jetzt zum Problem das ich denktechnisch habe:
Alle meine IPv6 Clients beziehen eine global unicast und werden über den radvd der sense konfiguriert. Da ich bei jeder Einwahl vom Provider ein neues Präfix bekomme, müsste ich den VPN Server ja jedes mal neu konfigurieren.
Wobei das ja mMn. auch sinnlos wäre, weil ich mich durch global unicasts eh direkt mit jedem meiner Rechner ohne eine VPN Verbindung connecten kann, wenn ich die entsprechenden Rules habe.
Sinn würde es machen, wenn mein LAN manuell mit unique local konfiguriert wäre. Ich wüsste sofort, welches Netz ich bei OpenVPN eintragen müsste. Ich würde dann auch den radvd oder DHCPv6 einrichten, dass es meinen Clients Adressen in meinem unique local Netz zuweist. Dann hätte ich aber gewissermaßen nix anderes als IPv4 und müsste ja dann von meinem unique local Netz auf eine unique global Adresse natten, wenn die Clients ins Internet sollen?
Eine Möglichkeit, radvd und DHCPv6 mit nem tracked Interface zu konfigurieren gibt es ja nicht. Da brauche ich statische IPs. Außerdem kann ich einem Interface auch nicht gleichzeitig ne statische unique local UND eine unique global Adresse geben, oder? Das alles verwirrt mich etwas.
Wie würdet ihr das ganze einrichten?
Ja, was die ISPs da teilweise veranstalten ist schon unverständlich. Mein ISP hat vor kurzem viele Umstellungen vogenommen. Von heut auf morgen hatten plötzlich 90% der Kunden DS-Lite statt Full DualStack.