1. Dashboard
  2. Forum
    1. Unerledigte Themen
  3. Mitglieder
    1. Letzte Aktivitäten
    2. Benutzer online
    3. Team-Mitglieder
    4. Trophäen
    5. Mitgliedersuche
  4. Tutorial Bereich
  • Anmelden
  • Registrieren
  • Suche
Dieses Thema
  • Alles
  • Dieses Thema
  • Dieses Forum
  • Seiten
  • Forum
  • Lexikon
  • Erweiterte Suche
  1. Informatik Forum
  2. Software und Anwendungen
  3. Betriebssysteme

cisco-vpnclient und TU-only-Profil -- DNS spinnt

    • Linux
  • daff
  • 28. September 2005 um 00:57
  • Unerledigt
  • daff
    14
    daff
    Mitglied
    Reaktionen
    11
    Punkte
    2.021
    Beiträge
    386
    • 28. September 2005 um 00:57
    • #1

    Hab den Cisco-vpnclient auf meiner Gentoo-Workstation installiert und verwende das vpntuonly-Profil. Sehr viel ist da für mich als Benutzer ja nicht zu tun, außer

    Code
    $ vpnclient connect vpntuonly


    Die Verbindung wird hergestellt und funktioniert offenbar, wenn man den Meldungen von vpnclient glauben darf:

    Code
    Enter Username and Password.
    
    
    Username [eXXXXXXX@vpn.tuwien.ac.at]:
    Password []:
    Authenticating user.
    Negotiating security policies.
    Securing communication channel.
    
    
    Your VPN connection is secure.
    
    
    VPN tunnel information.
    Client address: 128.131.211.174
    Server address: 192.35.241.84
    Encryption: 168-bit 3-DES
    Authentication: HMAC-MD5
    IP Compression: None
    NAT passthrough is active on port UDP 4500
    Local LAN Access is disabled
    Alles anzeigen


    Das Problem ist folgendes: irgendwas passt mit dem DNS nicht mehr. Sobald die VPN-Verbindung steht kann ich beispielsweise per Browser nicht mehr auf http://www.tuwien.ac.at zugreifen.

    Die /etc/resolv.conf zeigt folgendes an:

    Code
    domain tuwien.ac.at
    nameserver 192.168.0.1
    search tuwien.ac.at my-home.domain


    Normalerweise sieht die so aus:

    Code
    domain my-home.domain
    nameserver 192.168.0.1


    Mein LAN-Gateway ist neben Firewall auch Nameserver für das LAN, der Nameserver selbst verwendet einen Standard-Chello-Nameserver als Forwarder (195.34.133.11 z.B.). Das sollte dem vpnclient aber herzlich egal sein.

    Wenn ich also bei bestehender VPN-Verbindung etwa dig http://www.tuwien.ac.at mache, dann kommt nur

    Code
    ; <<>> DiG 9.2.5 <<>> www.tuwien.ac.at
    ;; global options:  printcmd
    ;; connection timed out; no servers could be reached


    Andere Seiten, etwa http://www.gentoo.org, sind problemlos zu erreichen. Auch alle anderen Adressen in meiner LAN-Domain sind erreich- und auflösbar.

    Woran kann es also liegen, dass entgegen den Behauptungen in der Beschreibung des Profils ("Das Nameservice erfolgt für tuwien.ac.at-Domains über die Nameserver der TU (tunamea, tunameb). Für alle anderen Domains wird das Nameservice des Providers verwendet.") kein Zugriff auf tuwien.ac.at-Domains möglich ist?

    Habe ich vergessen, irgendwelche Services oder Ports in der Firewall des LANs zu öffnen oder zu forwarden? Wüsste jetzt echt nicht, was da nötig sein könnte. Port 4500 (NAT passthrough laut oben) habe ich auf meine Gentoo-Workstation geforwarded. Ändert aber nichts.

    In der Profil-Datei (vpntuonly.pcf) gibts einen Parameter EnableSplitDNS, der defaultmäßig auf 1 gesetzt ist. Wenn ich den auf 0 setze, dann sind tuwien.ac.at-Domains wieder erreichbar, nur leidet darunter natürlich dann das lokale DNS, sprich ein dig gateway.my-home.domain (auflösen) dauert viel zu lang (weil offenbar zuerst die TU-Nameserver befragt werden, dann erst der lokale, oder so?) und nur über den Hostname (etwa ping gateway) zuzugreifen funktioniert überhaupt nicht mehr.

    Weiß jemand Rat? Ich weiß, das Posting ist viel zu lang und lesen wirds kaum jemand ganz, aber irgendwie hätt ich doch gern eine Lösung für das Problem. Vor allem wundert mich, dass es da überhaupt ein Problem gibt …

    TIA.

    Restrain the specimen!

  • gelbasack
    25
    gelbasack
    Mitglied
    Reaktionen
    90
    Punkte
    6.525
    Beiträge
    1.241
    • 28. September 2005 um 16:50
    • #2

    Wieso lässt du überhaupt deine /etc/resolv.conf überschreiben? Brauchst du bestimmte Einträge direkt von den DNS-Server der TU?
    Ansonsten: du könntest deinem DNS-Server sagen, dass er Hostabfragen, die auf tuwien.ac.at enden zu den DNS-Servern der TU weiterleiten soll.

  • daff
    14
    daff
    Mitglied
    Reaktionen
    11
    Punkte
    2.021
    Beiträge
    386
    • 28. September 2005 um 17:23
    • #3

    Danke mal für die Antwort!

    Die /etc/resolv.conf wird bei Herstellung der VPN-Verbindung über- bzw umgeschrieben, damit tuwien.ac.at-Domains über die TU-Wien-Nameserver aufgelöst werden, in Verbindung mit dem vpntuonly-Profil. So hab ich die Beschreibung davon zumindest verstanden. Schätze das ist nötig, um Domain- und Hostnamen aufzulösen, die nur im TUNET vorhanden sind, über die mein, oder der Chello-DNS-Server nichts wissen kann. Nach Verbindungstrennung stehen wieder die Ursprungsinfos in der resolv.conf.

    Wie gesagt, ich verwende das vom ZID zur Verfügung gestellte Profil, und es wundert mich sehr, dass es mich, direkt übernommen und unverändert, überall hinlässt, nur eben grade nicht ins TUNET. Das lustige ist ja, dass ich in die resolv.conf eintragen kann was ich will (nach Verbindungsherstellung), solange EnableSplitDNS=1 ist werden die tuwien.ac.at-Domains einfach nicht gefunden.

    Bei EnableSplitDNS=0 werden meine Nameserver in der /etc/resolv.conf komplett überschrieben:

    Code
    domain tuwien.ac.at
    nameserver 128.130.2.3
    nameserver 128.130.3.131
    search tuwien.ac.at my-home.domain


    Einzig my-home.domain bleibt eine Suchdomain, aber über die kann natürlich kein TU-DNS-Server Bescheid wissen. Ist leider kein Zustand, den ich tolerieren kann oder will.

    Hat sonst noch niemand den Cisco-Client und dieses Profil unter Linux verwendet? Wundert mich sogar noch mehr :)

    Restrain the specimen!

  • gelbasack
    25
    gelbasack
    Mitglied
    Reaktionen
    90
    Punkte
    6.525
    Beiträge
    1.241
    • 28. September 2005 um 17:42
    • #4

    Ja, warum die /etc/resolv.conf überschrieben wird, ist klar. Ich hatte eigentlich eher gemeint, ob sich das mal vermeiden ließe?
    Wenn alle DNS-Abfragen über deinen DNS-Server laufen, könntest du den entsprechend konfigurieren (geht bei mir mit tinydns zumindest problemlos).

  • daff
    14
    daff
    Mitglied
    Reaktionen
    11
    Punkte
    2.021
    Beiträge
    386
    • 28. September 2005 um 21:13
    • #5

    Es wäre toll, ließe sich das vermeiden, bzw. irgendwo angeben, dass an den DNS-Informationen nichts geändert werden soll. Allerdings sollte es den gleichen Effekt erzielen wenn ich die original /etc/resolv.conf nach dem Herstellen der VPN-Verbindung über die von vpnclient veränderte kopiere.

    Code
    # cp /etc/resolv.conf.vpnbackup /etc/resolv.conf


    Nutzt aber nichts. Liegt denk ich daran, dass per Default alle Verbindungen zu tuwien.ac.at über die TU-Nameserver aufgelöst werden, so stehts wohl im Profil bzw. beim Concentrator/VPN-Server auf der TU. Weißt du ob oder wo man das ändern kann?

    Nachdem ich ein wenig in der Doku zum vpnclient gelesen hab, denk ich, es muss doch irgendwas mit dem EnableSplitDNS zu tun haben. Damit das funktioniert muss aber irgendwie "split tunneling" aktiviert werden, was man sowohl auf Server- als auch auf Client-Seite tun muss. Habs aber nciht geschafft rauszufinden, welcher verdammte Parameter im Profil das sein soll, und ob der TU-VPN-Server split tunneling unterstützt weiß ich auch nciht.

    Nebenbei kommt mir der Gedanke, dass es vielleicht daran liegt, dass ich die Version 4.6.02.0030 vom Client verwende, der ZID offiziell aber nur die 4.6.00.0045-k9 anbietet. Letztere hab ich natürlich auch schon ausprobiert, aber die hat prompt zu einem Kernel Panic geführt, gleich drei Mal.

    Kann es wirklich an Versionsinkompatibilitäten liegen? Das wäre sehr … disturbing.

    Edit: Muss wirklich irgendwas Linux- oder Versionsspezifisches sein, weil unter Windows rennts tadellos mit dem Profil und dem Client vom ZID. Ich bin nicht amused. :frowning_face:

    Restrain the specimen!

  • Maximilian Rupp 27. Dezember 2024 um 12:09

    Hat das Thema aus dem Forum Betriebssysteme nach Betriebssysteme verschoben.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden

Benutzer online in diesem Thema

  • 1 Besucher

Rechtliches

Impressum

Datenschutzerklärung