INODE Zwangstrennung - Lease-Problem gefunden

[gruber]

du hast mail. danke!

[dfx]

ist angekommen und das problem ist klar ersichtlich: dein pc setzt dhcp requests für seine netzwerkkarte (oder wlan-karte) ab, schickt diese aber durch den aufgebauten vpn-tunnel (!), und dann noch mit der privaten 10er adresse als source adress (!!). diese requests wandern dann wahrscheinlich quer durchs netz und kommen dann über irgendeinen umweg schliesslich zum dhcp server, nur der rückweg kann so nicht funktionieren. die frage ist jetzt, warum ausgerechnet dein pc (deine pcs?) dieses merkwürdige verhalten an den tag legt....

folgender lösungsversuch: ich hab mal testweise eine statische route auf unserm router gesetzt, es wäre nett wenn du mal schaun könntest, ob sich dadurch irgendetwas bessert (möglicherweise ist ein einmaliger reboot nötig, um den dhcp prozess neu zu starten).

falls alle stricke reissen: da du ips aus dem 10er bereich beziehst und diese nur lokal gültigkeit haben, kannst du dir einfach eine aus dem 10.xxx bereich aussuchen und sie die statisch zuweinsen, also zb 10.xxx.0.2, mit 10.xxx.0.1 als gateway (wobei xxx die gleiche zahl ist, welche auch in den ip adressen an der stelle zu finden ist, welche du jetzt beziehst (umständliche formulierung um deinen wohnort nicht preiszugeben )). damit würdest du dhcp ganz vermeiden.

[gruber]

ist angekommen und das problem ist klar ersichtlich: dein pc setzt dhcp requests für seine netzwerkkarte (oder wlan-karte) ab, schickt diese aber durch den aufgebauten vpn-tunnel (!), und dann noch mit der privaten 10er adresse als source adress (!!). diese requests wandern dann wahrscheinlich quer durchs netz und kommen dann über irgendeinen umweg schliesslich zum dhcp server, nur der rückweg kann so nicht funktionieren. die frage ist jetzt, warum ausgerechnet dein pc (deine pcs?) dieses merkwürdige verhalten an den tag legt....

für mich wars leider nicht so klar ersichtlich. sprech nicht so gut ethernet.

folgender lösungsversuch: ich hab mal testweise eine statische route auf unserm router gesetzt, es wäre nett wenn du mal schaun könntest, ob sich dadurch irgendetwas bessert (möglicherweise ist ein einmaliger reboot nötig, um den dhcp prozess neu zu starten).

habs probiert. leider ohne erfolg.

falls alle stricke reissen: da du ips aus dem 10er bereich beziehst und diese nur lokal gültigkeit haben, kannst du dir einfach eine aus dem 10.xxx bereich aussuchen und sie die statisch zuweinsen, also zb 10.xxx.0.2, mit 10.xxx.0.1 als gateway (wobei xxx die gleiche zahl ist, welche auch in den ip adressen an der stelle zu finden ist, welche du jetzt beziehst (umständliche formulierung um deinen wohnort nicht preiszugeben )). damit würdest du dhcp ganz vermeiden.

solange du keine wirklichen geheimnisse preisgibst ist, kein problem.

[gruber]

hab mir die sache noch mal angesehen.

mit linux hab ich mal von einem anderen inode-anschluss gepumpt. das ging ohne problem. wenn ich wieder vor ort bin werd ich es nochmal in tribuswinkel pronieren.

was ich remote noch an der windows-maschine probiert habe, ist das lease ohne tunnel zu beziehen.
ich hätte eigentlich erwartet, dass das funktioniert. leider ist dem aber nicht so.
kann es sein, dass der request nur deswegen über den tunnel kommt, weil ohne tunnel kein ack kommt? (der "intelligenten net-automatik" von windoof trau ich alles zu )

[dfx]

mit linux hab ich mal von einem anderen inode-anschluss gepumpt. das ging ohne problem. wenn ich wieder vor ort bin werd ich es nochmal in tribuswinkel pronieren.

das kommt wieder auf den client drauf an, lokale config, gesetzte routen usw... aber zumindest hat man bei linux die möglichkeit, ganz gezielt die config so zu setzen, daß es dann funktioniert...

was ich remote noch an der windows-maschine probiert habe, ist das lease ohne tunnel zu beziehen.

was ich mich schon die ganze zeit frage: wie geht das, diese ganzen spielchen remote zu machen, wenn dadurch immer die internet connection ausfällt?

ich hätte eigentlich erwartet, dass das funktioniert. leider ist dem aber nicht so.

naja, direkt nach dem booten passiert ja genau das, die ip wird per dhcp ohne tunnel bezogen, weil ohne ip kannst du ja keinen tunnel aufbauen. was möglich wäre, ist daß nach dem aufbauen und wieder abbauen des tunnels einige (falsche) routen in der routing table liegen bleiben. vielleicht checkst du mal den output von "route print" abchecken?

kann es sein, dass der request nur deswegen über den tunnel kommt, weil ohne tunnel kein ack kommt? (der "intelligenten net-automatik" von windoof trau ich alles zu )

normalerweise nicht, weil wie gesagt, nach boot wird dhcp auf jeden fall ohne tunnel gespielt, und da haut es ja hin.

[gruber]

mit linux hab ich mal von einem anderen inode-anschluss gepumpt. das ging ohne problem. wenn ich wieder vor ort bin werd ich es nochmal in tribuswinkel pronieren.

das kommt wieder auf den client drauf an, lokale config, gesetzte routen usw... aber zumindest hat man bei linux die möglichkeit, ganz gezielt die config so zu setzen, daß es dann funktioniert...

hoffentlich (schaff ich das)!

was ich remote noch an der windows-maschine probiert habe, ist das lease ohne tunnel zu beziehen.

was ich mich schon die ganze zeit frage: wie geht das, diese ganzen spielchen remote zu machen, wenn dadurch immer die internet connection ausfällt?

da gibt es prinzipiell 2 möglichkeiten:
1) du skriptest das ganze
2) du steckst einfach 2 nics in den rechner und steuerst ihn über die leitung an der gerade nicht gebastelt wird.

da (1) ein bisschen riskant ist - ich könnte ja mal einen fehler machen und dann komm ich nicht mehr an den rechner -, arbeite ich nach methode (2) und verwende zur sicherheit noch einen dritten rechner für die alternative verbindung. (nur zur vorbeugung - die "netzwerkkonstruktion" ist mit dem inode-support abgesprochen)

ich hätte eigentlich erwartet, dass das funktioniert. leider ist dem aber nicht so.

naja, direkt nach dem booten passiert ja genau das, die ip wird per dhcp ohne tunnel bezogen, weil ohne ip kannst du ja keinen tunnel aufbauen. was möglich wäre, ist daß nach dem aufbauen und wieder abbauen des tunnels einige (falsche) routen in der routing table liegen bleiben. vielleicht checkst du mal den output von "route print" abchecken?

gleich nach dem Systemstart sieht der table so aus:

Code: Alles auswählen

Microsoft Windows 2000 [Version 5.00.2195]
(C) Copyright 1985-2000 Microsoft Corp.

C:\Dokumente und Einstellungen\Rudi>route print
===========================================================================
Schnittstellenliste
0x1 ........................... MS TCP Loopback interface
0x2 ...00 80 c7 87 fb 87 ...... Xircom CEM28 Ethernet+Modem Adapter
0x3 ...00 02 a5 6e 99 81 ...... Compaq WL110 PC Card
===========================================================================
===========================================================================
Aktive Routen:
     Netzwerkziel    Netzwerkmaske          Gateway   Schnittstelle  Anzahl
          0.0.0.0          0.0.0.0        10.27.0.1     10.27.5.242       8
        10.27.0.0      255.255.0.0      10.27.5.242     10.27.5.242       1
      10.27.5.242  255.255.255.255        127.0.0.1       127.0.0.1       1
   10.255.255.255  255.255.255.255      10.27.5.242     10.27.5.242       1
        127.0.0.0        255.0.0.0        127.0.0.1       127.0.0.1       1
      169.254.0.0      255.255.0.0  169.254.195.238  169.254.195.238      1
  169.254.195.238  255.255.255.255        127.0.0.1       127.0.0.1       1
  169.254.255.255  255.255.255.255  169.254.195.238  169.254.195.238      1
        224.0.0.0        224.0.0.0      10.27.5.242     10.27.5.242       1
        224.0.0.0        224.0.0.0  169.254.195.238  169.254.195.238      1
  255.255.255.255  255.255.255.255  169.254.195.238  169.254.195.238      1
Standardgateway:         10.27.0.1
===========================================================================
Ständige Routen:
  Keine

C:\Dokumente und Einstellungen\Rudi>ipconfig /renew

Windows 2000-IP-Konfiguration

Der folgende Fehler ist bei der Erneuerung von Adapter WL110 aufgetreten: DHCP-S
erver nicht verfügbar
Der folgende Fehler ist bei der Erneuerung von Adapter LAN-Verbindung aufgetrete
n: DHCP-Server nicht verfügbar

wie du siehst, funktioniert auch da (vor dem tunnelaufbau) die erneuerung des lease nicht.

dann habe ich die verbindung zu inode aufgebaut (die tunnelvariante)
danach sieht die sache so aus:

Code: Alles auswählen


C:\Dokumente und Einstellungen\Rudi>route print
===========================================================================
Schnittstellenliste
0x1 ........................... MS TCP Loopback interface
0x2 ...00 80 c7 87 fb 87 ...... Xircom CEM28 Ethernet+Modem Adapter
0x3 ...00 02 a5 6e 99 81 ...... Compaq WL110 PC Card
0x2000005 ...00 53 45 00 00 00 ...... WAN (PPP/SLIP) Interface
===========================================================================
===========================================================================
Aktive Routen:
     Netzwerkziel    Netzwerkmaske          Gateway   Schnittstelle  Anzahl
          0.0.0.0          0.0.0.0        10.27.0.1     10.27.5.242       9
          0.0.0.0          0.0.0.0    81.223.242.78   81.223.242.78       1
       10.0.0.138  255.255.255.255        10.27.0.1     10.27.5.242       8
        10.27.0.0      255.255.0.0      10.27.5.242     10.27.5.242       1
      10.27.5.242  255.255.255.255        127.0.0.1       127.0.0.1       1
   10.255.255.255  255.255.255.255      10.27.5.242     10.27.5.242       1
    81.223.242.78  255.255.255.255        127.0.0.1       127.0.0.1       1
   81.255.255.255  255.255.255.255    81.223.242.78   81.223.242.78       1
        127.0.0.0        255.0.0.0        127.0.0.1       127.0.0.1       1
      169.254.0.0      255.255.0.0  169.254.195.238  169.254.195.238      1
  169.254.195.238  255.255.255.255        127.0.0.1       127.0.0.1       1
  169.254.255.255  255.255.255.255  169.254.195.238  169.254.195.238      1
        224.0.0.0        224.0.0.0      10.27.5.242     10.27.5.242       1
        224.0.0.0        224.0.0.0    81.223.242.78   81.223.242.78       1
        224.0.0.0        224.0.0.0  169.254.195.238  169.254.195.238      1
  255.255.255.255  255.255.255.255  169.254.195.238  169.254.195.238      1
Standardgateway:     81.223.242.78
===========================================================================
Ständige Routen:
  Keine

C:\Dokumente und Einstellungen\Rudi>
C:\Dokumente und Einstellungen\Rudi>ipconfig /all

Windows 2000-IP-Konfiguration

        Hostname. . . . . . . . . . . . . : nbp3
        Primäres DNS-Suffix . . . . . . . :
        Knotentyp . . . . . . . . . . . . : Broadcastadapter
        IP-Routing aktiviert. . . . . . . : Nein
        WINS-Proxy aktiviert. . . . . . . : Nein

Ethernetadapter "WL110":

        Verbindungsspezifisches DNS-Suffix:
        Beschreibung. . . . . . . . . . . : Compaq WL110 PC Card
        Physikalische Adresse . . . . . . : 00-02-A5-6E-99-81
        DHCP-aktiviert. . . . . . . . . . : Ja
        Autokonfiguration aktiviert . . . : Ja
        IP-Adresse. . . . . . . . . . . . : 10.27.5.242
        Subnetzmaske. . . . . . . . . . . : 255.255.0.0
        Standardgateway . . . . . . . . . : 10.27.0.1
        DHCP-Server . . . . . . . . . . . : 81.223.56.254
        DNS-Server. . . . . . . . . . . . : 195.58.160.2
                                            195.58.161.3
        NetBIOS über TCP/IP . . . . . . . : Deaktiviert
        Lease erhalten. . . . . . . . . . : Donnerstag, 05. Februar 2004 12:50:0
9
        Lease läuft ab. . . . . . . . . . : Freitag, 06. Februar 2004 12:50:59

Ethernetadapter "LAN-Verbindung":

        Verbindungsspezifisches DNS-Suffix:
        Beschreibung. . . . . . . . . . . : Xircom CreditCard Ethernet+Modem 28.
8
        Physikalische Adresse . . . . . . : 00-80-C7-87-FB-87
        DHCP-aktiviert. . . . . . . . . . : Ja
        Autokonfiguration aktiviert . . . : Ja
        IP-Adresse (Autokonfiguration). . : 169.254.195.238
        Subnetzmaske. . . . . . . . . . . : 255.255.0.0
        Standardgateway . . . . . . . . . :
        DNS-Server. . . . . . . . . . . . :

PPP-Adapter  "xdsl@home":

        Verbindungsspezifisches DNS-Suffix:
        Beschreibung. . . . . . . . . . . : WAN (PPP/SLIP) Interface
        Physikalische Adresse . . . . . . : 00-53-45-00-00-00
        DHCP-aktiviert. . . . . . . . . . : Nein
        IP-Adresse. . . . . . . . . . . . : 81.223.242.78
        Subnetzmaske. . . . . . . . . . . : 255.255.255.255
        Standardgateway . . . . . . . . . : 81.223.242.78
        DNS-Server. . . . . . . . . . . . : 195.58.160.2
                                            195.58.161.3

leider werd ich nicht wirklich schlau aus den route tables.
kannst du mir da weiterhelfen?

kann es sein, dass der request nur deswegen über den tunnel kommt, weil ohne tunnel kein ack kommt? (der "intelligenten net-automatik" von windoof trau ich alles zu )

normalerweise nicht, weil wie gesagt, nach boot wird dhcp auf jeden fall ohne tunnel gespielt, und da haut es ja hin.

Code: Alles auswählen

wie du oben siehst, funktioniert das auch vor dem aufbau des tunnels nicht bzw. nur genau 1x.

und ich bin vollkommen ratlos, warum.

[dfx]

soda, wir ham das ganze jetzt bei uns nochmal 1:1 durchgespielt und konnten das problem auch bei nicht aufgebautem tunnel nachvollziehen. offenbar spielen hier gewisse eigenheiten des dhcp-protokolls (unicast-requests) zusammen mit eigenheiten der windows-implementation (kein fallback auf dhcp-discover) und auch unser spezielles netzwerksetup (dhcp für die vergabe von privaten ip-adressen) alles zusammen eine rolle. ein workaround ist statt nur "ipconfig /renew" machen, vorher ein "/release" machen und dann das renew. einfachste lösung für dich wäre aber die statische adressvergabe: gib dir einfach 10.27.0.2 und aufwärts (kannst frei wählen), netmask 255.255.0.0, gateway 10.27.0.1, und damit hat sich die geschichte. wir werden in den nächsten tagen aber auf jeden fall versuchen, eine "richtige" lösung zu finden.

[gruber]

nachdem ich schon ein bisschen am verzweifeln war , hab ich das zeugs auch unserem netzwerkguru geschickt und ihn ein bisschen an der testinstallation herumtüfteln lassen.

der ist im wesentlichen zum gleichen schluss gekommen, das inode nicht microsoft-kompatibel bzw. windows nicht xdsl-kompatibel ist.


der von dir vorgeschlagene workaround löst das problem auch nicht wirklich.
es kann zwar dadurch ein neues ablaufdatum der lease erreicht werden, leider hat windows aber durch den relase kurzzeitig keine ip mehr, was wiederum den tunnel zusammenbrechen lässt.
da warte ich lieber bis das aufgrund des lease-ablaufs passiert.

der workaround mit der statischen adresse ist bei mir leider auch nicht möglich, da der lappi dann im büro und an anderen hotspots jedesmal manuell mit einer neuen konfiguration versorgt werden müsste.

so bleibt mir also nur die hoffnung, das ihr die "richtige" lösung bald findet.
sagt mir bitte bescheid, wenns soweit ist.
oder besteht die möglichkeit einer "individuallösung"?

[dfx]

als quick fix könnt ma die lease time vorerst erhöhen, auf ein paar wochen oder so... wär das eine lösung?

[gruber]

damit kann ich leben, wenns kein ewiges provisorium wird.

ich hoffe nur, dass euch nicht die adressen ausgehen, wenn das lease am anschlag ist.

mich wundert nur, dass das ausser mir niemandem aufgefallen ist.
ihr habt wohl kaum noch windoof-user?

wieviele server müsst ihr denn jetzt fixen?

[dfx]

vorerst mal nur den dhcp server, der für dein gebiet zuständig ist (was soeben geschehen ist). mir sind sonst keine fälle bekannt, wo dieses spezielle phänomen ein problem ist, deshalb lassen wir die andern server derweil wie sie sind, bis eine endgültige lösung gefunden ist.

[gruber]

ich bin auch nur draufgekommen, weil ich grad am gerät war als es sich einfach so nochmal eingewählt hat.
und weil ich ein neugieriger mensch bin, hab ich mir halt mal die logs angesehen, wo mir dann die regelmässigkeit des ausfalls aufgefallen ist.
dass es am dhcp-lease liegen muss war auch recht schnell klar. nur wo genau?

vielen dank, dass du das für mich festgestellt hast!

und noch viel mehr dank, wenns dann "richtig gelöst ist".


im zusammenhang mit dem zusammenbrechen des tunnels hätt ich da noch eine frage, da ja der benutzer abgewiesen wird, wenn man sich gleich wieder einwählen will:
wie lange ist das vpn-session-timout?
kann man das ein bisschen kürzer einstellen?
das wird mich zwar mit dem verlängerten lease nicht mehr so häufig treffen. trotzdem wärs schön, wenn man da was machen könnte.

und nochmal danke, dass ihr auch für die minderheiten, die immer noch mit windows arbeiten, etwas tut!

[gruber]

ist inode in dieser beziehung mit allen os von microsoft inkompatibel?
habt ihr das mit den neueren versionen auch getestet?

Nochmal

[dfx]

wie lange ist das vpn-session-timout?
kann man das ein bisschen kürzer einstellen?

schwer zu sagen, 1-2 minuten wird's schon sein... einstellen kamma da nix afaik, aber das sollte auch kein problem sein, weil für jeden user 2 gleichzeitige logins erlaubt sind, eben genau aus dem grund, falls mal eine session hängenbleibt.

ist inode in dieser beziehung mit allen os von microsoft inkompatibel?
habt ihr das mit den neueren versionen auch getestet?

wie gesagt, es ist sonst von keinen problemen bekannt. ich würd's auch nicht als generelle inkompatibilität bezeichnen, sondern es ist einfach ein zusammenspiel mehrerer faktoren, was zu diesem ergebnis führt. aber wir werden auf jeden fall alle möglichkeiten mal durchspielen...

[gruber]

hab mir das problem interessehalber noch bei ein paar leuten mit xdsl angesehen.

das problem lässt sich auch mit anderen windows-versionen nachvollziehen.

aber nur bei leuten, die xdsl@home ohne router betreiben.
bei xdsl@work funktioniert die erneuerung des lease komischerweise.

was ist da bei @work anders?