Welche Kennung braucht Ihre VPN-Reservierung?

Drei Bedingungen entscheiden, welche Kennung eine Reservierung verwenden sollte: welches System die Adresse vergibt, ob dieses System jemals einen Layer-2-Rahmen sieht und was es als Client-Schlüssel verwendet. Ein Heimrouter mit DHCP, ein gebrücktes VPN und ein gerouteter Tunnel beantworten diese Fragen unterschiedlich. Die Kennung zu wählen ist dauerhafter, als jede MAC-Adresse einfrieren zu wollen, die ein Adapter meldet, denn die Kennung ist das, was der Zuteiler tatsächlich liest.

Beginnen Sie beim Zuteiler und arbeiten Sie sich rückwärts vor; die Kennung auf Client-Seite ist das, was dieses System akzeptiert.

Fragen Sie zuerst den Zuteiler

Ein DHCP-Server vergibt aus einem Pool und gleicht Reservierungen mit einer Kennung ab, die er erkennt; je nach Protokollversion kann das die Hardwareadresse, eine Client-Identifier-Zeichenkette oder eine DUID sein. Ein VPN-Server vergibt aus seinem eigenen Pool und gleicht mit dem ab, was sein Konfigurationsmodell offenlegt, oft der authentifizierte Common Name. Ein gebrücktes Netz kann dasselbe Problem an den DHCP-Server weiterreichen, der bereits das LAN bedient. Jede davon ist ein anderer Nachschlag, und eine Reservierung, die in einem gilt, ist für die anderen unsichtbar.

Bestätigen Sie, was der Server tatsächlich sieht, bevor Sie irgendetwas konfigurieren. Eine Reservierung mit der falschen Kennung scheitert still: Der Client erhält einfach eine Pool-Adresse, und der Fehler sieht wie ein Client-Problem aus.

Wo eine MAC-Adresse noch etwas bedeutet

An einer physischen Ethernet- oder Wi-Fi-Verbindung kennzeichnet die Hardwareadresse eine Schnittstelle in diesem Segment. Datenschutzfunktionen rotieren sie, virtuelle Adapter erzeugen neue, und ein Laptop kann über Wi-Fi und an einem Dock unterschiedliche Werte zeigen. Ein gerouteter TUN-Tunnel überträgt IP-Pakete und gibt die ursprüngliche drahtlose Identität nicht an einen entfernten DHCP-Server weiter, sodass eine MAC-basierte Reservierung auf diesem Weg nichts zum Abgleichen hat. TAP unterscheidet sich: Es überträgt Ethernet-Rahmen und kann einer gebrückten Domäne beitreten, in der Layer-2-Kennungen noch zählen.

Auch dort ist die relevante Adresse die auf dieser Domäne verwendete, nicht automatisch die des physischen Uplinks.

Tunneladressen und Peer-Schlüssel besitzen ihren eigenen Raum

Ein geroutetes OpenVPN-Deployment vergibt Adressen über sein eigenes Modell: eine Pro-Client-Konfiguration, die an einen authentifizierten Namen gebunden ist, oder einen expliziten Pool. Die DHCP-Reservierung eines LAN-Routers zu ändern erzeugt diese Zuweisung nicht, und eine Tunnel-Reservierung hinzuzufügen beeinflusst das LAN nicht. WireGuard geht weiter, denn ein Peer wird über seinen öffentlichen Schlüssel und erlaubte Adressen identifiziert statt über eine Hardwarekennung. Keine generische Ethernet-Reservierung ersetzt dort die Peer-Konfiguration.

Führen Sie ein Inventar, das vier Objekte trennt: die Geräte-Anmeldeinformation, den virtuellen Adapter, die Kennung des Zuteilers und die zugewiesene Adresse. Eine physische Maschine kann mehrere Adapter, Adressen und Sitzungen haben.

Eine stabile Adresse ist keine Identität

Eine vorhersagbare Adresse ist betrieblich praktisch und kein Authentifizierungsnachweis. Zugriffsregeln, die sich auf eine Adresse stützen, sind keine Identitätsprüfungen mehr, sobald sie neu zugewiesen, geteilt oder gefälscht wird. Wenn eine Regel von der Adresse abhängt, koordinieren Sie Neuzuweisung und Widerruf mit demjenigen, der die Identität besitzt, und halten Sie die eigentliche Authentifizierungsentscheidung anderswo. So wird aus einer Bequemlichkeit nicht der einzige Beleg dafür, welches Gerät verbunden war.

Erfassen Sie Zuteiler, Kennung und zugewiesene Adresse gemeinsam. Wenn sich eines ändert, sind die anderen beiden das, was Sie prüfen.

Wenn zwei Systeme beide behaupten, für dasselbe Subnetz zu vergeben, entscheiden Sie, welches es besitzt, bevor Sie einem der beiden Reservierungen hinzufügen.