搜索
则vpn故障造成业务中断的处理过程来源：互联网作者：佚名时间：02-2007:08:23浏览：690【大中小】客户报障描述：vpn接入系统出故障，接到N多报拆。具体为能通过ping激活vpn拨号，系统能自动弹出登陆对话框，不会报用户名和密码错误，但Netscreen-Remote客户端就是不会出现VPN成功连接后的黄色小钥匙，造成业务中断。排障过程：让客户提供一个vpn测试帐号，发现报障情况属实。查看Netscreen-RemoteLogViewer中的日志，如下：09:59:03.375MyConnections\-InitiatingIKEPhase1(IPADDR=1.1.1.1)09:59:03.406MyConnections\-SENDINGISAKMPOAKAG(SA,KE,NON,ID,VID,VID,VID,VID)09:59:03.546MyConnections\-RECEIVEDISAKMPOAKAG(SA,VID,VID,VID,VID,KE,NON,ID,HASH,VID,NAT-D,NAT-D)09:59:03.546MyConnections\-PeerisNAT-Tcapable09:59:03.546MyConnections\-NATisdetectedforClient09:59:03.562MyConnections\-SENDINGISAKMPOAKAG*(HASH,NAT-D,NAT-D,NOTIFY:STATUS_INITIAL_CONTACT)09:59:03.562MyConnections\-EstablishedIKESA09:59:03.562MYCOOKIEdece780815821bc09:59:03.562HISCOOKIE7affb1c1c737c13109:59:03.656MyConnections\-RECEIVEDISAKMPOAKTRANS*(HASH,ATTR)09:59:09.343MyConnections\-RECEIVEDISAKMPOAKTRANS*(Retransmission)09:59:15.343MyConnections\-RECEIVEDISAKMPOAKTRANS*(Retransmission)09:59:18.015MyConnections\-SENDINGISAKMPOAKTRANS*(HASH,ATTR)09:59:18.109MyConnections\-RECEIVEDISAKMPOAKTRANS*(HASH,ATTR)09:59:18.109MyConnections\-ReceivedPrivateIPAddress=IPADDR=11.2.1.23409:59:18.109MyConnections\-SENDINGISAKMPOAKTRANS*(HASH,ATTR)09:59:18.203MyConnections\-RECEIVEDISAKMPOAKTRANS*(HASH,ATTR)09:59:18.203MyConnections\-SENDINGISAKMPOAKTRANS*(HASH,ATTR)09:59:18.203MyConnections\-InitiatingIKEPhase2withClientIDs(messageid:BF484846)09:59:18.203Initiator=IPADDR=11.2.1.234,prot=0port=009:59:18.203Responder=IPSUBNET/MASK=192.168.1.0/255.255.255.0,prot=0port=009:59:18.203MyConnections\-SENDINGISAKMPOAKQM*(HASH,SA,NON,ID,ID)09:59:24.89009:59:33.875MyConnections\-QMre-keyingtimedout(messageid:BF484846).Retrycount:109:59:33.875MyConnections\-SENDINGISAKMPOAKQM*(Retransmission)09:59:46.89009:59:48.875MyConnections\-QMre-keyingtimedout(messageid:BF484846).Retrycount:209:59:48.875MyConnections\-SENDINGISAKMPOAKQM*(Retransmission)10:00:03.875MyConnections\-QMre-keyingtimedout(messageid:BF484846).Retrycount:310:00:03.875MyConnections\-SENDINGISAKMPOAKQM*(Retransmission)10:00:08.89010:00:18.875MyConnections\-Exceeded3re-keyingattempts(messageid:BF484846)从日志中可看出IKEPhase1已成功完成（红色加显），IKEPhase2未完成（蓝色加显）。接下来查看VPN服务器中相关的event，如下：2008-02-2009:56:11systeminfo00536IKE121.201.217.55Phase2msgIDa29ebdc9:Negotiationshavefailed.2008-02-2009:56:11systeminfo00536RejectedanIKEpacketonethernet1/1from121.201.217.55:500to1.1.1.1:500withcookies462e118477c5ab9cand99453c6c6b16eb87becausetheVPNdoesnothaveanapplicationSAconfigured.2008-02-2009:56:11systeminfo00536IKE121.201.217.55Phase2:NopolicyexistsfortheproxyIDreceived:localID(192.168.1.0/255.255.255.0,0,0)remoteID(11.2.1.234/255.255.255.255,0,0).2008-02-2009:56:11systeminfo00536IKE121.201.217.55Phase2msgIDa29ebdc9:Respondedtothepeer'sfirstmessage.2008-02-2009:56:11systeminfo00536IKE121.201.217.55:XAuthloginwaspassedforgatewayVPN_Gateway,usernametestuser,retry:0,ClientIPAddr11.2.1.234,IPPoolname:VPN_POOL,Session-Timeout:0s,Idle-Timeout:0s.2008-02-2009:56:00systeminfo00536IKE121.201.217.55:ReceivedinitialcontactnotificationandremovedPhase1SAs.2008-02-2009:56:00systeminfo00536IKE121.201.217.55Phase1:CompletedAggressivemodenegotiationswitha28800-secondlifetime.2008-02-2009:56:00systeminfo00536IKE121.201.217.55Phase1:Completedforusertestuser.2008-02-2009:56:00systeminfo00536IKE121.201.217.55:ReceivedinitialcontactnotificationandremovedPhase2SAs.2008-02-2009:56:00systeminfo00536IKE121.201.217.55:ReceivedanotificationmessageforDOI124578INITIAL-CONTACT.2008-02-2009:56:00systeminfo00536IKE121.201.217.55Phase1:IKEresponderhasdetectedNATinfrontoftheremotedevice.2008-02-2009:56:00systeminfo00536IKE121.201.217.55Phase1:ResponderstartsAGGRESSIVEmodenegotiations.从VPN服务器日志中可查看到更为详细的说明，从日志中可看出IKEPhase1已成功完成（红色加显），IKEPhase2未完成（蓝色加显），并对Phase2未完成原因进行了描述。VPN-SERVER-getpolicyTotalregularpolicies1,Defaultdeny.IDFromToSrc-addressDst-addressServiceActionStateASTLCB1dialupTrustDial-UpVPNappserverappserviceTunnelenabled---X-X从上面可知，系统中只有一条policy，状态为启用（enabled）。同时也可知道这是一个拨号型VPN。查看VPN服务器中的Dst-address跟Netscreen-Remote客户端中的RemotePartyIdentityandAddressing设置是否相同：VPN-SERVER-getaddresstrustnameappserverNameAddress/Prefix-lengthFlagCommentsappserver192.168.1.0/240200从上面可知，VPN服务器Dst-address与Netscreen-Remote中的RemotePartyIdentityandAddressing设置的完全匹配。接着来查看VPN服务器Policy中的Service：VPN-SERVER-getserviceappserviceName:appserviceCategory:otherID:0Flag:User-definedTransportSrcportDstportICMPtype,codeTimeout(min)Applicationtcp0/6553580/8030tcp0/655351222/122330tcp0/655352233/223430tcp0/655352344/234530tcp0/6553523/2330可以发现，放开的服务中并没有ping（ICMPtype：8，code：0），增加ping：VPN-SERVER-setserviceappservice+icmptype8code0故障解决，业务恢复正常。难道JuniperNetscreen配置xauthvpn时，一定要放开ping服务才能成功建立vpn连接？请高手指教。最后说明平台版本：客户端：NetscreenRemote8.0.0（Build14）VPN服务器：NetscreenISG-1000（SoftwareVersion:5.3.0r10.0,Type:Firewall+VPN）[收藏][推荐][评论][打印][关闭]顶一下上一篇：JuniperNetsScreen设备ScreenOS升级指南下一篇：Juniper防火墙计