Neue Funktionen
- Der Code für die Überwachung der LTE-Module wurde komplett überarbeitet. Diese Firmware-Version unterstützt nun zum ersten Mal vollständig die Modulversionen 10-01031 und 10-01032 für die USA und Kanada. Nun können auch die verwendeten Technologien besser analysiert werden; der Code meldet außerdem die/das aktuell genutzte Frequenz/Band.
- Der Startup-Code für Viprinet Router wurde optimiert. Dadurch geht die Inbetriebnahme eines Viprinet Hubs mit tonnenweise Tunneln nun wesentlich schneller vonstatten.
- Die Router haben nun eine maximale Anzahl an Tunneln, die konfiguriert werden können.
WICHTIGER HINWEIS: Das bedeutet nicht, dass der Router tatsächlich in der Lage sein wird, so viele Tunnel gleichzeitig bei annehmbarer Leistung zu halten - dies hängt auch von der Anzahl der Channels pro Tunnel und von der Komplexität der QoS-Regeln ab.
Hier ist die Anzahl maximal zulässiger Tunnel je Produkt:- 300: 25
- 500: 25
- 1600/1610/2610/1620/2620: 50
- 1000/1020: 100
- 2000/2020: 150
- 5000/5010: 500
- Bis jetzt nutzte das Hub-Redundanzsystem ausschließlich Ethernet-Broadcast bei der Kommunikation von Hubs untereinander. Aufgrund einer technischen Limitierung im verwendeten Kommunikationsprotokoll konnten Hubs nur dann Konfigurationsdateien teilen, wenn deren komprimierte Größe unter 64k lag. Leider war der Benutzer nicht in der Lage, herauszufinden, wie groß die aktuelle Konfiguration ist. Wenn die komprimierte Konfigurationsdatei etwas größer war als 64k, versagte das Hub-Redundanzsystem beim Synchronisieren der Konfigurationsdateien. Bei einigen Hub 5010-Installationen mit einer großen Anzahl an Tunneln und QoS-Konfigurationen wurde diese Limitierung tatsächlich auch erreicht.
Zusätzlich gab es beim Broadcasting Protocol ein grundsätzliches Problem: Wenn viele VPN Hubs zur gleichen Zeit im Betrieb waren, konnte es bei mehreren Hubs passieren, dass sie ihre Konfiguration exakt zur selben Zeit an den Hotspare schickten. In diesem Fall erhielt der Hotspare aufgrund von Fragmentierung manchmal überhaupt keine Konfiguration. Dieses Problem verschlimmerte sich, wenn in einer einzelnen Redundanzgruppe mehrere Hotspares liefen.
Wir haben das Hub-Redundanzsystem so verbessert, dass die hauptsächliche Kommunikation noch immer über Broadcasts läuft, für die Übertragung von Konfigurationsdateien aber nun eine direkte TCP-Verbindung zum Hotspare aufgebaut wird. Daher ist die Größe der Hub-Konfigurationsdateien nun unlimitiert. Das neue Protokoll wurde abwärts kompatibel gestaltet. Das bedeutet dass Hotspare Hubs, die mit derselben Cutting Edge-Firmware laufen, immer noch produktive Hubs bedienen können, die mit der Stable Firmware-Version laufen und ihre Konfiguration noch nicht per TCP synchronisieren können. Wir empfehlen dennoch, bei allen Hubs in einer Redundanzgruppe dieselbe Firmware-Version zu verwenden. - Bis jetzt konnte es passieren, dass Viprinet-Router manchmal Traffic als nicht routbar markierten, wenn der Tunnel down war, während der Traffic-Flow aufgebaut wurde. Seit der letzten Stable Firmware-Version wurde diese Restriktion noch etwas strenger: Jeglicher Traffic-Flow, der aufgebaut wurde, bevor der Tunnel bestand, wurde für immer als nicht routbar markiert. Wir haben nicht erwartet, dass das je ein Problem wäre - die meisten gesunden Protokolle brechen bei so etwas ohnehin ab und verbinden neu. Das ist aber z.B. bei ISAKMP von IPSec nicht der Fall, einem völlig hirnverbranntem Protokoll: Es nutzt per Konvention immer den UDP Quell- und Zielport 500. Dadurch wird es unmöglich, zwischen diesen ISAKMP-Flows zu unterscheiden, was unter anderem auch bei NAT Gateways Probleme verursacht. Bei Viprinet wurde, wenn ein IPSec Gateway einen IPSec-Tunnel aufbaute, bevor der Viprinet-Tunnel bestand (z.B. weil der Viprinet-Router, aber nicht das IPSec Gateway rebootet wurde), der ISAKMP-Flow als permanent nicht routbar markiert. Das konnte passieren, weil das IPSec Gateway nie "abbrach", und selbst wenn, dann würde ein neues IPSec-Setup genauso aussehen wie das alte, da die UDP Quell- und Zielports sich nicht änderten.
Wenn also das IPSec Gateway keine vernünftigen Timeouts benutzt, konnte es passieren, dass IPSec-Tunnel durch einen Viprinet-Tunnel für immer stecken blieben.
Das verursachte keine Probleme mit IPSec Gateways, die wir intern testen konnte, denn diese warteten einfach einige Sekunden vor einem erneuten Versuch, falls der ISAKMP-Handshake fehlschlug. Bis dahin zeigte der Flow vom UDP-Port 500 im Viprinet-Router eine Zeitüberschreitung, und das neue ISAKMP-Setup wurde als neuer Flow betrachtet, der dank des Viprinet-Tunnels nun als routbar markiert wurde.
Wie wir gelernt haben, verhalten sich nicht alle IPSec Gateways so - einige hämmern ohne Unterlass für den Fall, dass der ISAKMP-Handshake nicht funktioniert. Das ist unklug, aber leider Realität.
Wir haben das Routing-Design innerhalb der Viprinet-Router so geändert, dass nun diese Art von Problemen bewältigt werden kann, während die Geräte weiterhin optimale Leistung bringen.
Traffic-Flows, die als unzulässig/nicht routbar markiert werden, werden nun alle 2 Sekunden darauf überprüft, ob es in der Zwischenzeit möglich geworden ist, sie zu routen. Auf diese Weise haben wir weder hohe Last durch Systeme, die den Router mit nicht routbaren Ziel-IPs fluten (was zumindest eine Art von DoS ermöglichen würde), noch haben wir Probleme mit Protokollen, die immer denselben Flow hämmern, während der Viprinet-Tunnel noch nicht aufgebaut ist.
Es ist unmöglich, alle verfügbaren IPSec Gateway-Kombinationen zu testen, aber bei denen, die wir testen konnten, wurden IPSec-Tunnel typischerweise nach einigen Sekunden (wieder) aufgebaut, nachdem auch der Viprinet VPN-Tunnel wieder kam.
Fehlerbehebungen
- Die vorherige Cutting Edge Firmware-Version funktionierte nicht mit der 50-00500 Projektrouter-Serie. Das Problem wurde mit dieser Firmware-Version behoben.
- Ein Fehler wurde behoben, der durch einen SSL Handshake-Feler unter seltenen Umständen den Aufbau eines Tunnel-Channels zum VPN Hub abbrechen lassen konnte.