openconnect VPNをnetwork-manager経由で機能させる

これはここと同じ問題です：guiを介してopenconnect vpnを動作させるが、それに追加したものが削除され、新しい質問を作成するように求められました。

実際、多くの人々がここで同様の質問をしていて、すべて0応答でした。

ソフトウェアバージョン： ubuntu 14.04、openconnect 5.02

主な問題： openconnectを使用して、ネットワーク接続マネージャーにVPN接続を追加しようとしています。VPNのユーザー名とパスワードを入力すると、正常に接続されますが、DNSを解決できません。

端末でsudoを介してopenconnectを実行すると、dnsが機能します。

sudo openconnect -u <username> https://<vpn concentrator name>

詳細：

1a。openconnectとnetwork-managerを介して接続するとき、dnsと検索ドメインをipv4タブの下に明示的に追加したにもかかわらず、検索ドメインのみが/etc/resolv.confに入ります。DNSと検索ドメインを指定しなくても、VPNコンセントレータからその情報を取得していることをログで確認できます。この場合も、検索ドメインは適切に更新されます。[下のログ]

1b。端末でsudoを介して接続すると、コマンドラインでその情報を追加していないか、vpnc-scriptへのパスを指定していなくても、resolv.confにdnsと検索ドメインが適切に入力されます。VPNコンセントレータから取得している必要があります。[下にもログ]

2a。openconnectおよびnetwork-managerを介して接続すると、新しいインターフェイス「vpn0」が作成されます。

2b。sudoとコマンドラインを介して接続すると、新しいインターフェース「tun0」が作成されます。

network-manager経由で接続するときのログ：

NetworkManager[784]: <info> Starting VPN service 'openconnect'...
NetworkManager[784]: <info> VPN service 'openconnect' started (org.freedesktop.NetworkManager.openconnect), PID 4513
NetworkManager[784]: <info> VPN service 'openconnect' appeared; activating connections
NetworkManager[784]: <info> VPN plugin state changed: init (1)

これは私のパスワードを尋ねるところです

NetworkManager[784]: <info> VPN plugin state changed: starting (3)
NetworkManager[784]:    SCPlugin-Ifupdown: devices added (path: /sys/devices/virtual/net/vpn0, iface: vpn0)
NetworkManager[784]:    SCPlugin-Ifupdown: device added (path: /sys/devices/virtual/net/vpn0, iface: vpn0): no ifupdown configuration found.
NetworkManager[784]: <warn> /sys/devices/virtual/net/vpn0: couldn't determine device driver; ignoring...
NetworkManager[784]: <info> VPN connection '<connection name>' (Connect) reply received.
openconnect[4544]: Attempting to connect to server <ip address>:443
openconnect[4544]: SSL negotiation with <correctly identified vpn server>
openconnect[4544]: Connected to HTTPS on <correctly identified vpn server>
openconnect[4544]: Got CONNECT response: HTTP/1.1 200 OK
openconnect[4544]: CSTP connected. DPD 30, Keepalive 20
NetworkManager[784]: <info> VPN connection '<connection name>' (IP Config Get) reply received.
NetworkManager[784]: <info> VPN connection '<connection name>' (IP4 Config Get) reply received.
NetworkManager[784]: <info> VPN connection '<connection name>' (IP6 Config Get) reply received.
NetworkManager[784]: <info> VPN Gateway: <ip address>
NetworkManager[784]: <info> Tunnel Device: vpn0
NetworkManager[784]: <info> IPv4 configuration:
NetworkManager[784]: <info>   Internal Address: 10.xxx.xxx.xxx
NetworkManager[784]: <info>   Internal Prefix: 19
NetworkManager[784]: <info>   Internal Point-to-Point Address: 10.xxx.xxx.xxx
NetworkManager[784]: <info>   Maximum Segment Size (MSS): 0
NetworkManager[784]: <info>   Forbid Default Route: no
NetworkManager[784]: <info>   Internal DNS: <ip address>
NetworkManager[784]: <info>   Internal DNS: <ip address>
NetworkManager[784]: <info>   DNS Domain: '(none)'
NetworkManager[784]: <info> IPv6 configuration:
NetworkManager[784]: <info>   Internal Address: <ipv6 ip>
NetworkManager[784]: <info>   Internal Prefix: 64
NetworkManager[784]: <info>   Internal Point-to-Point Address: <ipv6 ip>
NetworkManager[784]: <info>   Maximum Segment Size (MSS): 0
NetworkManager[784]: <info>   Forbid Default Route: no
NetworkManager[784]: <info>   DNS Domain: '(none)'
openconnect[4544]: Connected vpn0 as <ip address> + <ipv6 ip>, using SSL
openconnect[4544]: Established DTLS connection (using OpenSSL)
NetworkManager[784]: <info> VPN connection '<connection name>' (IP Config Get) complete.
NetworkManager[784]: <info> Policy set '<connection name>' (vpn0) as default for IPv4 routing and DNS.
NetworkManager[784]: <info> Policy set '<connection name>' (vpn0) as default for IPv6 routing and DNS.
NetworkManager[784]: <info> Writing DNS information to /sbin/resolvconf
dnsmasq[1027]: setting upstream servers from DBus
dnsmasq[1027]: using nameserver 127.0.0.1#53 for domain 10.in-addr.arpa
dnsmasq[1027]: using nameserver 127.0.0.1#53 for domain <home search domain>
dnsmasq[1027]: using nameserver 127.0.0.1#53 for domain <vpn search domain>
dnsmasq[1027]: using nameserver <ip address>#53 for domain 10.in-addr.arpa
dnsmasq[1027]: using nameserver <ip address>#53 for domain <home search domain>
dnsmasq[1027]: using nameserver <ip address>#53 for domain <vpn search domain>
dnsmasq[1027]: using nameserver <ip address>#53 for domain 10.in-addr.arpa
dnsmasq[1027]: using nameserver <ip address>#53 for domain <home search domain>
dnsmasq[1027]: using nameserver <ip address>#53 for domain <vpn search domain>
dbus[471]: [system] Activating service name='org.freedesktop.nm_dispatcher' (using servicehelper)
NetworkManager[784]: <info> VPN plugin state changed: started (4)
NetworkManager[784]:    keyfile: updating /etc/NetworkManager/system-connections/<connection name>-6a503043-13b0-4ce7-9749-29cd3054cae3
dbus[471]: [system] Successfully activated service 'org.freedesktop.nm_dispatcher'

resolv.confの更新に関するログ内のすべてのノイズにもかかわらず、ネームサーバーは削除されますが、ログ内のIPアドレスに置き換えられません。検索ドメインは正しく更新されるため、権限の問題ではない可能性があります。

ターミナルでsudo openconnectを使用して接続するときのログ：

NetworkManager[784]:    SCPlugin-Ifupdown: devices added (path: /sys/devices/virtual/net/tun0, iface: tun0)
NetworkManager[784]:    SCPlugin-Ifupdown: device added (path: /sys/devices/virtual/net/tun0, iface: tun0): no ifupdown configuration found.
NetworkManager[784]: <warn> /sys/devices/virtual/net/tun0: couldn't determine device driver; ignoring...
dbus[471]: [system] Activating service name='org.freedesktop.hostname1' (using servicehelper)
kernel: [ 3258.725774] systemd-hostnamed[4927]: Warning: nss-myhostname is not installed. Changing the local hostname might make it unresolveable. Please install nss-myhostname!
dbus[471]: [system] Successfully activated service 'org.freedesktop.hostname1'

resolv.confの更新については何もありませんが、ネームサーバーと検索ドメインは適切に更新されます。

resolv.confのすべての警告を無視し、vpnコンセントレータネームサーバーを追加した場合、更新してすぐに閲覧できます。もちろん、切断するとすぐに、それらの変更は上書きされます。

これには2012年にバグがありましたが、期限が切れました。問題はvpncスクリプトにあるようです。

私は自分のvpnc-scriptsを最新バージョンに手動で更新しようとしましたが、役に立ちませんでした。

12.04の時点で、resolv.confはnetwork-managerを使用するときにネームサーバーがDNS解決に行く場所ではなくなったことが、さらなる調査によって判明しました。そのため、コマンドラインを使用すると機能しますが、network-managerを使用すると機能しません。むしろネームサーバー127.0.1.1 [dnsmasq]が追加され、そのネームサーバーには実際のネームサーバーのIPアドレスが通知されます。

大きな利点は、VPNに接続する場合、以前のようにすべてのDNSトラフィックをVPN経由でルーティングする代わりに、そのVPNによってアナウンスされたサブネットとドメインに関連するDNSクエリのみを送信することです。

/etc/resolv.confが入力されているため、上記のリンクで説明されているようにdnsmasqを無効にして更新すると、問題が解決します。

これはフォールバックですが、実際のソリューションではありません。

VPN経由で解決しようとしているホストと、Cisco VPNサーバーが送信している「DNSドメイン」との間に不一致がないかどうかを確認します。

これを確認するには、ターミナルを開いて実行します。

tail -f /var/log/syslog

次に、ネットワークマネージャー経由でopenconnectを起動します。次のような行を含め、出力全体が表示されます。

12月5日12:54:31カヌーNetworkManager [1266]：内部DNS：10.0.20.21

12月5日12:54:31カヌーNetworkManager [1266]：内部DNS：10.10.3.32

12月5日12:54:31カヌーNetworkManager [1266]：DNSドメイン： 'internal.example.com'

さらに下に表示されます

12月5日12:54:31 canoe dnsmasq [1871]：ドメインinternal.example.comにネームサーバー10.0.20.21＃53を使用

VPNサーバーは、DNSサーバが内部にホストを解決するために使用されるべきであることをクライアントに指示されていることを、この手段internal.example.comのような、server.internal.example.com。

私の場合、解決する必要がありますserver.example.com（結果も得られませんでした）。

私にとっての解決策は、VPN設定に移動し、example.com追加の検索ドメインとして追加することでした。

VPNを切断してから再接続して、設定を有効にすることを忘れないでください。

だから私は自分自身で十分にこれを解決しました。私はMint 18 / Ubuntu 16.04を使用しています

私の問題は、NetworkManagerを介してOpenconnect VPNに接続すると、自分の作業ドメイン外のドメインのDNSを解決できなくなることでした。すなわちインターネットを失った！

私の修正はこれでした：

1. NetworkManagerで、「ネットワーク接続」の下のVPN接続を編集しました。
2. IPv4タブで、メソッドを「自動（VPN）アドレスのみ」に変更しました
3. 仕事用のDNSサーバー（例10.10.10.100）と「mywork.tld」の「検索ドメイン」を追加しました
4. 「ルート」をクリックします。
5. 10.10.0.0 / 255.255.0.0と10.10.10.253のゲートウェイなど、自分の仕事用ネットワークをカバーするルートを追加します<-「traceroute」から取得したVPNゲートウェイ。
6. 次に、両方のオプションを選択しました。「自動的に選択されたルートを無視する」ii。「この接続は、ネットワーク上のリソースにのみ使用してください」

私のコンピューターで動作します。

何が起こったかについての私の理解は、

1. 私の/etc/resolv.confはdnsmasqでセットアップされ、127.0.1.1を指しています
2. dnsmasqは、一般的なインターネットDNS解決にISPのDNSサーバーを使用しています。たとえば、ISP DNSは8.8.8.8としましょう。
3. VPNに接続すると、「mywork.tld」DNS解決に使用するdnsmasqに追加サーバーとして10.10.10.100のDNSサーバーが追加されます。
4. VPNに接続すると、仕事用のファイアウォールでポート53から8.8.8.8を使用することができなくなり、インターネットの一般的な解像度が失われます。DNSはタイムアウトし、セカンダリDNSサーバーに移動する必要がありますが、なんらかの理由でそうなりませんか？
5. このクエリはVPN経由でアクセスできる10.10.10.100に行くため、「server01.mywork.tld」のDNS解決へのアクセスのみが残されます。
6. www.google.comに対してクエリを実行すると、内部DNSが転送できても失敗します。私は、自分の内部DNSが要求されないことを前提としています。

私の作業でネットワークまたはDNSサーバーのIPアドレスが変更されない限り、私の修正は機能し続けているようです。

私は少し漠然としていますが、これが完了するとワイヤレスNICがデフォルトのネットワーク接続になるので、うまくいくと思います。したがって、DNSクエリはwifi経由で8.8.8.8に行きます。「xyz.mywork.tld」に対するクエリは、dnsmasqから10.10.10.100に移動するように指示されます。そのためのルートを設定したので、「xpn.mywork.tld」の正しい10.10.10.x IPアドレスを返す「vpn0」NICを通過します。内部および外部ネットワークのビンゴバンゴDNS解決と誰もが満足しています。