VPN und Website auf einem Server ohne Kollisionen betreiben

Teilen Sie einen Host zwischen einer öffentlichen Website und einem VPN, erben Sie zwei Fragen statt einer: was wo lauscht und wer wen authentifiziert. Beantworten Sie beide, bevor Sie eine Konfigurationsdatei anfassen, denn die Standardwerte sind auf Arten falsch, die erst unter Last sichtbar werden. Eine Seite, die über HTTPS lädt, beweist, dass der Web-Listener antwortet, und nichts über den Peer-Listener. Was folgt, ist eine Entscheidungsreihenfolge, die verhindert, dass die beiden einander auffressen.

Entscheiden Sie, was auf welcher Adresse und welchem Transport lauscht

Schreiben Sie eine Tabelle mit drei Spalten, Adresse, Transport und Port, und einer Zeile pro Dienst, einschließlich der administrativen Schnittstelle. TCP 443 für die Website und UDP 443 für das VPN sind kein Konflikt, auch wenn die Zahlen übereinstimmen, weil der Transport unterschiedlich ist. Zwei Dienste auf derselben Adresse, demselben Transport und Port brauchen eine Regelung, die die Implementierung dokumentiert, nicht eine, die Sie während eines Ausfalls erfinden. Diese Tabelle ist auch das Artefakt, das die nächste Änderung überprüfbar macht.

Getrennte Adressen oder ein zweiter Port machen Eigentum in einem Paketmitschnitt sichtbar, und das ist mehr wert als Eleganz. Manche VPN-Implementierungen unterstützen das Teilen eines Ports mit einem Webserver, aber der Mechanismus ist spezifisch: Der Daemon prüft die ersten Bytes und leitet Verkehr weiter, der nicht sein eigenes Protokoll ist. Ein generischer HTTP-Reverse-Proxy tut das nicht, und das Umschreiben von Headern wird ihn keinen verschlüsselten Tunnel-Handshake verstehen lassen. Lesen Sie die Bereitstellungshinweise des Protokolls, etwa die OpenVPN-Listener-Dokumentation, und folgen Sie der Regelung, die sie beschreibt.

Entscheiden Sie, welche Identität zu welchem Dienst gehört

Ein Browserzertifikat und ein VPN-Peer-Nachweis sind verschiedene Objekte mit verschiedenen Vertrauensmodellen. Das Web-Zertifikat wird von einer öffentlichen Stelle validiert und nennt einen Hostnamen, während der Peer-Nachweis ein Gerät oder einen Benutzer gegenüber dem Konzentrator authentifiziert und selbstsigniert oder intern ausgestellt sein kann. Eines als das andere wiederzuverwenden funktioniert in engen Fällen und ist die Kopplung selten wert. Die Verifikation abzuschalten, damit ein gemeinsames Zertifikat passt, ist kein Trennungsplan; es entfernt die Prüfung, die dem Nachweis Bedeutung gab.

Halten Sie die beiden Speicher unabhängig und notieren Sie, welche Stelle welchen ausstellt. Wird einer rotiert, sollte der andere keine Änderung brauchen, und wenn doch, ist die Kopplung das, was zu beheben ist.

Entscheiden Sie, wo die Administration lebt

Die administrative Schnittstelle des VPN gehört auf einen Verwaltungspfad, niemals auf den öffentlichen Listener, auch wenn der Host bereits das Internet bedient. Ein Webserver auf 443 bedeutet nicht, dass die Peer-Konsole von überall erreichbar sein sollte, und die Konsole ist meist das wertvollere Ziel. Binden Sie sie an eine Loopback- oder Verwaltungsadresse, beschränken Sie sie nach Quelle und halten Sie einen Wiederherstellungspfad, der nicht davon abhängt, dass der Tunnel steht. Der Wiederherstellungspfad ist wichtig, weil der übliche Fehler darin besteht, sich auszusperren, während man die Sperre behebt.

Schreiben Sie enge Firewall-Regeln, eine pro Listener, und benennen Sie die Schnittstelle oder das Dienstkonto, wo die Plattform es unterstützt. Breite Regeln, die den Host öffnen, weil die Website 443 braucht, sind der Weg, auf dem administrative Schnittstellen in Scanner-Indizes landen.

Prüfen Sie diese Regeln gegen die Listener-Tabelle, wann immer ein Dienst hinzukommt. Die Prüfung ist billig, und sie fängt die Regel ab, die jemand um zwei Uhr morgens hinzugefügt hat.

Entscheiden Sie, was zu tun ist, wenn die beiden streiten

Einen Host zu teilen heißt, CPU, Speicher, Dateideskriptoren und Bandbreite zu teilen, und die umstrittene Ressource ist nicht immer die offensichtliche. Eine ausgelastete Website kann die Verbindungstabelle füllen, Arbeitsslots erschöpfen oder die Warteschlange der Platte so hart belasten, dass die VPN-Protokollierung stockt. Beobachten Sie die Nutzung pro Dienst statt der Summen des Hosts, denn ein Durchschnitt verbirgt, welcher Prozess hungert. Wenn eine Arbeitslast die andere wiederholt stört, isolieren Sie sie, statt um das Symptom herum zu optimieren.

Isolation kann ein Container sein, ein cgroup-Limit, eine separate Warteschlange oder ein zweiter Host, und die richtige Wahl hängt davon ab, welche Ressource streitet. Eine Portänderung behebt hier nichts, und eine größere Instanz behebt nichts, wenn das Limit eine gesättigte Warteschlange ist. Entscheiden Sie mit einer Messung: Benennen Sie die Ressource, lasten Sie sie aus, und wählen Sie dann die kleinste Isolation, die die Konkurrenz beseitigt.

Prüfen Sie von außen, dann erneut nach einem Neustart

Testen Sie von einem Gerät, das nicht im eigenen Netz des Hosts ist: Laden Sie die Website, bauen Sie den Tunnel auf und erreichen Sie eine Ressource, die ihn erfordert. Starten Sie dann jeden Dienst einzeln neu und wiederholen Sie den anderen Test, denn ein Neustart ist der Moment, in dem eine geteilte Listener-Regelung ihre Reihenfolge verliert. Startet das VPN vor dem Webserver, dem der geteilte Port gehört, hängt sich der Teilungsmechanismus vielleicht nie an, und das Symptom ist ein Tunnel, der gestern funktionierte. Machen Sie die Abhängigkeit in der Unit-Reihenfolge explizit.

Bestätigen Sie dann die Grenzen: Die Website antwortet auf ihrem Port, das VPN antwortet auf seinem eigenen, und die administrative Schnittstelle antwortet nur vom Verwaltungspfad aus. Notieren Sie das Ergebnis neben der Listener-Tabelle mit dem Datum. Ein Host, der alle drei Prüfungen nach einem Neustart besteht, ist ein Host, den Sie ohne Einweisung an jemand anderen übergeben können.