
Debian サーバーに OpenVPN をセットアップしました。クライアントは接続でき、サーバー上のリソース (Samba 共有とイントラネット) に ping してアクセスできます。
ただし、サーバーはクライアントに ping を実行できず、タイムアウトしてしまいます。
図
Client OpenVPN assigned IP: 10.67.15.26
↓ UDP on 1194
Internet
↓
Router port-forwards 1194 to server
↓
Server LAN IP: 10.67.5.1
サーバーの OpenVPN 構成 (関連ビット)
port 1194
proto udp
dev tun
server 10.67.15.0 255.255.255.0
push "route 10.67.5.0 255.255.255.0"
サーバールーティングテーブル
Destination Gateway Genmask Flags Metric Ref Use Iface
10.67.15.2 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
10.67.15.0 10.67.15.2 255.255.255.0 UG 0 0 0 tun0
10.67.5.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
0.0.0.0 10.67.5.254 0.0.0.0 UG 0 0 0 eth1
サーバーファイアウォール
サーバーのファイアウォールを一時的に無効にし、すべてのチェーンのポリシーが ACCEPT になり、すべての転送フラグが設定されました。
1 : /proc/sys/net/ipv4/conf/all/forwarding
1 : /proc/sys/net/ipv4/conf/default/forwarding
1 : /proc/sys/net/ipv4/conf/lo/forwarding
1 : /proc/sys/net/ipv4/conf/eth1/forwarding
1 : /proc/sys/net/ipv4/conf/tun0/forwarding
1 : /proc/sys/net/ipv4/ip_forward
テストケース:
クライアント:ping 10.67.5.1
他のリソースと同様に機能します。
サーバー:ping 10.67.15.26
タイムアウトしました。
答え1
2 つの異なるクライアントを比較することで、2 つの問題を特定して修正することができました。
問題1: ルーティング
何らかの理由で (解決したかどうかはわかりませんが)、サーバーのルーティング テーブルは LAN (10.67.5.0/24) との間のルートを忘れ続けました。これにより、すべての送信 LAN トラフィックがメイン ゲートウェイを通過し、OpenVPN LAN (10.67.15.0/24) にルーティングされません。これにより、LAN 宛ての OpenVPN ネットワークからのトラフィックがメイン ゲートウェイで失敗し、ping は送信されましたが、応答はドロップされました。
編集:残念ながら、このルートが削除された原因はわかりません。上記のルーティング テーブルにあることがわかります。/etc/network/interfaces にルート コマンドを追加しようとしましたが、重複した同一のルートが 2 つ存在してしまったため、再度削除しました。それは私のFWビルダーこのルートがドロップされる原因となった設定: eth1 アダプタを設定するときに、/24 (LAN 用) ではなく /32 ネットマスク (つまりホスト) を指定していました。
Debian クライアントをテストすることで、この問題を解明できました。その後、クライアントは動作しましたが、Windows 7 クライアントは動作しませんでした。
問題 2: Windows 7 ファイアウォール/構成
Windows のセットアップには 2 つの問題がありました。
Windowsでは、TAPアダプタに「Work」プライベートプロファイルが設定されている必要があります。
2020-06-11 更新
次の 2 つの PowerShell コマンドを使用して、インターフェイスをプライベートに変更できます。
# this first one will let you see the available connections,
# find the interface index of the one you would like to change
Get-NetConnectionProfile
Set-NetConnectionProfile -InterfaceIndex NN -NetworkCategory Private
「ネットワークと共有センター」には、(少なくとも) 2 つの「アクティブなネットワーク」が表示されます。ワイヤレス ネットワークと「識別されていないネットワーク」がありました。後者は OpenVPN TAP デバイスで、公園のベンチのアイコンが表示されており、パブリックで信頼できないものとして扱われていることを意味します。これを変更するには、アダプタのデフォルト ゲートウェイを追加する必要があります。
DOS/Cygwinターミナルを起動する管理者として(Orb を起動 > CMD を検索 > 右クリック > 管理者として実行)。
次に、 を実行しますroute print -4
。インターフェイス リストが表示されます。各行は番号で始まり、右側に名前が表示されます。TAP-Win32 アダプターのインターフェイス番号を特定します。私の場合は 17 でした。
次にルートを追加します。
route -p add 0.0.0.0 mask 0.0.0.0 1.2.3.4 metric 500 if 17
ここで、1.2.3.4 は OpenVPN ゲートウェイの IP (前のコマンドの出力の Gateway 列に表示) であり、17 は TAP インターフェイス番号である必要があります。この-p
オプションにより、ルートが永続的になります。テストのため、最初はこのオプションなしで実行しました。これは、クライアントのOpenVPNゲートウェイIPが接続間で変更されないことを前提としています。。
完了するとダイアログボックスがポップアップし、新しいネットワークを分類するように求められます。仕事。
この時点で、会社の LAN からクライアントにトラフィックを送信できるようになりました (netcat を使用してテスト済み) が、ping はまだ応答されませんでした。
Windows に ping (ICMPv4) を許可するように指示する
Orb を起動し、セキュリティが強化された Windows ファイアウォールを選択します。次に、受信の規則、新しい規則の順に進みます...
- カスタムルール
- すべてのプログラム
- プロトコル: ICMPv4
- 接続を許可する
- プライベートプロフィールに申し込む
- それに名前を付けます。
ついにpingが返されました。