Ein größerer VPN-Pool ist kein größeres Sitzungslimit

Ein /22 enthält 1,024 IPv4-Adressen, und diese Zahl wird leicht mit Kapazität verwechselt. Sie beschreibt, wie viele Zuweisungen der Bereich unterstützen könnte, nicht wie viele Sitzungen das Gateway annimmt oder wie viel Verkehr es weiterleiten kann. Hinter jeder Antwort stehen drei getrennte Zählungen, und sie versagen auf unterschiedliche Weise. Der Vergleich dieser drei ist der Weg, eine Ablehnung der richtigen zuzuordnen.

Der Pool, die Berechtigung und die Arbeitslast werden in verschiedenen Einheiten und von verschiedenen Verantwortlichen gezählt.

Was der Pool tatsächlich bietet

Beginnen Sie mit den tatsächlichen Grenzen statt mit der Maske. Die Subnetz-Topologie entscheidet, wie viele Adressen der Server vergeben kann, feste Zuweisungen und Reservierungen verbrauchen einige, und Netz- sowie Broadcast-Adresse stehen nicht zur Verfügung. Ein /22 bietet 1,024 theoretisch und weniger in der Praxis, was bereits genügt, um die erwartete Rechnung zu brechen. Überschneidungen mit Netzen, die die Clients erreichen müssen, können einen Bereich ausschließen, der großzügig aussah. Prüfen Sie, ob der Zuweisungsmechanismus den vorgeschlagenen Bereich unterstützt, bevor Sie ihn ankündigen.

Ein größerer Pool beseitigt genau eine Einschränkung. Er berührt weder Annahmegrenzen noch Lizenzierung oder Weiterleitungsdurchsatz, und ein Subnetz zu vergrößern, ohne Routen und Zugriffsrichtlinie zu ändern, erzeugt einen Bereich, den niemand erreichen kann.

Was die Lizenz tatsächlich erlaubt

Die unterstützte Nebenläufigkeit der Plattform und die Produktberechtigung sind zwei weitere Zahlen, und sie stimmen häufig nicht überein. Berechtigungen können Benutzer, Geräte oder gleichzeitige Sitzungen zählen, und diese Maße sind nicht austauschbar. Bestellleitfäden der Anbieter zeigen, wie unterschiedlich die Modelle sein können, weshalb die Peer-Zahl eines alten Datenblatts nicht in eine neue Bereitstellung übernommen werden sollte. Lesen Sie die Vereinbarung, die für den Dienst gilt, den Sie tatsächlich betreiben.

Eine Lizenz, die benannte Benutzer zählt, nimmt nicht deshalb mehr Geräte auf, weil im Pool Platz ist.

Was das Gateway tatsächlich tragen kann

Die dritte Zählung ist die Arbeitslast. Schätzen Sie den Verkehr, den diese Sitzungen gemeinsam erzeugen: Paketraten, Authentifizierungsspitzen, Verschlüsselungskosten und die jeweils aktivierten Richtlinienfunktionen. Interaktive Sitzungen und Massenübertragungen landen sehr unterschiedlich auf derselben Maschine. Ein Gateway kann freie Adressen und lizenzierte Annahme bereithalten, während die beabsichtigte Last übersteigt, was es weiterleiten kann. Kapazitätsplanung, die das Funktionsset ignoriert, liefert eine Zahl, die nur in einem Labor mit allem abgeschaltet gilt.

Eine Ablehnung ist der Moment, in dem Sie nachsehen, was das Gateway für diesen Versuch protokolliert hat: ein Zuweisungsereignis, eine Annahmeentscheidung oder einen hängenden Authentifizierungsaufruf. Diese drei verlangen unterschiedliche Korrekturen, und Raten von der Clientseite trifft selten die richtige.

Ordnen Sie die Ablehnung zu, bevor Sie etwas ändern

Der nützliche Vergleich ist der zwischen den drei Zählungen und der beobachteten Störung. Ist der Pool voll, erweitern Sie ihn und aktualisieren Sie die Routen und die Richtlinie, die ihn beschreiben. Wird die Annahme verweigert, während noch Adressen übrig sind, liegt die Einschränkung anderswo. Werden Sitzungen angenommen und bricht die Leistung ein, ist das Problem die Kapazität und nicht eine der beiden Grenzen.

Halten Sie fest, welche Zählung erschöpft war, wann es geschah und was sich danach geändert hat. Diese Aufzeichnung verhindert, dass die nächste Untersuchung wieder bei der Subnetzmaske beginnt.

Einen Pool zu vergrößern ist eine Änderung in einer Zeile mit dreiteiliger Nacharbeit: Routen, Richtlinie und ein erneuter Test.