web-dev-qa-db-ja.com

OpenVPNはTCP UDPでは機能しません

Debian（Raspberry Piモデルb +）でOpenVPNサーバーを正常にセットアップしました。プロトコルがTCP=に設定されている場合、VPN経由でルーティングされるインターネット、ローカルネットワークマシンへのアクセス）のとおりに動作しますが、プロトコルをUDPに設定すると（これは、速度）その後、任意のホスト（IPアドレスまたはドメイン名）にpingを実行できることがわかります。Telnetとssh（IPアドレスまたはドメイン）を実行できますが、ブラウザでページを開こうとすると、初期接続を確立しているように見えますしかし、その後はロードされません。

UDPモードでWebブラウジングが問題になる理由はありますか？

Iptablesを管理するようにUFWを設定しました。これのメインの構成行がbefore.rulesに追加されました

*nat
:PREROUTING ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
# Allow traffic from OpenVPN client to eth0
-A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
COMMIT

すべてがTCP=で正しく機能し、UDPで非常に適切に機能するので、問題はファイアウォール/ iptablesにあるのではなく、間違っている可能性があると思います。

私のopenvpnサーバー構成は

local 192.168.0.31
dev tun
proto tcp
port 1194
ca ca.crt
cert server.crt
key server.key
dh dh1024.pem
server 10.8.0.0 255.255.255.0
ifconfig 10.8.0.1 10.8.0.2
Push "route 10.8.0.31 255.255.255.255"
Push "route 10.8.0.0 255.255.255.0"
Push "route 192.168.0.31 255.255.255.0"
Push "dhcp-option DNS 192.168.0.1"
Push "redirect-gateway def1"
Push "explicit-exit-notify 3"
client-to-client
duplicate-cn
keepalive 10 120
tls-auth ta.key 0
cipher AES-128-CBC
comp-lzo
user nobody
group nogroup
persist-key
persist-tun
status /var/log/openvpn-status.log 20
log /var/log/openvpn.log
verb 1

なぜ問題があるのか​​誰かが何か考えを持っていますか？

openvpntcpudp
7
beacon_bonanza

これらの特定の症状（VPNを使用）は、パスMTUの問題を示すかなり一般的な症状です。

MTUの基本

パスMTU（最大伝送ユニット）は、インターネット（またはその他のネットワーク）上の2つのデバイス間を行き来できる最大のパケットです。パスに沿った各リンクには独自のMTUがあり、他のMTUと一致する場合と一致しない場合があります。パス全体のMTUは、パス全体で最も低いMTUです。

コンピューターがパスMTUより大きいパケットを送信しようとすると、データパケットはそれを超えるホップでドロップされ、データは到着しません。正常に動作しているネットワークでは、コンピューターはエラー応答を受け取り、MTUを自動調整するか、後続のパケットをフラグメント化する必要があります。振る舞いの悪いネットワークでは、静かに落とされるだけかもしれません。

パスMTU（自動）検出 は、ユーザーとVPNサーバー間のMTUを自動的に検出するために使用されるメカニズムですが、TCPを使用すると、UDPを使用した場合よりも堅牢になりますTCP=が到着しないパケットを通知できる明示的なフィードバックを義務付けているため、動作したネットワーク.

VPNリンクでの動作と同じように機能するのは、VPNカプセル化ヘッダーがトンネル接続のMTUを減らし、UDPがドロップされたパケットにフィードバックを提供しないためです。

たとえば、実際のP​​MTUが1400バイトの場合、VPNを介して1400バイトのパケットを送信するには、1432バイトかかる場合があります。 TCP接続の場合、1432バイトのパケットを送信しようとすると、TCPは、それが到着していないことを通知し、それをフラグメント化して、 1400バイトのパケットと2番目の32バイトのパケット（それでも大幅な単純化です）。UDPを使用すると、メッセージが表示されずにドロップされるだけです。ただし、両方の場合、1400バイトより小さいパケットを送信します成功します。

これが、SSHとtelnetが機能するのに対し、Webブラウジングが機能しない理由です。 VPNによってMTUがデフォルトより下に減少しましたが、エラーメッセージが適切に返されないか、PMTU自動検出が機能していないため、OSは認識していません。ただし、SSHとtelnetおよびpingはすべて非常に小さなパケット（通常は100バイト未満）を使用するため、MTUが1400から1368（1400-32）に減少しても、制限よりはるかに小さいため、問題にはなりません。 。 SSHとTelnetは通常、一度に1バイトと1行の間でパケットヘッダーを送信します。 pingパケットは通常、最大64バイトにパケットヘッダーを加えたもので、これもまた、正常なMTU（1400以上）よりもはるかに小さいです。

DNS、TCP SYN/ACKパケット、およびHTTPリクエストはどちらも通常1400バイトよりはるかに小さいため、Webブラウジングは最初に接続しますが、Webサイトが実際のWebページを送信しようとするとすぐに、フルサイズのパケットを使用し、途中で静かに破棄されます。

問題の解決

簡単な（不正な）方法と、実際に問題が何であるかを理解する方法があります。

MTUを手動ではるかに低く（たとえば1000に）設定するのは、VPNの削減されたMTUでもすべてが収まるのでおかしくない方法です。これ自体は、MTUが問題であるかどうかを確認するのに適したテストです。

より良い方法は、問題がどこにあるのかを見つけて修正することです。 MTU自動検出の問題は、サーバーやISPが原因で何もできないか、ローカルのファイアウォールや構成の問題が原因で発生する可能性があります。 OpenVPNルーティングである可能性があり、ファイアウォールルールにより、ICMPエラーメッセージをマシンに戻すことが許可されていません。

中間的な方法は、真の最大MTUを把握し、それを手動で設定することです。1000バイトなどの小さなものから始めて、上に向かって動作する最も高い値を見つけることができます。基本的に、UDPを使用してVPNを接続し、コマンドping -f <server address> -l <packet size>そして、それが動作を停止するまで、タイムアウトまたはエラーのいずれかで、パケットサイズを増やします。

14
qasdfdsaq