Am 19. Oktober ging unser Technikblog mit den ersten neun Artikeln online. Die Website lief auf einer eigenen virtuellen Maschine, die verschlüsselte Verbindung über HTTPS funktionierte und der Aufruf über das Handy gelang. Bis dahin mussten wir allerdings auch ein ausgefallenes WLAN und eine verzögerte Namensauflösung untersuchen.
An solchen Tagen zeigt sich, wie viele Dinge zusammenpassen müssen, bevor eine Website im Browser erscheint. Der Webserver ist ein Teil davon. Netzwerktrennung, Adressvergabe, Routing, Namensauflösung und Zertifikate gehören genauso dazu.
Warum beim Blogstart auch die Firewall und das WLAN eine Rolle spielten
Bei der Vorbereitung trafen Änderungen am Internetzugang, eine Netzumstellung und die Bereitstellung einer öffentlichen Website zusammen. Ein bestehender WLAN-Zugang war von diesen Arbeiten ebenfalls betroffen.
Die Aufgaben mussten deshalb getrennt betrachtet werden: bestehende Verbindungen erhalten, die neue Website bereitstellen und die vorgesehenen Netzgrenzen kontrollieren. Eine neue Anwendung kann Abhängigkeiten sichtbar machen, die zunächst nichts mit dem Webserver zu tun haben.
Bei einer solchen Umstellung müssen interne Dienste, drahtlose Zugänge und öffentlich erreichbare Anwendungen ihre vorgesehenen Netzgrenzen behalten. Eine Firewall kann mehrere Bereiche verwalten und für jeden festlegen, welche Verbindungen erlaubt sind.
Die Funkverbindung zu einem Gerät kann bestehen bleiben, obwohl dem vorgeschalteten Router der Internetzugang fehlt. Deshalb lohnt sich bei einer WLAN-Störung die Prüfung der vollständigen Verbindungskette.
Ein eigener Platz für den Blog
Für eine öffentliche Website sollten Leserzugriff und Administration klar getrennt geplant werden. Leser benötigen die veröffentlichten Seiten, keinen Zugang zu Verwaltungsoberflächen oder anderen Diensten.
Für den Blog haben wir die Artikel vorab als statische Dateien erzeugt und mit Caddy bereitgestellt. Ein solches Verfahren benötigt auf dem Webserver weder ein redaktionelles CMS noch eine Datenbank. Zur Bereitstellungsplanung gehört ausserdem die Netztrennung, etwa über einen abgegrenzten Bereich für öffentlich erreichbare Dienste.
Debian haben wir aktualisiert und nach dem Neustart unter anderem den neuen Kernel, fehlgeschlagene Dienste und die Zeitsynchronisation kontrolliert. Erst danach ging es mit den Containern weiter. So liess sich die Fehlersuche später auf eine bereits geprüfte Grundlage stützen.
Weshalb zuerst das WLAN wieder laufen musste
Bei der Netzumstellung bekam der bestehende WLAN-Zugang Vorrang. Ein Router meldete sich als offline; ein Neustart allein half nicht. Vor der weiteren Prüfung der Website sollte dieser bereits genutzte Zugang wieder funktionieren.
Die zentral gesammelten Firewall-Logs zeigten die Ursache: Die DHCP-Anfragen des WLAN-Routers blieben an einer Sperrregel zur Firewall hängen. DHCP ist der Dienst, über den ein Gerät automatisch seine IP-Adresse und weitere Netzwerkeinstellungen erhält. Hier ging es um die Adresse des Routers an seinem Anschluss zur Firewall. Ohne sie konnte er seine WLAN-Geräte nicht ins Internet weiterleiten.
Die Trennung der Netzbereiche war also bereits wirksam, blockierte aber auch einen benötigten Dienst der Firewall selbst. Eine Regel für den späteren Internetverkehr löste dieses Problem nicht: Zuerst musste der Router seine Netzwerkeinstellungen beziehen können.
Nach Korrektur der benötigten DHCP-Freigabe prüften wir nicht nur den Regelzähler. Ein Paketmitschnitt und die DHCP-Ereignisse mussten auch Antwort und Adressvergabe zeigen. Anschliessend funktionierte der Internetzugriff über das WLAN wieder.
Die zusätzliche Prüfung hat sich gelohnt. Ein Regelzähler zeigt, dass eine Regel getroffen wurde. Ob das Gerät tatsächlich wieder arbeiten kann, muss man am Gerät und am vollständigen Verbindungsablauf prüfen.
Bei DNS half die verbleibende Cachezeit
Nachdem der WLAN-Zugang wieder funktionierte, ging es um die Adresse der Website. DNS übersetzt einen Namen wie eine Blogdomain in die IP-Adresse des zuständigen Anschlusses. Für unsere Blogdomain änderten wir den öffentlichen DNS-Eintrag auf die neue Internetadresse. Im Verwaltungsportal war der neue Wert bereits veröffentlicht. Der Server bekam bei seinen Abfragen trotzdem noch die alte Adresse zurück.
DNS-Antworten werden für eine bestimmte Zeit zwischengespeichert. Mit einer Abfrage liess sich neben der Adresse auch diese verbleibende Cachezeit anzeigen. Sie erklärte, weshalb der bisherige Wert weiterhin verwendet wurde. Wir mussten die Änderung nicht immer wieder neu speichern, sondern konnten den Ablauf des vorhandenen Cacheeintrags beobachten. Später lieferte die Abfrage die erwartete neue Adresse.
Bei DNS-Änderungen müssen die Einträge anderer Dienste berücksichtigt werden. Eine Website und die Mailzustellung können dieselbe Domain verwenden, haben aber unterschiedliche Aufgaben und Abhängigkeiten.
Ein Konfigurationstest fing einen Fehler ab
Bevor Caddy dauerhaft startete, prüften wir seine Konfiguration mit genau dem Containerimage, das anschliessend laufen sollte. Dabei fiel ein falscher Parameter in der Konfiguration für den automatischen Zertifikatsbezug auf. Nach der Korrektur war die Konfiguration gültig.
Die Containerimages haben wir über konkrete Versionen und ihre Prüfsummen, die sogenannten Digests, festgelegt. Damit bleibt nachvollziehbar, welches Image wir geprüft und gestartet haben. Sicherheitsupdates müssen wir trotzdem aktiv einspielen: Ein festgelegter Digest wechselt nicht automatisch auf eine korrigierte Version.
Die Artikel übertrugen wir als geprüftes Archiv in ein eigenes Releaseverzeichnis. Ein Verweis bestimmt, welche Version Caddy ausliefert. Nach dem Start konnte Caddy das Zertifikat beziehen, und die Logs zeigten erfolgreiche HTTPS-Antworten. Der anschliessende Test am Handy bestätigte den öffentlichen Zugriff.
Von aussen erreichbar und intern zunächst gesperrt
Ein interner Test gelang zunächst nicht, obwohl der externe Aufruf funktionierte. Bei einer öffentlichen Namensauflösung muss der interne Verbindungsweg gesondert betrachtet werden. Je nach Aufbau kommen NAT-Loopback oder eine passende interne Namensauflösung infrage.
Für die Eingrenzung testeten wir eine Verbindung mit dem öffentlichen Domainnamen, gaben aber ausdrücklich das zu prüfende Ziel vor. So liessen sich Erreichbarkeit und Zertifikatsprüfung von der normalen Namensauflösung unterscheiden. Der anschliessende reguläre Aufruf musste denselben Funktionstest bestehen.
Öffentliche Erreichbarkeit und interner Zugriff sind unterschiedliche Wege. Der erfolgreiche Handytest konnte den internen Test deshalb nicht ersetzen.
Was zum dauerhaften Betrieb gehört
Am Ende dieses Abends war die Website erreichbar und die Artikel waren installiert. Auch die zuvor gestörte Verbindung funktionierte wieder. Die einzelnen Funktionsprüfungen waren damit nachvollziehbar abgeschlossen.
Zur weiteren Planung gehörten Kommentare und meine Antworten darauf. Dabei sollen Leser erkennen können, welche Antworten tatsächlich von mir stammen. Anmeldung, geschützte Betreiberkennzeichnung, Schutz vor Namensmissbrauch und Moderation waren deshalb weitere Aufgaben. Ein Kommentardienst war beim Start noch nicht eingerichtet.
Zum dauerhaften Betrieb gehören zusätzlich Namensvarianten, Sicherung, Wiederherstellung, Monitoring und Updates. Der Abend hatte gezeigt, wie eng Website und Netzwerkbetrieb zusammenhängen: Eine funktionierende Anwendung braucht passende Netzwerkeinstellungen, erlaubte Verbindungen und einen geprüften Zugriffsweg.