仕事で Linux を使用したいのですが、社内 VPN では使用できませんか? その場合、確実ではありませんが、この記事が役に立つかもしれません。 事前に警告しておきますが、私はネットワーク管理の問題をよく理解していないため、すべてが間違っていた可能性があります。 逆に、一般の人にもわかりやすいようにガイドを書くことはできるかもしれないので、ぜひ試してみることをお勧めします。

この記事には不要な情報が多く含まれていますが、この知識がなければ、VPN の設定で予期せず発生した問題を解決できなかったでしょう。 このガイドを使用しようとする人は、私にはなかった問題に直面すると思います。この追加情報がこれらの問題を自分で解決するのに役立つことを願っています。

このガイドで使用されるコマンドのほとんどは sudo を介して実行する必要がありますが、簡潔にするために削除されています。 覚えておいてください。

ほとんどの IP アドレスは高度に難読化されているため、435.435.435.435 のようなアドレスが表示された場合は、そのケースに特有の通常の IP がそこにあるはずです。

私は Ubuntu 18.04 を持っていますが、少し変更を加えれば、このガイドは他のディストリビューションにも適用できると思います。 ただし、本文では Linux == Ubuntu とします。

Cisco Connect

Windows または MacOS を使用しているユーザーは、Cisco Connect 経由で当社の企業 VPN に接続できます。これには、ゲートウェイ アドレスを指定する必要があり、接続するたびに、固定部分と Google Authenticator によって生成されたコードで構成されるパスワードを入力する必要があります。

Linux の場合、Cisco Connect を実行することはできませんでしたが、Cisco Connect を置き換えるために特別に作成された openconnect の使用に関する推奨事項を Google で検索することができました。

オープンコネクト

理論的には、Ubuntu には openconnect 用の特別なグラフィカル インターフェイスがありますが、私にとっては機能しませんでした。 もしかしたらそれは良い方向に向かうかもしれない。

Ubuntu では、openconnect はパッケージ マネージャーからインストールされます。

apt install openconnect

インストール後すぐに VPN への接続を試すことができます。

openconnect --user poxvuibr vpn.evilcorp.com

vpn.evilcorp.com は架空の VPN のアドレスです
poxvuibr - 架空のユーザー名

openconnect はパスワードの入力を求めます。パスワードは固定部分と Google Authenticator からのコードで構成されており、VPN への接続を試みます。 それが機能する場合は、おめでとうございます。かなり面倒な中間部分を安全にスキップして、バックグラウンドで実行されている openconnect に関するポイントに進むことができます。 うまくいかない場合は、続行できます。 たとえば、職場のゲスト Wi-Fi から接続したときに機能したとしても、喜ぶのは時期尚早かもしれません。自宅から手順を繰り返してみてください。

証明書

何も開始されない可能性が高く、openconnect の出力は次のようになります。

POST https://vpn.evilcorp.com/
Connected to 777.777.777.777:443
SSL negotiation with vpn.evilcorp.com
Server certificate verify failed: signer not found

Certificate from VPN server "vpn.evilcorp.com" failed verification.
Reason: signer not found
To trust this server in future, perhaps add this to your command line:
    --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444
Enter 'yes' to accept, 'no' to abort; anything else to view: fgets (stdin): Operation now in progress

VPN に接続できなかったため、これは不快な一方で、この問題を解決する方法は原則として明らかです。

ここで、サーバーは証明書を送信しました。これにより、接続が邪悪な詐欺師ではなく、ネイティブ企業のサーバーに行われており、この証明書がシステムに認識されていないことがわかります。 したがって、サーバーが本物かどうかを確認することはできません。 そして、念のため、動作を停止します。

openconnect がサーバーに接続するには、-servercert キーを使用して、どの証明書が VPN サーバーから取得されるべきかを明示的に指示する必要があります。

また、openconnect が出力した内容から、サーバーがどの証明書を直接送信したかを知ることができます。 この作品からは次のとおりです。

To trust this server in future, perhaps add this to your command line:
    --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444
Enter 'yes' to accept, 'no' to abort; anything else to view: fgets (stdin): Operation now in progress

このコマンドを使用すると、再度接続を試みることができます

openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr vpn.evilcorp.com

おそらく今はうまくいっているので、最後まで進むことができます。 でも個人的には、ウブンタがこんな形のイチジクを見せてくれました

POST https://vpn.evilcorp.com/
Connected to 777.777.777.777:443
SSL negotiation with vpn.evilcorp.com
Server certificate verify failed: signer not found
Connected to HTTPS on vpn.evilcorp.com
XML POST enabled
Please enter your username and password.
POST https://vpn.evilcorp.com/
Got CONNECT response: HTTP/1.1 200 OK
CSTP connected. DPD 300, Keepalive 30
Set up DTLS failed; using SSL instead
Connected as 192.168.333.222, using SSL
NOSSSSSHHHHHHHDDDDD
3
NOSSSSSHHHHHHHDDDDD
3
RTNETLINK answers: File exists
/etc/resolvconf/update.d/libc: Warning: /etc/resolv.conf is not a symbolic link to /run/resolvconf/resolv.conf

/etc/resolv.conf

# Generated by NetworkManager
search gst.evilcorpguest.com
nameserver 127.0.0.53

/run/resolvconf/resolv.conf

# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
# 127.0.0.53 is the systemd-resolved stub resolver.
# run "systemd-resolve --status" to see details about the actual nameservers.

nameserver 192.168.430.534
nameserver 127.0.0.53
search evilcorp.com gst.publicevilcorp.com

habr.com は解決されますが、そこにはアクセスできなくなります。 jira.evilcorp.com のようなアドレスはまったく解決されません。

ここで何が起こったのか私には分かりません。 しかし、実験では、/etc/resolv.conf に行を追加すると、

nameserver 192.168.430.534

そうすれば、VPN 内のアドレスが魔法のように解決され始め、それらをたどることができます。つまり、DNS がアドレスを解決するために探しているものは、他の場所ではなく、特に /etc/resolv.conf 内にあります。

/etc/resolv.conf に変更を加えることなく、VPN への接続が存在し、機能することを確認できます。これを行うには、VPN からのリソースのシンボリック名ではなく、その IP アドレスをブラウザに入力するだけです。

その結果、２つの問題が発生しました

• VPN に接続するときに、DNS が取得されない
• すべてのトラフィックは VPN を経由するため、インターネットへのアクセスは許可されません

これから何をすべきかを説明しますが、最初に少し自動化します。

パスワードの固定部分の自動入力

おそらく、これまでに少なくとも XNUMX 回はパスワードを入力しており、この手順にはすでにうんざりしているでしょう。 XNUMX つ目はパスワードが長いため、XNUMX つ目は入力時に一定時間内に収める必要があるためです。

この問題の最終的な解決策は記事には記載されていませんが、パスワードの固定部分を何度も入力する必要がないことを確認できます。

パスワードの固定部分が fixPassword で、Google Authenticator からの部分が 567 であると仮定します。パスワード全体は、--passwd-on-stdin 引数を使用して標準入力経由で openconnect に渡すことができます。

echo "fixedPassword567987" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr vpn.evilcorp.com --passwd-on-stdin

これで、最後に入力したコマンドに常に戻って、そこで Google Authenticator の一部のみを変更できるようになります。

企業 VPN ではインターネットを閲覧できません。

一般に、Habr にアクセスするために別のコンピューターを使用する必要がある場合は、それほど不便ではありません。 stackoverfow からコピー＆ペーストできないと、一般に作業が麻痺する可能性があるため、何らかの対処が必要です。

内部ネットワークからリソースにアクセスする必要がある場合は Linux が VPN にアクセスし、Habr にアクセスする必要がある場合はインターネットにアクセスするように、何らかの方法で整理する必要があります。

openconnect は、起動して vpn との接続を確立した後、/usr/share/vpnc-scripts/vpnc-script にある特別なスクリプトを実行します。 いくつかの変数が入力としてスクリプトに渡され、VPN が構成されます。 残念ながら、ネイティブ スクリプトを使用して企業 VPN とインターネットの残りの部分の間でトラフィック フローを分割する方法を理解できませんでした。

どうやら、vpn-slice ユーティリティは私のような人のために特別に開発されたようで、これを使用すると、タンバリンで踊らずに XNUMX つのチャネルを通じてトラフィックを送信できます。 つまり、踊らなければなりませんが、シャーマンである必要はありません。

vpn-slice を使用したトラフィック分離

まず、vpn-slice をインストールする必要があります。これは自分で解決する必要があります。 コメントに質問があれば、これについて別の記事を書きます。 ただし、これは通常の Python プログラムなので、難しいことはありません。 virtualenvを使用してインストールしました。

次に、-script スイッチを使用してユーティリティを適用し、標準スクリプトの代わりに vpn-slice を使用する必要があることを openconnect に示す必要があります。

echo "fixedPassword567987" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr --passwd-on-stdin 
--script "./bin/vpn-slice 192.168.430.0/24  " vpn.evilcorp.com 

--script には、スクリプトの代わりに呼び出す必要があるコマンドを含む文字列が渡されます。 ./bin/vpn-slice - vpn-slice 実行可能ファイルへのパス 192.168.430.0/24 - vpn に移動するアドレスのマスク。 ここで、アドレスが 192.168.430 で始まる場合、このアドレスを持つリソースを VPN 内で検索する必要があることを意味します。

状況はほぼ正常になっているはずです。 ほとんど。 これで、Habr にアクセスし、IP によって企業内リソースにアクセスできるようになりますが、シンボル名によって企業内リソースにアクセスすることはできません。 ホスト内のシンボリック名とアドレスの一致を指定すると、すべてが機能するはずです。 そしてIPが変わるまで作業します。 Linux は、IP に応じてインターネットまたはイントラネットにアクセスできるようになりました。 ただし、アドレスを決定するために企業以外の DNS が依然として使用されています。

この問題は、このような形で現れることもあります。職場ではすべて問題ありませんが、自宅では IP 経由でのみ社内リソースにアクセスできます。 これは、VPN を使用せずにそのようなアドレスにアクセスすることは依然として不可能であるにもかかわらず、企業 Wi-Fi に接続している場合は企業 DNS も使用され、VPN からのシンボリック アドレスがそこで解決されるためです。

hostsファイルの自動変更

vpn-slice が丁寧に要求された場合、VPN を立ち上げた後、DNS に移動し、そこで必要なリソースの IP アドレスを記号名で見つけてホストに入力できます。 VPN をオフにすると、これらのアドレスはホストから削除されます。 これを行うには、シンボリック名を vpn-slice に引数として渡す必要があります。 このような。

echo "fixedPassword567987" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr --passwd-on-stdin
--script "./bin/vpn-slice 192.168.430.0/24  jira.vpn.evilcorp.com git.vpn.evilcorp.com " vpn.evilcorp.com 

これで、オフィスでもビーチでもすべてが機能するはずです。

VPN によって指定された DNS 内のすべてのサブドメインのアドレスを検索します。

ネットワーク内にアドレスがほとんどない場合は、hosts ファイルを自動的に変更するアプローチが非常にうまく機能します。 ただし、ネットワーク上に大量のリソースがある場合は、zoidberg.test.evilcorp.com のような行をスクリプトに常に追加する必要があります。zoidberg はテストベンチの XNUMX つの名前です。

しかし今では、なぜこの必要性を排除できるのかが少し理解できました。

VPN を立ち上げた後、/etc/hosts を見ると、次の行が表示されます。

192.168.430.534 dns0.tun0 # vpn-slice-tun0 自動作成

そして、resolv.conf に新しい行が追加されました。 つまり、vpn-slice は、vpn の DNS サーバーがどこにあるかを何らかの方法で決定しました。

ここで、evilcorp.com で終わるドメイン名の IP アドレスを見つけるために、Linux が企業 DNS にアクセスし、何か他のものが必要な場合はデフォルトの DNS にアクセスすることを確認する必要があります。

かなり長い間グーグルで調べたところ、Ubuntuではそのような機能がそのまま利用できることがわかりました。 これは、ローカル DNS サーバー dnsmasq を使用して名前を解決できることを意味します。

つまり、Linux が常にローカル DNS サーバーにアクセスして IP アドレスを取得し、ドメイン名に応じて、対応する外部 DNS サーバーで IP を検索するようにすることができます。

ネットワークとネットワーク接続に関連するすべてを管理するために、Ubuntu は NetworkManager を使用します。たとえば、Wi-Fi 接続を選択するためのグラフィカル インターフェイスはそのフロントエンドにすぎません。

その構成を登る必要があります。

1. /etc/NetworkManager/dnsmasq.d/evilcorp にファイルを作成します

アドレス=/.evilcorp.com/192.168.430.534

evilcorpの前のポイントに注目してください。 これは、evilcorp.com のすべてのサブドメインを企業 DNS で検索する必要があることを dnsmasq に通知します。

1. 名前解決に dnsmasq を使用するように NetworkManager に指示します

ネットワークマネージャーの設定は /etc/NetworkManager/NetworkManager.conf にあります。そこに以下を追加する必要があります。

[メイン] dns=dnsmasq

1. ネットワークマネージャーを再起動します

service network-manager restart

これで、openconnect と vpn-slice を使用して VPN に接続した後、vpnslice の引数にシンボリック アドレスを追加しなくても、IP は正常に決定されます。

VPN経由で各サービスにアクセスする方法

VPN に接続できた後、XNUMX 日間非​​常に満足していましたが、オフィス ネットワークの外部から VPN に接続するとメールが機能しないことがわかりました。 おなじみの症状ですね。

私たちのメールは mail.publicevilcorp.com にあります。つまり、dnsmasq のルールに該当せず、メール サーバー アドレスはパブリック DNS を通じて検索されます。

そうですね、オフィスではまだこのアドレスを含む DNS を使用しています。 そう思いました。 実際、dnsmasq に行を追加した後、

アドレス=/mail.publicevilcorp.com/192.168.430.534

状況はまったく変わっていません。 IPはそのままでした。 仕事に行かなければなりませんでした。

そしてその後、私が状況をさらに深く掘り下げて問題を少し理解したとき、一人の賢い人がそれを解決する方法を教えてくれました。 そのままではなくVPN経由でメールサーバーに接続する必要がありました

vpn-slice を使用して、VPN を経由して 192.168.430 で始まるアドレスにアクセスします。 また、メール サーバーには、evilcorp のサブドメインではないシンボリック アドレスがあるだけでなく、192.168.430 で始まる IP アドレスもありません。 そしてもちろん、彼は一般のネットワークからの誰も彼のところに来ることを許可していません。

Linux が VPN を経由してメール サーバーにアクセスできるようにするには、Linux を vpn-slice にも追加する必要があります。 メーラーのアドレスが 555.555.555.555 であるとします。

echo "fixedPassword567987" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr --passwd-on-stdin
--script "./bin/vpn-slice 555.555.555.555 192.168.430.0/24" vpn.evilcorp.com 

XNUMX つの引数で VPN を起動するスクリプト

もちろん、これらすべてはあまり便利ではありません。 はい、テキストを手で入力する代わりに、ファイルに保存してコンソールにコピー＆ペーストすることもできますが、それでもあまり快適ではありません。 プロセスを簡単にするために、PATH に配置されるスクリプトでコマンドをラップできます。 あとは、Google Authenticator から受け取ったコードを入力するだけです。

#!/bin/sh  
echo "fixedPassword$1" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr --passwd-on-stdin 
--script "./bin/vpn-slice 192.168.430.0/24  jira.vpn.evilcorp.com git.vpn.evilcorp.com " vpn.evilcorp.com 

スクリプトを connect~evilcorp~ に置くと、コンソールに簡単に書くことができます。

connect_evil_corp 567987

ただし、何らかの理由で、openconnect が実行されているコンソールを開いたままにする必要があります。

バックグラウンドでの openconnect の実行

幸いなことに、openconnect の作成者が私たちの世話をしてくれて、プログラム -background に特別なキーを追加しました。これにより、プログラムは起動後にバックグラウンドで動作するようになります。 このように実行すると、起動後にコンソールを閉じることができます

#!/bin/sh  
echo "fixedPassword$1" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 
--user poxvuibr 
--passwd-on-stdin 
--background 
--script "./bin/vpn-slice 192.168.430.0/24  jira.vpn.evilcorp.com git.vpn.evilcorp.com " vpn.evilcorp.com  

現在、ログがどこに行くのかは明らかではありません。 一般に、ログは実際には必要ありませんが、それはわかりません。 openconnect はそれらを syslog にリダイレクトし、そこで安全に保管されます。 コマンドに –syslog スイッチを追加する必要があります

#!/bin/sh  
echo "fixedPassword$1" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 
--user poxvuibr 
--passwd-on-stdin 
--background 
--syslog 
--script "./bin/vpn-slice 192.168.430.0/24  jira.vpn.evilcorp.com git.vpn.evilcorp.com " vpn.evilcorp.com  

そのため、openconnect がバックグラウンドで動作しており、誰にも迷惑をかけていないことがわかりましたが、それを停止する方法は不明です。 つまり、もちろん、grep を使用して ps 出力をフィルタリングし、名前に openconnect が含まれるプロセスを探すこともできますが、これはどういうわけか面倒です。 これも考えてくれた作者さんに感謝です。 Openconnect にはキー -pid-file があり、これを使用して openconnect にプロセス識別子をファイルに書き込むように指示できます。

#!/bin/sh  
echo "fixedPassword$1" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 
--user poxvuibr 
--passwd-on-stdin 
--background  
--syslog 
--script "./bin/vpn-slice 192.168.430.0/24  jira.vpn.evilcorp.com git.vpn.evilcorp.com " vpn.evilcorp.com  
--pid-file ~/vpn-pid

コマンドでいつでもプロセスを強制終了できるようになりました。

kill $(cat ~/vpn-pid)

プロセスがない場合、kill は呪いますが、エラーはスローしません。 ファイルが存在しない場合でも、悪いことは何も起こらないため、スクリプトの最初の行でプロセスを安全に強制終了できます。

kill $(cat ~/vpn-pid)
#!/bin/sh  
echo "fixedPassword$1" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 
--user poxvuibr 
--passwd-on-stdin 
--background 
--syslog 
--script "./bin/vpn-slice 192.168.430.0/24  jira.vpn.evilcorp.com git.vpn.evilcorp.com " vpn.evilcorp.com  
--pid-file ~/vpn-pid

これで、コンピュータの電源を入れ、コンソールを開いてコマンドを実行し、Google Authenticator からのコードを渡します。 その後、コンソールを釘で固定することができます。

VPN スライスなし。 あとがきの代わりに

VPN スライスなしでどうやって生きていくかを理解するのは非常に難しいことがわかりました。 たくさん本を読んだり、グーグルしたりする必要がありました。 幸いなことに、問題に多くの時間を費やした後では、技術マニュアルや OpenConnect さえも刺激的な小説のように読めます。

その結果、vpn-slice はネイティブ スクリプトと同様に、ルーティング テーブルを別のネットワークに変更することがわかりました。

ルーティングテーブル

簡単に言うと、これは最初の列に Linux が経由するアドレスの先頭を示し、XNUMX 番目の列にこのアドレスでどのネットワーク アダプターを経由するかを示す表です。 実際にはもっと多くの発言者がいますが、本質は変わりません。

ルーティング テーブルを表示するには、ip Route コマンドを実行する必要があります。

default via 192.168.1.1 dev wlp3s0 proto dhcp metric 600 
192.168.430.0/24 dev tun0 scope link 
192.168.1.0/24 dev wlp3s0 proto kernel scope link src 192.168.1.534 metric 600 
192.168.430.534 dev tun0 scope link 

ここで、各行は、あるアドレスにメッセージを送信するためにどこに行く必要があるかを担当します。 192.168.0.0 つ目は、アドレスをどこから開始するかの説明です。 16/192.168 がアドレスが XNUMX で始まることを意味することを判断する方法を理解するには、IP アドレス マスクとは何かをグーグルで検索する必要があります。 dev の後には、メッセージの送信先となるアダプターの名前があります。

VPN 用に、Linux は仮想アダプター tun0 を作成しました。 この回線により、192.168 で始まるすべてのアドレスのトラフィックが確実に通過します。

192.168.0.0/16 dev tun0 scope link 

次のコマンドを使用して、ルーティング テーブルの現在の状態を確認することもできます。 ルート-n (IP アドレスは巧妙に匿名化されます) このコマンドは別の形式で結果を生成するため、一般に非推奨ですが、その出力はインターネット上のマニュアルによく掲載されており、それを読める必要があります。

ルートの IP アドレスがどこから開始されるべきかは、Destination 列と Genmask 列の組み合わせから理解できます。 Genmask の数値 255 に対応する IP アドレスの部分は考慮されますが、0 がある部分は考慮されません。 つまり、宛先 192.168.0.0 とジェンマスク 255.255.255.0 の組み合わせは、アドレスが 192.168.0 で始まる場合、そのアドレスへのリクエストはこのルートに沿って送信されることを意味します。 宛先が 192.168.0.0 で、Genmask が 255.255.0.0 の場合、192.168 で始まるアドレスへのリクエストはこのルートに沿って送信されます。

vpn-slice が実際に何をしているのかを理解するために、前後のテーブルの状態を確認することにしました。

VPNをオンにする前はこんな感じでした

route -n 

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         222.222.222.1   0.0.0.0         UG    600    0        0 wlp3s0
222.222.222.0   0.0.0.0         255.255.255.0   U     600    0        0 wlp3s0
333.333.333.333 222.222.222.1   255.255.255.255 UGH   0      0        0 wlp3s0

vpn-slice なしで openconnect を呼び出した後、次のようになりました

route -n

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         0.0.0.0         0.0.0.0         U     0      0        0 tun0
0.0.0.0         222.222.222.1   0.0.0.0         UG    600    0        0 wlp3s0
222.222.222.0   0.0.0.0         255.255.255.0   U     600    0        0 wlp3s0
333.333.333.333 222.222.222.1   255.255.255.255 UGH   0      0        0 wlp3s0
192.168.430.0   0.0.0.0         255.255.255.0   U     0      0        0 tun0
192.168.430.534 0.0.0.0         255.255.255.255 UH    0      0        0 tun0

そして、このようにvpn-sliceと組み合わせてopenconnectを呼び出した後

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         222.222.222.1   0.0.0.0         UG    600    0        0 wlp3s0
222.222.222.0   0.0.0.0         255.255.255.0   U     600    0        0 wlp3s0
333.333.333.333 222.222.222.1   255.255.255.255 UGH   0      0        0 wlp3s0
192.168.430.0   0.0.0.0         255.255.255.0   U     0      0        0 tun0
192.168.430.534 0.0.0.0         255.255.255.255 UH    0      0        0 tun0

vpn-slice を使用しない場合、openconnect は、特に指定されたものを除くすべてのアドレスが vpn 経由でアクセスする必要があることを明示的に書き込むことがわかります。

これはそれです：

0.0.0.0         0.0.0.0         0.0.0.0         U     0      0        0 tun0

その隣に別のパスがすぐに示されます。Linux が通過しようとしているアドレスがテーブルのどのマスクにも一致しない場合は、このパスを使用する必要があります。

0.0.0.0         222.222.222.1   0.0.0.0         UG    600    0        0 wlp3s0

この場合、標準の Wi-Fi アダプターを使用する必要があることは、すでにここに書かれています。

VPN パスはルーティング テーブルの最初のパスであるため、使用されていると思います。

そして理論的には、このデフォルト パスをルーティング テーブルから削除すると、dnsmasq openconnect と併用することで通常の動作が確保されるはずです。

私は試した

route del default

そしてすべてがうまくいきました。

vpn-slice を使用しないメールサーバーへのリクエストのルーティング

ただし、アドレス 555.555.555.555 のメール サーバーもあり、これにも VPN 経由でアクセスする必要があります。 そこへのルートも手動で追加する必要があります。

ip route add 555.555.555.555 via dev tun0

そして今はすべて順調です。 したがって、vpn-slice がなくても実行できますが、何をしているのかをよく理解する必要があります。 現在、ネイティブの openconnect スクリプトの最後の行にデフォルト ルートの削除と、VPN 接続後のメーラーのルートを追加して、自転車の可動部分を減らすことを検討しています。

おそらく、VPN の設定方法を理解するには、このあとがきだけで十分でしょう。 しかし、何をどのようにすればよいかを理解しようとしている間、著者にとっては役に立ちますが、何らかの理由で私にとっては役に立たないこのようなガイドをかなりたくさん読みました。そこで、見つけたすべての部分をここに追加することにしました。 そのようなことはとても嬉しいです。

出所： habr.com