Wie Sie den Adressraum für ein VPN mit mehreren Standorten planen

Wie groß das VPN-Subnetz sein sollte, hat keine Antwort, solange Sie nicht benennen, welche Adressen Sie zählen. In einem Entwurf sind das die beiden Endpunkte einer nummerierten Tunnelverbindung, in einem anderen das Büro-LAN hinter einem richtlinienbasierten Tunnel und in einem dritten die reservierte Infrastruktur eines verwalteten Gateways. Drei Objekte, drei Budgets, und die meisten Dimensionierungsfehler entstehen daraus, dass eine Spalte mit der Zahl einer anderen gefüllt wird.

Vier Rollen, vier verschiedene Fragen

Der äußere Transport ist die Adresse, zu der ein Peer verbindet, also folgt seine Größe Ihrer öffentlichen Adressierung oder der des Anbieters, nie der Zahl der Geräte dahinter. Interne Tunnelverbindungen gibt es nur in Entwürfen, die eine virtuelle Schnittstelle nummerieren, und dort folgt die Zahl den Nachbarschaften der Topologie. Präfixe geschützter LANs folgen den realen Netzen und ihrem Wachstumsplan. Vom Anbieter reservierte Infrastruktur folgt dem, was der verwaltete Dienst dokumentiert.

Nur das Dritte davon hat einen Bezug dazu, wie viele Laptops das Büro enthält. Genau diese Verwechslung erklärt die meisten Diskussionen.

Schreiben Sie die vier Rollen als getrennte Spalten auf, bevor Sie einen Taschenrechner öffnen. Jede bekommt ihre eigene Zuteilung, ihren Verantwortlichen und ihre Wachstumsannahme, und keine erbt die Größe einer anderen. Hat ein Entwurf keine nummerierte interne Verbindung, ist diese Spalte leer statt klein, und eine leere Spalte ist ein Fakt, den es für den nächsten Prüfer festzuhalten lohnt.

Blöcke zählen: was ein /30 wirklich kostet

Eine Punkt-zu-Punkt-Verbindung braucht zwei Adressen und verbraucht einen Block, dessen Größe von der Plattform abhängt. Ein /30 enthält vier Adressen, von denen zwei üblicherweise nutzbar sind, also verbrauchen zwölf Verbindungen im Plan achtundvierzig Adressen, während sie vierundzwanzig Endpunkte bieten. Ein /31 enthält zwei Adressen, und beide sind nutzbar, was die Rechnung halbiert, aber nur dort, wo beide Enden es akzeptieren.

RFC 3021 definiert das Zwei-Adressen-Modell, und Unterstützung ist eine Eigenschaft der Endpunkte und des Dienstes, nicht der guten Absichten. Eine Anbieter-API kann ihre eigene Maskenanforderung für eine interne Tunneloption erzwingen, und ein allgemeiner RFC hebt eine dokumentierte Einschränkung nicht auf. Prüfen Sie, was Ihre Plattform angibt, bevor Sie das Budget zusammenfassen, denn der Unterschied zwischen achtundvierzig und vierundzwanzig Adressen entscheidet, ob der Plan in den reservierten Bereich passt. Rechnen Sie es durch, statt ihm am Ende eines langen Tages zu vertrauen.

ipcalc -n 10.44.12.0/30
ipcalc -n 10.44.12.4/31

Multiplizieren Sie erst, wenn die Topologie geklärt ist. Zwölf getrennte Verbindungen und ein Multipoint-Overlay mit zwölf Teilnehmern ergeben bei gleicher Standortzahl sehr unterschiedliche Summen.

Das Subnetz des verwalteten Gateways ist kein Client-Pool

Ein verwalteter Dienst reserviert oft ein Subnetz für seine eigene Gateway-Infrastruktur, und dieses Subnetz wird vom Dienst verbraucht statt an Clients ausgegeben. Es hat eine dokumentierte Größe, manchmal einen dokumentierten Namen und keinen Bezug dazu, wie viele Nutzer sich verbinden. Es als Adresspool für entfernte Rechner zu behandeln, erzeugt einen Entwurf, der sich am ersten geschäftigen Morgen erschöpft.

Lesen Sie die Anforderung des Anbieters als feste Kosten, so wie Sie eine Rackeinheit behandeln würden. Sie ist nicht Teil des Budgets für das geschützte Präfix.

Dieselbe Lesart gilt für Namen. Ein Subnetz, dessen dokumentierter Zweck Gateway-Infrastruktur ist, ist in diesem Dienst per Konvention Infrastruktur, und es umzubenennen, damit es zu Ihrem eigenen Schema passt, bricht die Bereitstellung, statt das Diagramm zu verbessern. Behalten Sie die Namen und Größen des Anbieters, und verwenden Sie Ihr eigenes Nummerierungsschema für die Teile, die Sie steuern.

Dokumentieren Sie den Plan, damit er den zweiten Standort überlebt

Ein Plan, der in einem Ingenieurskopf lebt, scheitert an der ersten Überschneidung zwischen einem Büropräfix und dem Standardbereich eines Heimrouters. Veröffentlichen Sie die Zuteilungen mit ihren Verantwortlichen und geben Sie an, welches Ende jeder Verbindung welche Adresse vergibt. Routen oder Selektoren müssen weiterhin angekündigt werden, denn eine interne Verbindung zu nummerieren veröffentlicht noch kein LAN.

Halten Sie die Wachstumsannahme hinter jedem Block fest, denn genau dieser Teil lässt sich von keinem späteren Leser allein aus den Adressen rekonstruieren.

Prüfen Sie den Plan dann gegen die unangenehmen Fälle: einen Standort, der mit einem Präfix kommt, das Sie bereits nutzen, eine Verbindung, deren fernes Ende jemand anderes verwaltet, und eine Region, deren Anbieteranforderung von der ersten dokumentierten abweicht. Erzwingt einer davon eine Neugestaltung, war das, was Sie hatten, ein Diagramm und keine Richtlinie. Ein Plan, der sie übersteht, ist kurz genug, um im Repository neben der Tunnelkonfiguration zu liegen, und genau dort wird die nächste Person danach suchen.