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

  • 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:


    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!

  • 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.

  • 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!

  • 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).

  • 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. :(

    Restrain the specimen!

Jetzt mitmachen!

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