Loopback->DNS->NTP->VPN: Kettenreaktion

[Transcendence]

Hi,

folgendes etwas ungewöhnliches, unrsprünglich aus Zeiten von LCOS 6.x stammendes Setup, das ja nur 2 private Netze (Intranet und DMZ) verwalten konnte. Es sollte ohne VLANs für wenigstens etwas Trennung der Nutzergruppen sorgen:

- Eth1: DMZ (/24)

- Eth2: Intranet (/20), Anschluss Büro
- mit DHCP für ein /24-Gast-Subnetz des Intranets;
- die Bürorechner sind mit festen Netzwerkeinstellungen in einem anderen /24-Subnetz innerhalb des Intranet.
Auf diese Weise konnten sich Gäste mit ihren Laptops anschließen und in einem eigenen Subnetz den Internetzugang nutzen, ohne das Subnetz der Bürocomputer zu betreten.

- Eth3: Intranet (/20), Anschluss Privatwohnung
- mit DHCP für dasselbe /24-Gast-Subnetz wie im Büro. Die Privatrechner und Gäste nutzten das Gast-Subnetz.

Alle Router-Ports befinden sich im Private Mode, so dass von der Privatwohnung aus der Zugang zum Büronetz ganz unterbunden werden konnte.

Zwei Laptops aus dem Büro sollen auch von der Privatwohnung aus Zugang zum Internet erhalten. Aus diesem Grund erhielt der Router eine Loopback-Adresse: Seine IP-Adresse aus dem Büronetz. Damit war er auch in der Privatwohnung mit der GW-Einstellung der Büro-Laptops ansprechbar.

Der Router holt sich die Zeit beim Neutstart per NTP aus dem Internet.

Bis einschließlich LCOS-Version 7.22 funktionierte das einwandfrei. Seit der Version 7.26 trat wiederholt folgendes Phänomen auf:

VPN funktionierte nach einem Neustart des Routers nicht mehr. Nach einigen Tagen funktionierte der Zugang mit den Büro-Laptops in der Privatwohnung nicht mehr, dafür wieder VPN. In den Routereistellungen war die Loopback-Adresse durch eine anders benannte überschrieben, deren Wert betrug 0.0.0.0. Kunde versicherte jedes Mal glaubhaft, nichts angerührt zu haben.

Eine Rekonstruktion mit dem LANMonitor sowie traces über NTP und DNS ergab Folgendes:

Wurde der oben genannte Loopback-Eintrag gesetzt und der Router neu gestartet, zeigte LANMonitor an, dass die verwendeten VPN-Zertifikate noch nicht gültig seien, der Router lehnte folgerichtig die Verbindung ab. Ein Blick auf die Systemzeit des Routers ergab, dass diese nicht gesetzt wurde, also auf 00.00.0000 00:00:00 + Betriebszeit (entspricht 01.01.1900 + Betriebszeit) stand. Ein trace # ntp ergab, dass der Router von den Zeitservern keine Daten erhielt, ein trace # dns ergab als Grund, dass er die Namen dieser Server nicht auflösen konnte.

Entfernte man den Loopback-Eintrag, verschwand das Problem, jedoch konnten die Büro-Laptops in der Privatwohnung natürlich so nicht mehr ins Internet.

Entfernte man den Eintrag dagegen nicht, wurde er nach ein paar Tagen tatsächlich selbständig (???) überschrieben. Wenn ich es nicht selbst gesehen hätte, würde ich es wahrscheinlich nicht glauben.

Das ist sowohl mit der Version 7.26 als auch mit der 7.28 passiert. Bis da hin, also auch mit der 7.22, funktionierte es dagegen problemlos, so dass es auch unter 7.x unter Aufwandsgesichtspunkten weiter betrieben wurde.

Aufgrund der Probleme wurde nun unter Nutzung der neuen Fähigkeiten der 7.x-Versionen (mehrere dedizierte Netze pro Anschluss) eine neue Lösung eingerichtet, die ohne Loopback-Adressen, dafür mit einem externen DHCP-Server arbeitet, der mehrere Einzelnetze pro Anschluss versorgen kann. Diese Lösung wird vom Router zuverlässig unterstützt.

Es ist aus meiner Sicht jedoch mysteriös, dass das Setzen der Loopback-Adresse plötzlich derartige Probleme mit dem DNS verursacht. Entsprechende Versions-Hinweise über Änderungen sind auch nicht zu finden. Unter den Aspekten "systematische Fehlersuche" und "Verlässlichkeit des Zustands einer eingerichteten Konfiguration" finde ich es auch nicht akzeptabel, wenn Einstellungen nachträglich und anscheinend selbständig (???) überschrieben werden.

Vielleicht hilft diese Schilderung, Probleme mit dem DNS, die immer mal wieder thematisiert werden, weiter einzugrenzen.

Grüße
T.