web-dev-qa-db-ja.com

OpenVPNLinuxクライアントはtap0インターフェースを起動しません

Linux上にOpenVPNサーバーに接続しているOpenVPNクライアントがあります。サーバーはDHCPを介してIPを割り当てるため、tunインターフェイスではなくtapインターフェイスを使用して接続します。

OpenVPNは接続、認証、サーバーとのチャット、そして一杯のコーヒーを飲みますが、tap0インターフェースの起動を怠ります。接続後、手動でifup tap0を実行してインターフェイスを起動し、IPを取得する必要があります。

実行した設定ファイルにupスクリプトを追加してみました

ip link set tap0 up
dhclient tap0

しかし、それはデバイスを起動しただけで、IPを取得しませんでした。

消毒されたclient.conf：

# Openvpn config to connect to <DOMAIN>
tls-client
dev tap0
; dev tap ; this didn't work either

; run script after init (supposedly)
; script-security 2 ; to run up script
; up /etc/openvpn/tap0up.sh ; bring up tap0
; up-delay ; Didn't work with or without this; 

proto udp
remote <DOMAIN> 1194
resolv-retry infinite
nobind
persist-key
persist-tun

ca ca.crt
cert monkey.crt
key monkey.key

ns-cert-type server
comp-lzo
verb 3

そしてifcfg-tap0、NetworkManagerを信じることを拒否したため

DEVICE=tap0
BOOTPROTO=dhcp
ONBOOT=yes
PEERDNS=no
ZONE=trusted

前もって感謝します！

編集：面白い事実：起動するのを忘れたネットワークの正しい静的ルートをルーティングテーブルに追加します。

Edit2： OpenVPNサーバー設定、リクエストにより：

local <my.ext.ip>
port 1194
mode server
tls-server
proto udp

dev tap0
; dev tap

ca keys/ca.crt
cert keys/zombie.crt
key keys/zombie.key
dh keys/dh2048.pem

keepalive 10 120
comp-lzo

persist-key
persist-tun

status zombievpn-status.log
verb 3
networkingvpndhcpopenvpntap
3
Chris

Ubuntu 17.10以降（およびsystemd-resolvedやnetwork-managerを使用する他のOS）でTAPデバイスを適切に機能させることは、私の経験ではあまり重要ではありませんが、多くの実験を行った後、うまく機能するセットアップにたどり着きました。

私の解決策を説明する前に、これが私の状況と要件です。 OpenVPNサーバーをホームネットワークのルーター（Asus RT-AC87UとAsus Merlinファームウェア）で実行し、DHCPサーバーも実行しています。 DHCPサーバーは、TAPインターフェイスのIPを配布するように構成され、DNS検索ドメインもプッシュします。これにより、ホスト名による接続システムの検出が可能になります（たとえば、ホスト名が「desktop」のシステムは、検索ドメイン「mydomain.com」のために「desktop.mydomain.com」に展開される「desktop」として検出できます）。 TAPネットワークを使用して、トンネルの真上でwake-on-lanを使用できるようにします（wake-on-lanマジックパケットは、システムをウェイクアップする必要があるネットワークアダプターのMACアドレスにxxx255アドレスでブロードキャストする必要があります、レベル2のパッケージをブロードキャストできるようにするために間違ったネットワーク層で動作するため、TUNデバイスが実行できないこと。サーバーはDNSオプションをクライアントにプッシュできる必要があります。すべてのインターネットトラフィックがトンネルを介してルーティングされることを望んでいません-これはその種のVPNではありません（そのユースケースでは別のポートで別のTUNサーバーを実行しますが、この回答の範囲外です）。最後に、トンネルを閉じるときに、すべてを元の状態に戻す必要があります（これは自動的には行われません）。

難しかったのはすべての実験だったことがわかりました。結局のところ、ソリューションの構成はそれほど複雑ではありません。 UbuntuリポジトリからOpenVPNをインストールしました。執筆時点でのバージョンは2.4.4です。

OpenVPNサーバーは次の構成を使用します（サーバーはDHCPサーバーとして機能する10.75.233.1（ゲートウェイIPも）でDNSMasqを実行します）。

# Automatically generated configuration
daemon ovpn-server1
server-bridge   # proxy the DHCP server
Push "route 0.0.0.0 255.255.255.255 net_gateway"
proto udp
port 1194
dev tap21
ncp-ciphers AES-256-GCM
auth SHA384
comp-lzo adaptive
keepalive 15 60
verb 2
Push "dhcp-option DNS 10.75.233.1"   # Pushes the DNS server
tls-crypt static.key
ca ca.crt
dh dh.pem
cert server.crt
key server.key
crl-verify crl.pem
status-version 2
status status 5

# Custom Configuration
mssfix 1420  # You might not need this, it depends on your local network conditions
tun-mtu 1500  # You might not need this, it depends on your local network conditions
tls-version-min 1.2
tls-cipher TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384:TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384

これらはすべてそれほど興味深いものではありません。これはクライアント設定です：

client
dev tap0
persist-tun
persist-key
proto udp
remote mydomain.com 1194
float
ncp-ciphers AES-256-GCM
auth sha384
comp-lzo adaptive
remote-cert-tls server
auth-nocache
tls-version-min 1.2
verb 2

ca /etc/openvpn/secrets/mydomain/ca.crt
cert /etc/openvpn/secrets/mydomain/client.crt
key /etc/openvpn/secrets/mydomain/client.key
tls-crypt /etc/openvpn/secrets/mydomain/ta.key

resolv-retry infinite
nobind

これもそれほど興味深いことではありませんが、アップ/ダウンスクリプトはありません[ここにblow mindgif]があります。

その理由は、既存のオペレーティングシステムサービスにできるだけ多くの処理をさせること、つまりOSの粒度に合わせて移動すること、つまり、OSの粒度に逆らうことが最もエレガントだと思うからです。インストールされているデフォルトのアップ/ダウンスクリプトは、Ubuntu 18.04が（直接）使用しない/etc/resolv.confを操作するためのものです。 systemd-resolvedを使用します。 resolv.confを直接操作すると、多くの涙が出ます、若いジェダイ。ただし、これにより、Ubuntu開発者がsystemdのアップ/ダウンスクリプトをインストールすることはありません-デフォルトで解決されます。これはあなたに任されています（Sudo apt install openvpn-systemd-resolved-スクリプトは/etc/openvpnにあります）。これらはTUNデバイスでは正常に機能しますが、私の経験では、TAPデバイスでも適切に機能しません。

うまく機能するのは、ネットワークインターフェイスに明示的にtap0デバイスを追加することです（/etc/network/interfaces）：

# interfaces(5) file used by ifup(8) and ifdown(8)
auto lo
iface lo inet loopback

allow-hotplug tap0
iface tap0 inet dhcp

以下を使用してネットワークスタックを再起動します。

Sudo systemctl daemon-reload
Sudo systemctl restart networking

ブーム！ OSは、通常のインターフェースと同様に、DHCPサーバーにすべて照会し、アダプターを起動します。サーバーに接続すると、ifconfig tap0にIPアドレスが割り当てられたアダプターが表示されます。また、systemd-resolve --statusは、出力の最初の行に、OpenVPNサーバーによってプッシュされたDNS検索ドメインとDNSサーバーがグローバル構成として設定されていることを示し、クイックnslookup desktopが機能するはずです。 （ホストがトンネルの反対側のどこかに存在する場合）。

ただし、これにより、トンネルを停止したときにいくつかの問題が発生することが判明しました。正常にダウンし、tap0デバイスはifconfig出力に表示されなくなります。ただし、systemd-resolve --statusは、検索ドメインとDNSサーバーが引き続き存在していることを示しています。私の場合、VPNサーバーを実行するドメインは「mydomain.com」であり、検索ドメインも「mydomain.com」であるため、トンネルがダウンすると、VPNサーバーに再度接続できなくなりました。 、systemd-resolvedが厄介な検索ドメインに混乱している限り、実際のIPは解決できないためです。 systemd-resolvedサービスを再起動しても問題は解決しませんが、再起動しても問題は解決します。死ぬほどの苦痛！

ありがたいことに、これに対する解決策もあります。ある種の一時的な構成ファイルが/run/systemd/resolved.conf.d/isc-dhcp-v4-tap0.confで作成されていることが判明しました。これにより、systemd-resolvedはVPNサーバーのDNSサーバーに頑固に接続されたままになります。ファイルを削除してからサービスを再起動すると、問題が修正されます（Sudo rm /run/systemd/resolved.conf.d/isc-dhcp-v4-tap0.conf && Sudo systemctl restart systemd-resolved.service）。

したがって、必要最小限の設定の場合、これで十分です。しかし、私は自分の贅沢が好きで、Niceのsystemdサービスを使ってそれを提供することができます！ UbuntuのOpenVPNパッケージでは、/etc/openvpn/clientのすべてのOpenVPN-configで「ワイルドカード」systemdサービスを利用できることに注意してください。 /lib/systemd/system/[email protected]にあるはずのユニットファイルを見ることができます。 Sudo systemctl start [email protected]で制御できます。 TUNスタイルのトンネルではまったく問題なく機能するので、そのままにしておきます。 TAPデバイスで機能するように複製します。

ファイル/lib/systemd/system/openvpn-my-tap-service-name.serviceを作成し、以下を追加します。

[Unit]
Description=OpenVPN tunnel for mydomain.com
After=syslog.target network-online.target
Wants=network-online.target
Documentation=man:openvpn(8)
Documentation=https://community.openvpn.net/openvpn/wiki/Openvpn24ManPage
Documentation=https://community.openvpn.net/openvpn/wiki/HOWTO

[Service]
Type=notify
PrivateTmp=true
WorkingDirectory=/etc/openvpn/client
ExecStart=/usr/sbin/openvpn --suppress-timestamps --nobind --config mydomain.com.conf
ExecStopPost=/etc/openvpn/post-tap0-service-stop.sh  # Removes search domain and DNS server from systemd-resolved config
CapabilityBoundingSet=CAP_IPC_LOCK CAP_NET_ADMIN CAP_NET_RAW CAP_SETGID CAP_SETUID CAP_SYS_CHROOT CAP_DAC_OVERRIDE
LimitNPROC=10
DeviceAllow=/dev/null rw
DeviceAllow=/dev/net/tun rw
ProtectSystem=true
ProtectHome=true
KillMode=process

[Install]
WantedBy=multi-user.target

これは、デフォルトのサービスを単純​​に適応させたものです。これが機能するには、クライアント構成が/etc/openvpn/client/mydomain.com.confにある必要があります。 1つだけ追加されます。「一時的な」systemdで解決された構成ファイルを削除する小さなスクリプトです。

ファイルを作成します/etc/openvpn/post-tap0-service-stop.shそして実行可能に設定します（chmod +x /etc/openvpn/post-tap0-service-stop.shを使用）：

#!/bin/bash

FILE_MESSING_WITH_SYSTEMD_RESOLVED=/run/systemd/resolved.conf.d/isc-dhcp-v4-tap0.conf

echo "Removing $FILE_MESSING_WITH_SYSTEMD_RESOLVED..."
rm -f $FILE_MESSING_WITH_SYSTEMD_RESOLVED 

echo "Restarting systemd-resolved service..."
systemctl restart systemd-resolved.service

タダ！ Sudo systemctl start/stop/restart/status openvpn-my-tap-service-nameを使用してOpenVPNを制御できるようになりました（もちろん、サービスファイルを作成した後の簡単なSudo systemctl daemon-reloadの後）。

残りの仕上げは1つだけです。常にパスワードでサービスを管理するのは面倒です。これを修正するには、サービスを制御するために必要なコマンドをsudoersファイルに追加します。

次のコマンドpkexec visudo -f /etc/sudoers.d/openvpnを実行して、次のように入力します。

Cmnd_Alias OPENVPN = /bin/systemctl start openvpn-my-tap-service-name, \
                     /bin/systemctl stop openvpn-my-tap-service-name, \
                     /bin/systemctl restart openvpn-my-tap-service-name

%my-username ALL= NOPASSWD: OPENVPN

これで、パスワードなしでサービスのSudo systemctlコマンドを実行できます。

これが役に立てば幸いです！

4
Juul

私もこの奇妙な状況に遭遇しました。 Openvpn dhcpサーバーを無効にして独自の（ブリッジ/タップモード）を使用するために失敗した作業で次の3つの変更を行うまで、Openvpnは正常に機能していました。おそらくあなたの場合、構成に反対の変更を適用する必要があるかもしれません（サーバーディレクティブを追加し、tls-serverとserver x yを削除します）。

  1. サーバー構成で、server X Yディレクティブをコメント化しました
  2. サーバー構成で、tls-serverとmode serverを追加し、IPプールオプションをコメントアウトしました。これらはすべて、server x yなしでopenvpnを起動しているときに受信した致命的なエラーメッセージに対応しています
0
regulatre