web-dev-qa-db-ja.com

PPTPエラー800/806で接続が失敗する

実稼働環境に接続できないクライアント(Server 2008 R2)がありますPPTP VPNサーバー(Server 2003、RRASを実行))。

サーバーは、TCP1723およびGREが開いているファイアウォールの背後にあります。私たちのオフィスの他のクライアントは問題なく接続できます。私たちのオフィスはJuniper SSG5-Serialファイアウォールの背後にありますが、すべての送信トラフィックが許可されており、他の複数のクライアントが問題なくVPNサーバーに接続できます。

また、オフィスの外にある別のネットワークにまったく異なるVPNサーバーをセットアップしました。機能しているクライアントは正常に接続しますが、Server 2008 R2マシンは接続しません。したがって、それは特にこのマシンの問題です。

再起動しました。ファイアウォールを無効にしました。サイコロもありません。

サーバー/クライアントでPPTPSRVとPPTPCLNTを実行しましたが、それらは完全に通信できます。TCP1723もGREも使用して問題がないことを示しています。

Server 2008 R2マシンは、VPNサーバー自体(受信接続)としても実行されており、完全に機能しています。アクティブな着信接続があるかどうかに関係なく、問題があります。

次のデバッグ手順がどうなるかわかりません。助言がありますか?

編集:サーバー上のイベントログには、RasManからの次の警告があります。

A connection between the VPN server and the VPN client xxx.xxx.xxx.xxx has been 
established, but the VPN connection cannot be completed. The most common cause
for this is that a firewall or router between the VPN server and the VPN client
is not configured to allow Generic Routing Encapsulation (GRE) packets (protocol 47).
Verify that the firewalls and routers between your VPN server and the Internet allow
GRE packets. Make sure the firewalls and routers on the user's network are also
configured to allow GRE packets. If the problem persists, have the user contact
the Internet service provider (ISP) to determine whether the ISP might be blocking
GRE packets.

明らかに、これはGREが潜在的な問題であることを示しています。しかし、他のクライアントが問題なく接続していて、PPTPSRVとPPTPCLNTが通信可能であることを考えると、これはニシンの可能性があるのではないかと疑っています。

編集:クライアントが年代順に記録した匿名化されたイベントは次のとおりです。


CoId={742CB15C-A7E0-47B7-8240-0EFA1139CBD9}: The user XXX\YYY has started dialing a VPN connection using a per-user connection profile named ZZZ. The connection settings are: 
Dial-in User = XXX\YYY
VpnStrategy = PPTP
DataEncryption = Require
PrerequisiteEntry = 
AutoLogon = No
UseRasCredentials = Yes
Authentication Type = CHAP/MS-CHAPv2 
Ipv4DefaultGateway = No
Ipv4AddressAssignment = By Server
Ipv4DNSServerAssignment = By Server
Ipv6DefaultGateway = Yes
Ipv6AddressAssignment = By Server
Ipv6DNSServerAssignment = By Server
IpDnsFlags = Register primary domain suffix
IpNBTEnabled = Yes
UseFlags = Private Connection
ConnectOnWinlogon = No.

CoId={742CB15C-A7E0-47B7-8240-0EFA1139CBD9}: The user XXX\YYY is trying to establish a link to the Remote Access Server for the connection named ZZZ using the following device: 
Server address/Phone Number = XXX.YYY.ZZZ.KKK
Device = WAN Miniport (PPTP)
Port = VPN3-4
MediaType = VPN.

CoId={742CB15C-A7E0-47B7-8240-0EFA1139CBD9}: The user XXX\YYY has successfully established a link to the Remote Access Server using the following device: 
Server address/Phone Number = XXX.YYY.ZZZ.KKK
Device = WAN Miniport (PPTP)
Port = VPN3-4
MediaType = VPN.

CoId={742CB15C-A7E0-47B7-8240-0EFA1139CBD9}: The link to the Remote Access Server has been established by user XXX\YYY.

CoId={742CB15C-A7E0-47B7-8240-0EFA1139CBD9}: The user XXX\YYY dialed a connection named ZZZ which has failed. The error code returned on failure is 806.

クライアントでWiresharkを実行すると、「71構成要求」の送信を試行して再試行することが示されます。 enter image description here

サーバーは着信クライアント要求を示していますが、明らかに応答はありません。 enter image description here

これがGREトラフィックであることを考えると、ブロックされているGREトラフィックは除外されると思います。質問は、サーバーが応答しないのはなぜですか?


これは、サーバーが機能していないクライアントから受信する構成要求です(クライアント要求に応答が送信されないことを意味します)。

enter image description here

そして、これはサーバーが動作中のクライアントから受け取る構成要求です: enter image description here

私には、キーとマジックナンバーが異なることと、1つのクライアントが応答を受信して​​いるのに他のクライアントが応答を受信して​​いないという事実を除いて、それらは同じに見えます。

6

ISPやその他のリモートの問題が解決されているとの考え。これは、スタッフがリモートで作業しているときに何度も見られました。リモートサイトのISPまたはIT部門は、VPNトラフィックをブロックします。

一部のホームルーターがPPTPを適切に許可しないという問題も見られます。直接接続してテストした後、ISPまたはホームハードウェアをポイントしました

1
Dave M