Nachdem uns nun das neue Subnetz für den Betrieb des OpenVPN-Gateways zugeteilt wurde, gibt es mehr Probleme, als erwartet:
Um auch in Netzen Zugriff zu gewähren, die den Internetzugriff nur via Proxyserver gewähren, läuft der VPN-Server auf dem HTTPS-Port 443. Dieser ist meist entsprechend offen.
Ursprünglich war es geplant, normal den Standard-Port von OpenVPN zu verwenden, und somit zwei Instanzen des VPN-Servers zu starten. Jedoch müssten wir dann – je nach verwendeten Port – unterschiedliche VPN-Subnetze vergeben, was sich jedoch nicht mit der zentralen Authentifizierung am RADIUS-Server vereinbaren lässt.
Somit wird es nur eine Instanz auf Port 443 geben. Nachteile? Keine – die Verbindung auf diesen Port ist so gut wie immer möglich.
Des weiteren ist es geplant, statische, öffentliche IP-Adressen direkt an VPN-Clients zu vergeben. Leider scheitert die direkte Vergabe an OpenVPN und dem Routing an sich: Erhält der Client eine IP aus dem Subnetz zugewiesen, in dem sich der Gateway befindet, so ist nach dem (erfolgreichen) Verbindungsaufbau keine Kommunikation mit dem Gateway mehr möglich: Klar, die Pakete zum Gateway sollen über diesen laufen … was natürlich Probleme macht.
Eine Zuweisung von IPs aus dem neuen Subnetz ist ebenfalls nicht möglich, da OpenVPN sich weigert, die /27er Subnetzmaske anzuerkennen.
Mögliche Abhilfe wird sich u.U. durch statisches NAT ergeben: Pakete, die an eine bestimmte öffentliche IP ankommen, werden vom Gateway modifziert, und an die interne IP des Clients umgeleitet. Ausgehende Pakete erhalten als Quelle dann nicht die interne IP, sondern die öffentliche.
Details nach Abschluss der ersten Tests 😉
