Archiv für September 2010

strongSwan: We have no ipsecN interface for either end of this connection

Vor einigen Tagen hatten wir das Problem, dass die VPN-Verbindung zu einer Außenstelle nach einem dortigen Stromausfall nicht wiederhergestellt werden konnte. Zwar war der Rechner (Debian mit strongSwan) nach dem Stromausfall automatisch wieder hochgefahren, die VPN-Verbindung allerdings nicht gestartet. Das manuelle Initiieren der Verbindung führte zu folgender Fehlermeldung:

debian:~# ipsec up berlin-bonn
022 "test": we have no ipsecN interface for either end of this connection

Das externe Interface des Rechners ist direkt an einem ADSL-Modem angeschlossen und stellt beim Booten die Internetverbindung via PPPoE her. Ebenfalls während des Bootvorgangs und parallel zur Einwahl beim Provider wird außerdem strongSwan gestartet:

debian:~# ls -lahF /etc/rcS.d/
S39ifupdown -> ../init.d/ifupdown
S40networking -> ../init.d/networking
S43firewall -> /etc/init.d/firewall
S44ipsec -> /etc/init.d/ipsec

In diesem Fall war strongSwan bereits gestartet, bevor die PPPoE-Einwahl beim Provider abgeschlossen war. Dies führte dazu, dass strongSwan das externe Interface nicht kannte und damit zum beschriebenen Problem. Lösen lässt es sich mit einem Neustart von strongSwan, sobald das entsprechende Interface verfügbar ist.

Um das Problem künftig zu vermeiden, lasse ich strongSwan kurz vor Abschluss des Bootvorgangs mittels Script beenden und nach einer Wartezeit von fünf Sekunden neu starten:

#!/bin/sh
#
### INFO ###
#
# /etc/init.d/ipsec-delay
# Neustart von ipsec, damit es das ppp0 Interface erkennt
#
### INFO ###

/etc/init.d/ipsec stop
sleep 5
/etc/init.d/ipsec start

So ist sichergestellt, dass das erforderliche Interface in strongSwan zur Verfügung steht und die VPN-Verbindung auch infolge eines unerwarteten Herunterfahrens automatisch wiederhergestellt werden kann.

Advertisements

NetBIOS Namensauflösung unter Windows funktioniert nicht

Einer unserer Anwender arbeitet in einer Außenstelle, die aus lediglich einem Switch, einem Router und zwei Rechnern besteht: Dem Notebook des Mitarbeiters und einem „Server“, beide mit Windows XP. Mittels Offlinedateien synchronisiert das Notebook Daten mit einer Freigabe des Servers. Das klappte plötzlich nicht mehr.

Nach einigen Tests stellte sich als Ursache schnell eine kaputte Namensauflösung heraus. Der in der Offlinesynchronisation verwendete Hostname des Servers konnte vom Notebook nicht aufgelöst werden und das Resulat war eine nicht mehr funktionierende Synchronisation.

Weil eine (interne) DNS-Auflösung im Netzwerk nicht existiert, musste der Fehler irgendwo bei der Namensauflösung via NetBIOS liegen. Und in der Tat förderte ein nbtstat -a hostname kein Ergebnis zu Tage:

C:\>nbtstat -a xp-server

LAN-Verbindung:
Knoten-IP-Adresse: [192.168.61.10] Bereichskennung: []

    Host nicht gefunden.

…während der Hostname via IP-Adresse erfolgreich ausgekundschaftet werden konnte:

C:\nbtstat -A 192.168.61.1

LAN-Verbindung:
Knoten-IP-Adresse: [192.168.61.10] Bereichskennung: []

      NetBIOS-Namentabelle des Remotecomputers

       Name               Typ          Status
    ---------------------------------------------
    XP-SERVER        EINDEUTIG   Registriert
    WORKGROUP        GRUPPE      Registriert
    XP-SERVER        EINDEUTIG   Registriert
    WORKGROUP        GRUPPE      Registriert
    WORKGROUP        EINDEUTIG   Registriert
    ..__MSBROWSE__.  GRUPPE      Registriert

    MAC Adresse = 00-1A-4D-5C-CB-65

Um das nun weiter zu untersuchen, muss man zunächst den Prozess der Namensauflösung in Windows verstehen. Der Normalfall sieht hier folgende Reihenfolge vor [1]:

    When an application uses Windows Sockets and either the application or a user specifies a host name, TCP/IP for Windows XP and Windows Server 2003 attempts to resolve the name in the following order when NetBIOS over TCP/IP is enabled:

    1. Windows checks whether the host name is the same as the local host name.
    2. If the host name and local host name are not the same, Windows searches the DNS client resolver cache.
    3. If the host name cannot be resolved using the DNS client resolver cache, Windows sends DNS Name Query Request messages to its configured DNS servers.
    4. If the host name is a single-label name (such as server1) and cannot be resolved using the configured DNS servers, Windows converts the host name to a NetBIOS name and checks its local NetBIOS name cache.
    5. If Windows cannot find the NetBIOS name in the NetBIOS name cache, Windows contacts its configured WINS servers.
    6. If Windows cannot resolve the NetBIOS name by querying its configured WINS servers, Windows broadcasts as many as three NetBIOS Name Query Request messages on the directly attached subnet.
    7. If there is no reply to the NetBIOS Name Query Request messages, Windows searches the local Lmhosts file.

    The name resolution process stops when Windows finds the first IP address for the name. If Windows cannot resolve the host name using any of these methods, name resolution fails, and the only way to communicate with the destination host is to specify either its IP address or another name associated with the host that Windows can resolve to an IP address.

Was hier scheinbar noch fehlt, sind die Einträge aus der Hosts-Datei. Tatsächlich findet dies aber bereits im zweiten Schritt statt. Denn, was vermutlich größtenteils unbekannt ist [1]:

    TCP/IP for Windows XP and Windows Server 2003 does not search the Hosts file directly when performing name resolution. Rather, the entries in the Hosts file are automatically loaded into the DNS client resolver cache.

Für den gegebenen Fall wird es allerdings erst ab Schritt 4 interessant – nämlich ab dem Zeitpunkt, wann die Namensauflösung via NetBIOS startet.

Zuerst wird im NetBIOS Cache nachgesehen. Der war leer. Anschließend wird ein WINS-Server gefragt. Den es nicht gibt. Spätestens mit dem Broadcast im sechsten Schritt hätte es aber funktionieren müssen – hat es aber nicht! Warum?

Weil der Prozess der Namensauflösung via NetBIOS unterschiedlich sein kann und nicht in jedem Fall der oben beschriebenen Reihenfolge entspricht. Festgelegt wird das durch den in Windows konfigurierten NetBIOS node type – auf deutsch „Knotentyp“ [2]:

    B-node (broadcast)
    Uses broadcasts for name registration and resolution. Because routers typically do not forward NetBT broadcasts, NetBIOS resources that are located on remote subnets cannot be resolved.

    P-node (peer-peer)
    Uses an NBNS such as WINS to resolve NetBIOS names. P-node does not use broadcasts but queries the NBNS directly. Because broadcasts are not used, NetBIOS resources located on remote subnets can be resolved. However, if the NBNS becomes unavailable, NetBIOS name resolution fails for all NetBIOS names, even for NetBIOS applications that are located on the local subnet.

    M-node (mixed)
    A combination of B-node and P-node. By default, an M-node functions as a B-node. If the broadcast name query is unsuccessful, NetBT uses an NBNS.

    H-node (hybrid)
    A combination of P-node and B-node. By default, an H-node functions as a P-node. If the unicast name query to the NBNS is unsuccessful, NetBT uses a broadcast.

    Microsoft enhanced B-node
    A combination of B-node and the use of the local Lmhosts file. If the broadcast name query is not successful, NetBT checks the local Lmhosts file.

Standardmäßig verwendet Windows den Knotentyp „Microsoft enhanced B-node“, also eine Kombination aus Broadcasts und Lmhosts. Sobald ein WINS Server konfiguriert ist, wird auf „H-node (hybrid)“ umgestellt.

Der Knotentyp des Notebooks stand dagegen auf „P-node (peer-peer)“, womit die Namensauflösung via Broadcast komplett abgeschaltet war:

C:\>ipconfig /all

Windows-IP-Konfiguration

   Hostname  . . . . . . . . . . . . : xp-notebook
   Primäres DNS-Suffix . . . . . . . :
   Knotentyp . . . . . . . . . . . . : Peer-Peer
   IP-Routing aktiviert  . . . . . . : Nein
   WINS-Proxy aktiviert  . . . . . . : Nein

Zum Ändern des Knotentyps muss folgender DWORD Eintrag in der Registrierung hinzugefügt und auf einen der vier möglichen Werte gestellt werden:

    HKLM\SYSTEM\CurrentControlSet\Services\Netbt\Parameters\NodeType

    1 = B-Knoten (Broadcast)
    2 = P-Knoten (Peer-Peer)
    4 = M-Knoten (Mixed)
    8 = H-Knoten (Hybrid)

Nach Änderung des Wertes auf 1 (Broadcast) und einem anschließenden Neustart wurde der Name des Servers wieder aufgelöst und die Synchronisation erfolgreich gestartet.

[1] Technet: TCP/IP Fundamentals for Microsoft Windows; Chapter 7 – Host Name Resolution
[2] Technet: TCP/IP Fundamentals for Microsoft Windows; Chapter 11 – NetBIOS over TCP/IP