ifconfig-push: Peer-Adresse bei net30 oder Subnetzmaske bei subnet?

Dynamische Clients verbinden sich und das Routing funktioniert, aber der eine Client mit fester Adresse erreicht den Server überhaupt nicht. In der Firewall hat sich nichts geändert, und die CCD-Zeile sieht plausibel aus. Die übliche Ursache ist ein zweites Argument, das für eine andere TUN-Topologie geschrieben wurde als die, die der Server ausführt. Der Fehler ist still: Der Client kommt mit einer Adresse hoch und der Server nimmt die Verbindung an, doch es fließt kein Verkehr.

Unter net30 ist dieses Feld eine Peer-Adresse; unter subnet ist es eine Subnetzmaske. Die beiden Formen sind Alternativen, niemals eine Abfolge.

Die beiden Formen im Vergleich

In einer traditionellen net30-Bereitstellung besitzt jeder Client einen /30-Block: eine Netzwerkadresse, zwei nutzbare Adressen und eine Broadcast-Adresse. ifconfig-push nimmt die Client-Adresse und die Peer-Adresse, und der Peer ist die andere nutzbare Adresse im selben Block, die von der Serverseite der Punkt-zu-Punkt-Verbindung verwendet wird.

# net30: client address and its peer
ifconfig-push 10.99.0.6 10.99.0.5
# topology subnet: client address and the pool netmask
ifconfig-push 10.99.0.20 255.255.255.0

Unter topology subnet teilt der Client ein Subnetz mit dem Server, und dieselbe Direktive nimmt eine Adresse und eine Subnetzmaske. Die eigene Adresse des Servers stammt aus der Direktive server, nicht aus dem zweiten Feld. Das Mischen der Formen erzeugt einen Client, der glaubt, er sei auf einer Punkt-zu-Punkt-Verbindung, während der Server ihn als Subnetz-Host routet, oder umgekehrt. Deshalb darf eine Subnetzmaske niemals mit net30 kombiniert werden.

Beide Zeilen im Block sind einzelne Zeilen für eine CCD-Datei. Jeder Client bekommt genau eine davon.

Lesen Sie die Topologie, die der Server tatsächlich ausführt

Lesen Sie die laufende Konfiguration statt einer Paketvorgabe, denn die Topologie kann vor Jahren gesetzt und weiterkopiert worden sein. Suchen Sie topology subnet oder dessen Fehlen und prüfen Sie dann, wie die server-Zeile Adressen vergibt. Eine Konfiguration, die die Topologie nie erwähnt, ist nicht dasselbe wie eine, die subnet setzt.

Lesen Sie dann die Einstellungen, die der Client empfangen hat. Die Adresse, Maske und der Peer, die er meldet, sagen Ihnen, welche Auslegung der Server angewendet hat.

Halten Sie die feste Adresse aus dem dynamischen Pool heraus

Eine feste Adresse muss außerhalb des dynamischen Pools liegen, sonst können zwei Clients dieselbe Adresse erhalten. Bei Subnetz-Topologie unterdrückt nopool in der server-Zeile den automatischen Pool, und ein expliziter ifconfig-pool-Bereich legt fest, was dynamische Clients erhalten.

dev tun
topology subnet
server 10.99.0.0 255.255.255.0 nopool
ifconfig-pool 10.99.0.100 10.99.0.210 255.255.255.0
client-config-dir /etc/openvpn/ccd

Der Server nimmt 10.99.0.1 für sich, und die feste Client-Adresse liegt außerhalb des Pool-Bereichs. Die CCD-Datei wird nach der effektiven Client-Identität benannt, nicht nach dem Profildateinamen, und sie hat keine zusätzliche Erweiterung. Ist username-as-common-name aktiv, ist der authentifizierte Benutzername die zuzuordnende Identität. Zwei Geräte, die sich eine Identität teilen, teilen auch die feste Adresse, was ein Richtlinienproblem und kein Routingproblem ist.

Prüfen Sie die Zuweisung, die der Client tatsächlich erhalten hat

Verbinden Sie den vorgesehenen Client erneut und bestätigen Sie, welche CCD-Datei ausgewählt wurde, bevor Sie etwas anderes prüfen. Prüfen Sie dann Adresse, Maske oder Peer und die Route zurück zum Server. Ein Client, der in einer Subnetz-Bereitstellung eine Peer-Adresse anzeigt, verwendet noch die falsche Form.

Eine Topologieänderung betrifft jeden Client und jede Überschreibung, behandeln Sie sie also als Migration und nicht als Reparatur eines Clients. Die statische Zeile an die bereits verwendete Topologie anzupassen ist normalerweise die kleinere Änderung. die server-options-Referenz dokumentiert den Helfer und die clientspezifischen Überschreibungen.