Ist WireGuard produktionsreif? Die Antwort liegt nicht im Protokoll

Man fragt, ob WireGuard produktionsreif ist, was nach einer Frage zur Kryptografie klingt und in Wahrheit eine Frage nach Ihrer Umgebung ist. Das Protokoll wird seit Jahren geprüft; der Rollout muss weiterhin beantworten, ob Ihre Netze seinen Transport tragen, wer Geräte aufnimmt und außer Betrieb nimmt und wer das Paket an beiden Enden patcht. Diese Antworten unterscheiden sich zwischen zwei Servern in einem Rack und tausend Notebooks. Das Protokoll ist in beiden Fällen dasselbe, der Betrieb nicht.

Die Frage hinter der Frage

Was man meist wissen will, ist, ob man sich auf ein Design festlegen kann, das einen in einem halben Jahr nicht blamiert. Das ist eine Rollout-Frage mit vier Teilen, und jeder Teil kann unabhängig von den anderen scheitern. Gute Antworten auf drei davon gleichen den vierten nicht aus.

Eine alte Warnung zu einem Vorab-Snapshot ist eine Tatsache über diesen Snapshot, kein dauerhaftes Etikett auf jedem späteren Paket. Ebenso wenig kann ein Blogbeitrag Ihre konkrete Kombination aus Kernel, Client, Netz und Personal für reif erklären. Die Arbeit besteht darin, die Kombination explizit zu machen und sie zu prüfen.

Behandeln Sie Bereitschaft als eine Menge von Toren, die Sie entweder bestehen oder als offen festhalten. Das macht aus einer Debatte eine Checkliste mit Verantwortlichen. Es macht außerdem die offenen Punkte für jeden sichtbar, der freigibt, statt sie in einem Pilotbericht zu begraben.

Tor eins: der Pfad muss UDP tragen

WireGuard überträgt seinen Verkehr über UDP und dokumentiert, dass es weder einen TCP-Modus noch eine Verkehrsverschleierung bietet. Ein Design, das darauf baut, dass er wie gewöhnlicher Webverkehr aussieht, oder darauf, den Port zu ändern, um TCP-Verhalten zu erhalten, ruht auf einer Annahme, die die Software nicht unterstützt.

Das erste Tor ist also eine Bestandsaufnahme, kein Test auf einer Maschine. Listen Sie die Zugangsumgebungen auf, in denen Ihre Nutzer tatsächlich arbeiten, prüfen Sie dann den freigegebenen UDP-Pfad in jeder davon und entscheiden Sie, was passiert, wenn er nicht verfügbar ist.

Eine Verbindung, die aus dem Büro funktioniert, beweist nichts über ein Hotelnetz, eine Campus-Firewall oder einen Mobilfunkanbieter, der UDP anders behandelt. Diese Umgebungen sind der Grund, warum Fernzugriffs-Rollouts nach einem erfolgreichen Pilot scheitern. Der Pilot war nicht falsch; er war eng. Ihn zu erweitern, ist das Tor.

Schreiben Sie auch den Rückfallweg auf. Wenn die Antwort lautet, dass es keinen gibt, ist das eine Entscheidung, die man vorab benennen sollte, statt sie auf einer Dienstreise zu entdecken.

Tor zwei: jemand muss die Schlüssel besitzen

WireGuard-Peers authentifizieren sich mit Schlüsseln, ein Paar pro Teilnehmer. Das ist einfach zu beschreiben und betrieblich anspruchsvoll, weil nichts im Protokoll ein Gerät aufnimmt, nachhält, wer welchen Schlüssel hält, oder den Zugang entfernt, wenn ein Notebook verloren geht. Das Protokoll setzt voraus, dass die Schlüssel bereits stimmen, und Korrektheit ist jemandes Arbeit.

Benennen Sie die Person, die ein Gerät aufnimmt, den Datensatz, der einen öffentlichen Schlüssel einer Person und einem Gerät zuordnet, und das Verfahren zum Entfernen. Wenn das Entfernen davon abhängt, sich zu merken, wohin Kopien einer Konfigurationsdatei installiert wurden, ist das Verfahren nicht fertig.

Wählen Sie während des Piloten ein Gerät und nehmen Sie es von Anfang bis Ende außer Betrieb. Diese Übung liefert nützlichere Informationen als ein weiterer Konnektivitätstest, weil sie die Lücken in Ihren Aufzeichnungen offenlegt.

Tor drei: das Paket braucht einen Betreuer

WireGuard kann als Implementierung im Kernel, als Distributionspaket oder als Client im Userspace kommen, und jeder hat seinen eigenen Aktualisierungspfad. Die operative Frage ist, welche Variante Sie betreiben, woher sie stammt und wer eine Sicherheitsmeldung einspielt.

Wir nutzen WireGuard ist kein Inventar. Es benennt weder das zu patchende Paket noch die Version auf dem Gateway noch die Person, die ein schlechtes Update zurückrollen kann.

Tor vier: akzeptieren Sie die Arbeitslast, nicht den Handshake

Abnahmekriterien sollten beschreiben, was Nutzer tun. Eine interne Anwendung erreichen, ihren privaten Namen auflösen, an einem nicht freigegebenen Ziel abgewiesen werden und das definierte Verhalten befolgen, wenn der Tunnel ausgefallen ist, sind alle beobachtbar, und ein erfolgreicher Handshake ist keines davon.

Lassen Sie diese Prüfungen durch einen Netzwechsel, einen Geräteneustart und ein Wartungsfenster des Gateways laufen, denn genau in diesen Übergängen brechen Rollouts.

Bewahren Sie die Belege neben den Kriterien auf, einschließlich des lokalen Zustands, der sie erzeugt hat:

wg show
ss -lunp | grep 51820
ip -4 route get 10.63.0.1

Ein grüner Test in einem ruhigen Netz mit einem Notebook ist eine Anfangsbeobachtung. Er ist keine Aussage über Zuverlässigkeit, und ihn als eine zu behandeln, ist der Weg, auf dem aus einem funktionierenden Design ein Design wird, dem man vertraut.