2
IPv6 Konfiguration von Site-Site-VPN ohne feste IP
Hallo zusammen,
vor einiger Zeit hatte ich hier eine Frage zu dem Thema gepostet: Statische IPv6 im internen Netz ohne feste IP am ISP Da war noch etwas offen. Seitdem ist einige Zeit vergangen und ich glaube, ich habe so langsam die Sache mit der IPv6 Address-Selection verstanden.
Daher habe ich meine bisherigen Erkenntnisse mal zusammengefasst.
Diese Anleitung bezieht sich zum Teil nur auf Windows Systeme. Ich setzte voraus, dass dir Grundlagen zur Konfiguration eines Site-Site-VPNs bekannt sind sowie die Grundlagen zu IPv6. Natürlich ist diese Anleitung nur nützlich, wenn man Standorte, an denen IPv6 verwendet wird, verbinden will.
Ansonsten lese man den Beitrag von @aqui : VPNs einrichten mit PPTP
sowie https://de.wikipedia.org/wiki/IPv6 und ggf. https://danrl.com/projects/ipv6-workshop/
Auch im IPv6-Zeitalter kann es sehr sinnvoll sein, Standorte über ein VPN zu verbinden. Das ist aber eine andere Diskussion. Ich gehe davon aus, dass ein VPN zwischen den Standorten besteht. Hierdurch wird der inter-Site Datenverkehr gekapselt, verschlüsselt und somit abgesichert. Allerdings können hier Probleme auftauchen, wenn einer (oder beide) Standorte keine feste IP-Adresse besitzen. Um das zu erklären, stelle ich zunächst die Situation bei festen ISP-IPs dar:
Beide Standorte bekommen vom ISP durch Übergabe eines IPv6-Präfixes einen festen IPv6-Bereich zugewiesen. Mit diesem Präfix können im LAN Global-Unicast Adressen erzeugt werden. Beide Standorte werden über ein VPN verbunden. Das VPN verbindet als Site-Site-VPN die IPv6-Bereiche der beiden Standorte miteinander. Natürlich kann die Link-Lokal-Adresse (fe80:: ) nicht geroutet werden, geroutet werde die Global-Unicast-Adressen.
Die Situation stellt sich dann wie folgt dar:
Site-A: ServerA1
Site-B: ServerB1
Die VPN-Router routen den Datenverkehr zwischen den Standorten:
Soweit wie erwartet.
Was passiert nun, wenn einer oder beide Standorte über keine feste IP verfügen?
Site-A: ServerA1
Site-B: ServerB1
Die VPN-Router müssten eigentlich genau so, bei festen IPs arbeiten. Also:
Allerdings ändern sich die Präfixe bei jeder Einwahl. Nach der nächsten Einwahl müssten die Routing-Regeln geändert werden, je nach zugewiesenem Präfix, also z.B.:
Das Problem könnte ja unter Umständen über noch über aktivierte Routingprotokolle gelöst werden (siehe zum Beispiel RIPng). Mein Router beispielsweise kann das nicht, die über VPN verbundenen Subnetze müssen fest benannt werden.
Das zweite Problem haben die DNS-Server der Standorte. Korrekt konfiguriert erhalten die DNS-Server natürlich umgehend die jeweils aktuelle IPv6 Adresse der Rechner des Standortes. Allerdings kann der DNS-Server von Standort A nicht auf einen DNS-Server am Standort B zugreifen, da er dessen neue Global-Unicast-Adresse nicht kennt.
Damit sind selbst eine Kommunikation zwischen den Standorten über IPv6 nicht mehr möglich.
Zunächst müssen für die Standorte feste Unique-Local-Adressen vergeben werden.
https://tools.ietf.org/html/rfc4193
Super! Genau das ist ja das Anwendungsszenario!
Es sei darauf hingewiesen, dass diese eigentlich nur für spezielle Situationen gedacht sind.
Die Sache würde dann z.B. so aussehen:
Site-A: ServerA1
Site-B: ServerB1
Die VPN-Router routen den Datenverkehr zwischen den Standorten:
Jetzt können IP-Adressen unabhängig vom ISP-Präfix zugewiesen werden, das VPN steht auch nach einer Adressänderung durch den ISP.
Von Standort A funktioniert jetzt ein ping -6 fd65:2:1:1:192:168:2:10.
Der Versuch des Pings auf den Hostnamen zeigt aber, dass der leider nicht die Unique-Local-Address verwendet wird, sondern die Global-Unicast-Address. Warum?
Windows-Clients registrieren alle IPv6-Addresen eines Interfaces beim DNS-Server, wenn dies für das Interface eingestellt ist (Häkchen bei Adressen dieser Verbindung in DNS registrieren). Meines Wissens kann man das nicht auf einzelne IPv6-Präfixe oder Scopes beschränken! Dies gilt auch, wenn es keine Reverse-Lookupzone gibt. Daher erhält der anfragende Client mehrer IPvs-Adressen ausgeliefert:
Das Problem liegt im Default-Address-Selection Algorithmus des IPv6 Gerätes: http://www.ietf.org/rfc/rfc3484.txt
Letztlich werden alle erhaltenen IPv6 Adressen nach den Vorgaben einer nach Vorrang sortierte Präfix-Liste sortiert. Die Adresse mit dem höchsten Vorrang wird dann ausgewählt (Existieren mehrere Adressen mit dem gleichen Prefix, treten hier noch andere Sortierregeln hinzu, siehe rfc, aber das ist an dieser Stelle nicht relevant!).
Diese sogenannten Prefixpolicies können über netsh oder powershell (Get-NetPrefixPolicy) abgefragt werden.
Hier scheint Microsoft etwas unglücklich übersetzt zu haben. Vorgänger statt Precedence - Vorrang wäre viel besser. Die zutreffende Zeile mit der höchsten Precedence wird verwendet, um festzulegen, welche IPv6 Adresse als Zieladresse festgelegt wird. Davon wird dann auch die Quelladresse abgeleitet. Man kann sich die prefixpolicies-Tabelle analog zu einer Routingtabelle vorstellen. (Predescence entspricht hier der Metrik, allerdings umgekehrt gewichtet).
In der oben gezeigten Tabelle haben alle Unique-Local-Addressen fc00::/7 eine viel niedrigere Predecence (nämlich 3) als normale IPv6-Addressen ::/0 Damit verlieren unsere Unique-Local-Adressen und die Global-Unicast-Adresse wird ihnen vorgezogen.
Zum Glück kann man die Prefixpolicies ändern (Linux: siehe man gai.conf ).
Im Hinblick auf den Default-Address-Selection Algorithmus kann en nicht schaden, an allen Standorten das gleiche Label (hier: 20) zu verwenden. Zunächst ist aber die erhöhte Predescence wichtig.
Hilfe dazu siehe auch netsh interface ipv6 add prefixpolicy ?
Jetzt wird, wenn der DNS-Server bei der Namensauflösung mehrere IPv6-Adressen ausspuckt, die Unique-Local-Address des Ziels ausgesucht und die entsprechende eigene Unique-Local-Address als Quelladresse verwendet.
Achtung: Die Predescence muss bei allen Clients geändert werden, die den Hostnamen eines Hosts über einen DNS-Server auflösen, der die sich ändernden Global-Unicast-Adressen kennt!
Das Problem der Namensauflösung kann man auch anders angehen:
Viele Spass damit!
lcer
EDIT (einige kleine Ergänzungen)
vor einiger Zeit hatte ich hier eine Frage zu dem Thema gepostet: Statische IPv6 im internen Netz ohne feste IP am ISP Da war noch etwas offen. Seitdem ist einige Zeit vergangen und ich glaube, ich habe so langsam die Sache mit der IPv6 Address-Selection verstanden.
Daher habe ich meine bisherigen Erkenntnisse mal zusammengefasst.Diese Anleitung bezieht sich zum Teil nur auf Windows Systeme. Ich setzte voraus, dass dir Grundlagen zur Konfiguration eines Site-Site-VPNs bekannt sind sowie die Grundlagen zu IPv6. Natürlich ist diese Anleitung nur nützlich, wenn man Standorte, an denen IPv6 verwendet wird, verbinden will.
Ansonsten lese man den Beitrag von @aqui : VPNs einrichten mit PPTP
sowie https://de.wikipedia.org/wiki/IPv6 und ggf. https://danrl.com/projects/ipv6-workshop/
Inhaltsverzeichnis
Ausgangslage
Auch im IPv6-Zeitalter kann es sehr sinnvoll sein, Standorte über ein VPN zu verbinden. Das ist aber eine andere Diskussion. Ich gehe davon aus, dass ein VPN zwischen den Standorten besteht. Hierdurch wird der inter-Site Datenverkehr gekapselt, verschlüsselt und somit abgesichert. Allerdings können hier Probleme auftauchen, wenn einer (oder beide) Standorte keine feste IP-Adresse besitzen. Um das zu erklären, stelle ich zunächst die Situation bei festen ISP-IPs dar:Verbindung von Standorten mit festen (Internet)-IPs
Beide Standorte bekommen vom ISP durch Übergabe eines IPv6-Präfixes einen festen IPv6-Bereich zugewiesen. Mit diesem Präfix können im LAN Global-Unicast Adressen erzeugt werden. Beide Standorte werden über ein VPN verbunden. Das VPN verbindet als Site-Site-VPN die IPv6-Bereiche der beiden Standorte miteinander. Natürlich kann die Link-Lokal-Adresse (fe80:: ) nicht geroutet werden, geroutet werde die Global-Unicast-Adressen.Die Situation stellt sich dann wie folgt dar:
Site-A: ServerA1
C:\Windows\system32>ipconfig /all
Ethernet-Adapter Ethernet:
IPv6-Adresse. . . . . . . . . . . : 2003:1:1:1:1:1:1:1(Bevorzugt)
Verbindungslokale IPv6-Adresse . : fe80:1:1:1:1:1(Bevorzugt)
IPv4-Adresse . . . . . . . . . . : 192.168.1.10(Bevorzugt)
Subnetzmaske . . . . . . . . . . : 255.255.255.0Site-B: ServerB1
C:\Windows\system32>ipconfig /all
Ethernet-Adapter Ethernet:
IPv6-Adresse. . . . . . . . . . . : 2003:2:1:1:1:1:1:1(Bevorzugt)
Verbindungslokale IPv6-Adresse . : fe80:2:1:1:1:1(Bevorzugt)
IPv4-Adresse . . . . . . . . . . : 192.168.2.10(Bevorzugt)
Subnetzmaske . . . . . . . . . . : 255.255.255.0Die VPN-Router routen den Datenverkehr zwischen den Standorten:
- VPN-Router am Standort A routet das Ziel 2003:2:1:1::::/64 über das VPN.
- VPN-Router am Standort B routet das Ziel 2003:1:1:1::::/64 über das VPN.
Soweit wie erwartet.
Verbindung von Standorten mit wechselnden (Internet)-IPs
Was passiert nun, wenn einer oder beide Standorte über keine feste IP verfügen?Site-A: ServerA1
C:\Windows\system32>ipconfig /all
Ethernet-Adapter Ethernet:
IPv6-Adresse. . . . . . . . . . . : 2003:1:1:1:1:1:1:1(Bevorzugt)
Verbindungslokale IPv6-Adresse . : fe80:1:1:1:1:1(Bevorzugt)
IPv4-Adresse . . . . . . . . . . : 192.168.1.10(Bevorzugt)
Subnetzmaske . . . . . . . . . . : 255.255.255.0Site-B: ServerB1
C:\Windows\system32>ipconfig /all
Ethernet-Adapter Ethernet:
IPv6-Adresse. . . . . . . . . . . : 2003:2:1:1:1:1:1:1(Bevorzugt)
Verbindungslokale IPv6-Adresse . : fe80:2:1:1:1:1(Bevorzugt)
IPv4-Adresse . . . . . . . . . . : 192.168.2.10(Bevorzugt)
Subnetzmaske . . . . . . . . . . : 255.255.255.0Die VPN-Router müssten eigentlich genau so, bei festen IPs arbeiten. Also:
- VPN-Router am Standort A routet das Ziel 2003:2:1:1::::/64 über das VPN.
- VPN-Router am Standort B routet das Ziel 2003:1:1:1::::/64 über das VPN.
Allerdings ändern sich die Präfixe bei jeder Einwahl. Nach der nächsten Einwahl müssten die Routing-Regeln geändert werden, je nach zugewiesenem Präfix, also z.B.:
- VPN-Router am Standort A routet das Ziel 2003:2a:34:1::::/64 über das VPN.
- VPN-Router am Standort B routet das Ziel 2003:a74:24:1::::/64 über das VPN.
Das Problem könnte ja unter Umständen über noch über aktivierte Routingprotokolle gelöst werden (siehe zum Beispiel RIPng). Mein Router beispielsweise kann das nicht, die über VPN verbundenen Subnetze müssen fest benannt werden.
Das zweite Problem haben die DNS-Server der Standorte. Korrekt konfiguriert erhalten die DNS-Server natürlich umgehend die jeweils aktuelle IPv6 Adresse der Rechner des Standortes. Allerdings kann der DNS-Server von Standort A nicht auf einen DNS-Server am Standort B zugreifen, da er dessen neue Global-Unicast-Adresse nicht kennt.
Damit sind selbst eine Kommunikation zwischen den Standorten über IPv6 nicht mehr möglich.
Lösung: Unique-Local-Address
Zunächst müssen für die Standorte feste Unique-Local-Adressen vergeben werden.https://tools.ietf.org/html/rfc4193
6. Advantages and Disadvantages
6.1. Advantages
This approach has the following advantages:
...
- Provides Local IPv6 prefixes that can be used independently of
any provider-based IPv6 unicast address allocations. This is
useful for sites not always connected to the Internet or sites
that wish to have a distinct prefix that can be used to localize
traffic inside of the site.
- Sites can change their provider-based IPv6 unicast address
without disrupting any communication that uses Local IPv6
addresses.
...
- Can be used for inter-site VPNs.Super! Genau das ist ja das Anwendungsszenario!
Es sei darauf hingewiesen, dass diese eigentlich nur für spezielle Situationen gedacht sind.
- Insbesondere soll ein Routing ins Internet ausgeschlossen sein.
- Auch sollte man den Erzeugungsalgorithmus beachten, der durch zufällige Generierung der Adresse die Wahrscheinlichkeit für Adresskollisionen minimieren soll. Man sollte nicht Präfixe wie fd00:1:: wählen!
- Der zu verwendende Bereich ist hier fd00::/8 also fd00:: bis fdff:: (der Bereich fc00:: bis fcff:: fällt ebenfalls unter Unique-Local-Address, ist aber undefiniert)
Die Sache würde dann z.B. so aussehen:
Site-A: ServerA1
C:\Windows\system32>ipconfig /all
Ethernet-Adapter Ethernet:
IPv6-Adresse. . . . . . . . . . . : 2003:1:1:1:1:1:1:1(Bevorzugt)
IPv6-Adresse. . . . . . . . . . . : fd65:1:1:1:192:168:1:10(Bevorzugt)
Verbindungslokale IPv6-Adresse . : fe80:1:1:1:1:1(Bevorzugt)
IPv4-Adresse . . . . . . . . . . : 192.168.1.10(Bevorzugt)
Subnetzmaske . . . . . . . . . . : 255.255.255.0Site-B: ServerB1
C:\Windows\system32>ipconfig /all
Ethernet-Adapter Ethernet:
IPv6-Adresse. . . . . . . . . . . : 2003:2:1:1:1:1:1:1(Bevorzugt)
IPv6-Adresse. . . . . . . . . . . : fd65:2:1:1:192:168:2:10(Bevorzugt)
Verbindungslokale IPv6-Adresse . : fe80:2:1:1:1:1(Bevorzugt)
IPv4-Adresse . . . . . . . . . . : 192.168.2.10(Bevorzugt)
Subnetzmaske . . . . . . . . . . : 255.255.255.0Die VPN-Router routen den Datenverkehr zwischen den Standorten:
- VPN-Router am Standort A routet das Ziel fd65:2:1:1::::/64 über das VPN.
- VPN-Router am Standort B routet das Ziel fd65:1:1:1::::/64 über das VPN.
Neues Problem - die Namensauflösung: Prefixpolicies
Jetzt können IP-Adressen unabhängig vom ISP-Präfix zugewiesen werden, das VPN steht auch nach einer Adressänderung durch den ISP.Von Standort A funktioniert jetzt ein ping -6 fd65:2:1:1:192:168:2:10.
Der Versuch des Pings auf den Hostnamen zeigt aber, dass der leider nicht die Unique-Local-Address verwendet wird, sondern die Global-Unicast-Address. Warum?
Windows-Clients registrieren alle IPv6-Addresen eines Interfaces beim DNS-Server, wenn dies für das Interface eingestellt ist (Häkchen bei Adressen dieser Verbindung in DNS registrieren). Meines Wissens kann man das nicht auf einzelne IPv6-Präfixe oder Scopes beschränken! Dies gilt auch, wenn es keine Reverse-Lookupzone gibt. Daher erhält der anfragende Client mehrer IPvs-Adressen ausgeliefert:
C:\Windows\system32>nslookup
Standardserver: dns-server1.lokaletestdomain.de
Address: 192.168.0.10
> anderer-server1
Server: dns-server1.lokaletestdomain.de
Address: 192.168.0.10
Name: anderer-server1.lokaletestdomain.de
Addresses: fd65:5:5:1:2:3:4
fd65:1:1:1:192:168:1:10
2003::5:5:1:2:3:4
192.168.1.10Das Problem liegt im Default-Address-Selection Algorithmus des IPv6 Gerätes: http://www.ietf.org/rfc/rfc3484.txt
Letztlich werden alle erhaltenen IPv6 Adressen nach den Vorgaben einer nach Vorrang sortierte Präfix-Liste sortiert. Die Adresse mit dem höchsten Vorrang wird dann ausgewählt (Existieren mehrere Adressen mit dem gleichen Prefix, treten hier noch andere Sortierregeln hinzu, siehe rfc, aber das ist an dieser Stelle nicht relevant!).
Diese sogenannten Prefixpolicies können über netsh oder powershell (Get-NetPrefixPolicy) abgefragt werden.
C:\Windows\system32>netsh interface ipv6 show prefixpolicies
Der aktive Status wird abgefragt...
Vorgänger Label Präfix
---------- ----- --------------------------------
50 0 ::1/128
40 1 ::/0
35 4 ::ffff:0:0/96
30 2 2002::/16
5 5 2001::/32
3 13 fc00::/7
1 11 fec0::/10
1 12 3ffe::/16
1 3 ::/96In der oben gezeigten Tabelle haben alle Unique-Local-Addressen fc00::/7 eine viel niedrigere Predecence (nämlich 3) als normale IPv6-Addressen ::/0 Damit verlieren unsere Unique-Local-Adressen und die Global-Unicast-Adresse wird ihnen vorgezogen.
Zum Glück kann man die Prefixpolicies ändern (Linux: siehe man gai.conf ).
C:\Windows\system32>netsh int ipv6 add prefixpolicy fd65:1:1::/48 45 20
OK.Im Hinblick auf den Default-Address-Selection Algorithmus kann en nicht schaden, an allen Standorten das gleiche Label (hier: 20) zu verwenden. Zunächst ist aber die erhöhte Predescence wichtig.
Hilfe dazu siehe auch netsh interface ipv6 add prefixpolicy ?
C:\Windows\system32>netsh interface ipv6 show prefixpolicies
Der aktive Status wird abgefragt...
Vorgänger Label Präfix
---------- ----- --------------------------------
50 0 ::1/128
45 20 fd65:1:1:1:/48
40 1 ::/0
35 4 ::ffff:0:0/96
30 2 2002::/16
5 5 2001::/32
3 13 fc00::/7
1 11 fec0::/10
1 12 3ffe::/16
1 3 ::/96Jetzt wird, wenn der DNS-Server bei der Namensauflösung mehrere IPv6-Adressen ausspuckt, die Unique-Local-Address des Ziels ausgesucht und die entsprechende eigene Unique-Local-Address als Quelladresse verwendet.
Achtung: Die Predescence muss bei allen Clients geändert werden, die den Hostnamen eines Hosts über einen DNS-Server auflösen, der die sich ändernden Global-Unicast-Adressen kennt!
Alternative Lösungen
Das Problem der Namensauflösung kann man auch anders angehen:- das Verwenden der Unique-Local-Adresse statt des Hostnamens
- das umgehen der DNS-Auflösung über andere Mechanismen (möglicherweise /drivers/etc/hosts ? von mir nicht getestet)
- Das manuelle Eintragen der Server-IPv6-Adressen und das Abschalten der automatischen Registrierung. Damit sind dem DNS-Server die Global-Unicast-Adressen unbekannt. Dies wiederspricht allerdings den Windows Best-Practies: DNS: Schnittstelle Ethernet des DNS-Servers sollte so konfiguriert sein, dass die IP-Adressen in DNS registriert werden
- Bevorzugen von IPv6 gegenüber IPv4: https://support.microsoft.com/de-de/help/929852/guidance-for-configuring ... per Windows-Registry. Hier wird als Übergangslösung wieder eine Mischtechnologie implementiert (LAN IPv4, sonst IPv6).
Viele Spass damit!
lcer
EDIT (einige kleine Ergänzungen)
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 392319
Url: https://administrator.de/tutorial/ipv6-konfiguration-von-site-site-vpn-ohne-feste-ip-392319.html
Ausgedruckt am: 22.12.2024 um 02:12 Uhr
2 Kommentare
Neuester Kommentar
Stand der Dinge:
momentan sieht meine Konfiguration wie folgt aus:
Die Priorisierung der ULAs per Erhöhung der Predescense bringt hat einige Probleme mit sich: Der Algoritmus der Source Address Selection kommt zum falschen Ergebnis, wenn der Scope des der Global-Unicast-Adresse des LAN Native-IPv6 und der Scope des Ziels eine Übergangstechnologie-IPv6 Adresse darstellt. Hier passt dann der Scope nicht (Rule 2 des Algoritmus). Dann wird unter Umständen die ULA wegen der erhöhten Predescence als Source-Adresse ausgewählt (zumindest war das bei mir so).
Obwohl die Einstellung Bevorzugen von IPv6 gegenüber IPv4 auch nichts anderes tut, als die Predescence zu ändern (kann man schön über netsh interface ipv6 show prefixpolicies verfolgen) gibt es einen entscheidenden Unterschied: Zu den vom DNS-Server zurückgelieferten IPv4-Adressen können immer gültige Quelladressen gefunden werden, da immer eine verwendbare IPv4-Adresse ausgewählt wird.
Der Client hat da nämlich nur die eine, die dann in der Regel über NAT umgesetzt als Quelladresse fungieren kann. Wird hingegen für das LAN verlassende Zieleadressen die ULA als Quelladresse ausgewählt, fehlt dann die Rückroute vom Provider zum LAN.
Grüße
lcer
momentan sieht meine Konfiguration wie folgt aus:
- ich habe an den Standorten ULAs konfiguriert
- bei den Windows-Rechnern ist per Registry Bevorzugen von IPv6 gegenüber IPv4 eingestellt
Die Priorisierung der ULAs per Erhöhung der Predescense bringt hat einige Probleme mit sich: Der Algoritmus der Source Address Selection kommt zum falschen Ergebnis, wenn der Scope des der Global-Unicast-Adresse des LAN Native-IPv6 und der Scope des Ziels eine Übergangstechnologie-IPv6 Adresse darstellt. Hier passt dann der Scope nicht (Rule 2 des Algoritmus). Dann wird unter Umständen die ULA wegen der erhöhten Predescence als Source-Adresse ausgewählt (zumindest war das bei mir so).
Obwohl die Einstellung Bevorzugen von IPv6 gegenüber IPv4 auch nichts anderes tut, als die Predescence zu ändern (kann man schön über netsh interface ipv6 show prefixpolicies verfolgen) gibt es einen entscheidenden Unterschied: Zu den vom DNS-Server zurückgelieferten IPv4-Adressen können immer gültige Quelladressen gefunden werden, da immer eine verwendbare IPv4-Adresse ausgewählt wird.
Der Client hat da nämlich nur die eine, die dann in der Regel über NAT umgesetzt als Quelladresse fungieren kann. Wird hingegen für das LAN verlassende Zieleadressen die ULA als Quelladresse ausgewählt, fehlt dann die Rückroute vom Provider zum LAN.
Grüße
lcer
momentaner Status: IPv6 wieder deaktiviert. Es gab immer wieder Probleme mit der Erreichbarkeit.
Ich denke, die richtige Lösung wäre ein passendes Routing-Protokoll für die VPN-Router, die leider keins beherrschen. NDP reicht nicht aus.
Grüße
lcer
Ich denke, die richtige Lösung wäre ein passendes Routing-Protokoll für die VPN-Router, die leider keins beherrschen. NDP reicht nicht aus.
Grüße
lcer
