ipsec验证xl2tpd报错：handle_packet: bad control packet!

使用ipsec和xl2tpd搭建好vpn后，使用ipsec密钥方式不能连接，显示 “连接的时候被远程服务器中止”

使用xl2tpd -D查看连接情况，尝试连接了许多次，错误如下：

开始不确定问题所在，查看ppp连接日志:

/etc/ppp/option.xl2tpd中增加一行：

logfile  /var/log/xl2tpd.log

 

重新在win10上面连接vpn，发现日志出现许多如下字符：

auth chap ms-v2

后来发现可能是协议的问题

在/etc/ppp/options.l2tpd增加+mschap-v2即可，增加后，重启ipsec，即可连接成功。

 

 

 

 

以下为转载资料：http://www.gpxz.com/diannao/hulianwang/432244.html

15 PPP认证、压缩和加密

　　IPsec被用来开L2TP隧道，L2TP在运行时开PPP隧道。PPP有几种认证法子。最常用的是PAP（不加密口令）和CHAP（基于认证的挑战/回应）。你可以自由地选择两者，最好是CHAP。如果你用PAP，Windows客户会提示口令没有加密。这有点离题，IPsec已经加密了。 PAP和CHAP都是IETE标准，但微软收购并增强了CHAP，推出一一个新的MS-CHAP（最近断定为MS-CHAPv2）。

　　默认情况下，Windows客户会使用MS-CHAP进行PPP认证。问题是大多数发行版包含的PPP服务不支持MS-CHAP，比如 Red Hat Linux 9或更早的版。一个解决法子是配置每个Windows客户使用CHAP。另一个解决法子是更新pppd到包含MS-CHAP (v2)的2.4.2或更高版本。如果你连接一个不支持MS-CHAP的服务器，客户端配置为使用MS-CHAP，pppd将会提示 “auth chap 81”和“peer will not authorize”。一但你安装一个支持MS-CHAP的pppd，你需要在 /etc/ppp/options.l2tpd增一行（根据你的pppd版本，参照man pppd）：

　　+mschap-v2

　　或者

　　require-chapms-v2

　　使用PAP或(MS-)CHAP最容易的法子是一个口令文件（secrets）。口令文件指定为/etc/ppp/chap-secrets或者 /etc/ppp/pap-secrets（分别对应于PAP还是CHAP/MS-CHAP）。当用户数量较多而更为繁杂的情况下，你也许会寻找更为灵活的东西。这是来自文档（毕竟它是PPP出版）的一小部分，但是这有多种可能的解决方案：

　　在l2tpd.conf中使用“unix authentication”关键字。账户名和口令将依靠Linux用户数据库（/etc/passwd）来检查。为PPP选项增加“login”关键字后会它会做什么。记住，你最好使用PAP，因为(MS-)CHAP不能使用保存在/etc/pssswd文件中的预加密用户口令。账户名仍由/etc/ppp/pap-secrets指定，但是在这个文件中口令为空字符串（“”）时，pppd使用Unix口令。参见：man pppd。

　　pppd2.4.2以上版本包含了RADIUS插件（radius.so，radattr.so），允许你依靠RADIUS服务对用户进行认证。在有利用RADIUS和MySQL的安装示范。他们使用pppd，同样也适用于L2TP。

　　pppd2.4.3及以上版本包含了一个由Samba小组的Andrew Bartlet供给的winbind插件(winbind.so)，它供给依靠Samba或Windows域控制器使用MS-CHAP或MS-CHAPv2对用户认证的能力。Andrew发布了安装文档：http: //hawkerc.net/staff/abartlet/comp3700/final-report.pdf。

　　多数ppp守护进程目前编译时都有PAM支持。这意味着你可以使用所有的认证机制来认证。例如：插入上面提到的winbind插件，你可以用像 pam smb（包含pam_smb_auth）、pam_winbind或pam_ntdom（已经停止）的模块依靠Samba或Windows服务器认证。还有，你可以用pam_ldap来依靠LDAP服务认证。

　　在/etc/ppp/options.l2tpd中指定noauth，你就可以完全忘记PPP认证。它可以在任何版本的pppd上工作，因为它不再要求客户进行PPP认证（当然客户仍然有IPsec认证）。但是，这还算是一个比较猛烈的解决办法。你不应该简单地省去PPP认证，尽管它不会对整个安全增强多少。

　　微软也开发了MPPE，一种PPP加密协议。它基于RSA安全体系RC4加密算法，并且被用到了PPTP中。通常，你不要想使用MPPE与 L2TP/IPsec结合使用，因为它意味着IPsec和MPPE双重加密。有时Windows客户想强制使用MPPE。如果那样的话，在那些 Windows客户上禁用加密。这可能把用户搞混。他禁用MPPE加密，认为根本没有任何加密，IPsec已经供给了加密，但是用户大概不会知道这些。一些Windows客户也支持压缩。你注意，这是PPP压缩，不是IPsec压缩（IPCOMP）。微软使用的压缩协议(MPPC)是有专利限制的。如果你仍想使用MPPC，参考配置一个LINUX PPP服务器()。

　　16.1 安装和配置PPP（LINUX）

　　一旦L2TP连接启用，它将控制权移交给PPP守护进程。明显地，你需要一个PPP服务。几乎每个发行版都有一个pppd。安装一个最新的版本，比如2.4.1或更高。另外，相同的PPP软件也可以用来做点别的事情（比如：用于拨号连接的模拟调制解调器）。幸运的是，你可以在l2tpd.conf 文件中用pppoptfile参数来为L2TP守护进程指定一个单独的PPP选项文件。

　　注意：PPP守护进程的口令共享给所有PPP进程，不仅仅是l2tpd启动的那个。可是，你可以限制用户名/口令的有效性到某些IP地址，就像这个chap-secrets示例文件那样。

 

# Secrets for authentication using CHAP

　　# client　　　　server　secret　　　　　　　　　IP addresses

　　jacco　　　　　 *　　　 "mysecret"　　　　　　　192.168.1.128/25

　　*　　　　　　　 jacco　 "mysecret"　　　　　　　192.168.1.128/25

　　sam　　　　　　 *　　　 "rumpelstiltskin"　　　 192.168.1.5

　　*　　　　　　　 sam　　 "rumpelstiltskin"　　　 192.168.1.5

　　每个用户都有两个入口，两端的认证。在这种情况下，用户jacco将从像/etc/l2tpd/l2tpd.conf文件中指定的l2tpd的 IP地址池（在示范配置文件中是192.168.1.128——192.168.1.254符合192.168.1.128/25） 获得一个地址。用户 sam总是从PPP服务获得192.168.1.5。这是一种给用户在你的内部局域网上的固定虚拟地址的法子（它看起来能工作，但是不能100%确认在任何情况下都能工作）。如果你不想在IP地址作任何限制，你可以使用通配符“*”来代替IP地址（不推荐这样，因为它会允许用户自己断定自己的地址，有一定的风险）。

　　微软客户端有一个选项“登录到Windows”如果启用它，客户端尝试用“DOMAINNAMEusername”验证。另外，你还可以在chap-secrets或者pap-secrets文件中指定这个用户名款式。

　　关于解决如何配置PPP服务器这个主题的资料很多，如PPP Howto（）。

　　简单点，我们假设你的Linux服务器外网接口是eth0，并且内网接口是eth1。PPP服务允许远程用户用一个内网的IP地址，一旦用户连接上，ppp0介面将会自动启动。l2tpd.conf中有一行“local ip”，用这个参数指定内网的一个固定IP地址供L2TP守护进程使用。

　　你看到的PPP选项文件示范那样（/etc/ppp/options.l2tpd），你也可以指定DNS和WINS服务器，当连接成功后，远程客户将会自动获得这些参数。一般情况下，你应该为远程客户指定的DNS/WINS就像直接连接的内网客户一样。可是，Windows 2000/XP自己的L2TP/IPsec客户端好象只支持获这些DNS/WINS服务器（当它的Internet连接配置为动态IP地址时）。

　　注：options.l2tpd包含proxyarp参数。这个参数将在内网接口（示例中的eth1）为远程用户打开一个代理ARP入口。如果这个关键字没有指定，Windows客户端发出的数据包将到达内网服务器，但这些服务器不知道向哪儿发出回应，因为没有人回答它的ARP请求。用 proxyarp参数，内网机器被到远程Windows客户到网关发送进来的数据包欺骗。网关让IP继续向前，因此它知道如何发送数据到Windows客户端。

　　16.2 MTU问题

　　你的VPN连接有断断续续的问题，它可能是一个MTU问题。你大概会看这样的问题：你可以ping内网的机器，并且你可以复制非常小的文件，但是你不能复制大文件，因为连接中断。试着在/etc/ppp/options.l2tp文件中增加以下几行减少MTU到1410（或许更低）。

　　mtu 1400

　　mru 1400

　　当你的连接通过VPN到用broken Path MTU Discovery站点时，这个问题可能特别明显。大概用PPTP或PPPoE的 ADSL连接同样有这样的问题。如果认证成功前连接失败，减少PPP数据包的大小是没有用的。试着使用更小的证书或不使用被NAT的连接。

　　FreeS/WAN的邮件列表中有一些讨论，FreeS/WAN小组写到：“可以在ipsec.conf的配置安装用一节用 overridemtu=参数改变MTU。”一般情况下，这个参数仅支持KLIPS，不支持26sec。其它的提有，减少你的证书大小（短姓名，更少的 X.509v3选项等），或用IPCOMP压缩。你也可以试着强制你的以太网接口使用一个更小的MTU：ifconfig ethx mtu 1400。

　　Cisco也有关于这一问题的一些文档。微软知识库中的Q314053解释了如何为一个指定的适配器设置MTU。

　　17 再次开始L2TP/IPsec连接

　　到这里，你已经配置好了IPsec、L2TP、PPP，在Windows或Mac客户端再次开始VPN连接，这个过程和上边的一样，但这一次 L2TP连接应该正常启动，如果成功了，祝贺你，你获得了一个成功的L2TP/IPsec配置。如果它不成功，检查你的设置，也可以看下面的“检查并修理故障”。

　　有两种比较好的检查办法：

　　1、在客户端和服务器之间放一台计算机，你可以用这台计算机靠tcpdump或Ethereal这样的网络监视程序来sniff客户端和服务器之间的通信。数据包必须被加密，如果你看到未被加密的数据包（举例来说，出现文本“L2TP”），说明你的设置有问题。

 

2、在客户端使用nmap或其它更好的端口扫描工具来扫描服务器上开放的端口（用法：nmap –sU 123.123.123.123），你不应该能看到L2TP守护进程（UDP 1701），打开的端口应该只有IKE（UDP 500）和随意的UDP端口，比如4500（NAT-T）。

　　18 对L2TP/IPsec的一些评论

　　在第一次测试期间，我忘了在Windows工作站的TCP/IP配置里输入默认网关和主机名，对于Linux服务器在本地网络来说真的不是一个问题，可是当我从Windows客户端向Linux服务器发起一个连接时，l2tpd在/var/log/message里提示一个有点模糊的错误信息 “Specify you hostname”，最初我想大概是l2tpd不能探测到正在运行的Linux服务器的主机名，我在Windows工作站里输入主机名后这个问题解决了，我只是简单地认为l2tpd不需要它。

　　19 NAT-Traversal

　　19.1 绪论

　　在客户端和IPsec服务器之间有时需要网络地址转换（NAT：Network Address Translation）。比如：当用户把他所有的计算机联网并通过一个NAT路由器共享上互联网。还有一种情况是VPN服务器自己位于NAT设备（UDP 500、4500传送到VPN服务器）之后。甚至在有些情况下客户端和服务器都位于NAT之后。有些ISP也使用在他们的路由器上使用NAT，我们看到许多GPRS服务商使用NAT，比如，他们给GPRS电话分配10.x.x.x或192.168.x.x地址。

　　NAT将在数据包穿过时改变它。问题是VPN会设法防止数据包改变。一些NAT设备支持“IPsec passthrough”，允许一次一个用户的IPsec通过，相同的NAT设备后的不允许多个连接的用户。

　　如果同L2TP/IPsec一起使用NAT-T，考虑到是实验性的并且不安全。Linux kernel 2.6包含的一个不同的IPsec执行者（“26sec”）也支持NAT-T。显然它也有与Openswan等的NAT-T补丁相同的安全问题。26sec执行者支持KAME用户态程序（多数发行版的ipsec-tools）也支持Openswan/Strongswan/FreeS/WAN 2.x。切换到ipsec-tools并不能改变安全问题。

　　19.2 局限性和需求

　　NAT-T支持26sec（推荐kernel 2.6.6及以上），最新的发行版如Fedora Core2+、 Debian unstable、Mandrake 10.0+、SuSE 9.1+使用了带26sec的内核，支持NAT-T。如果你在内核中使用 KLIPS代替26sec，你需要Mathieu Lafon的NAT-Traversal补丁（ source.arkoon.net/）。注：根据Mathieu，NAT-T在传输模式（Transport Mode）可能不安全。微软、SSH、 SafeNet不支持NAT-T，但他大概会对非安全工作区拿出一个方案。老版的Red HAT、Mandrake、SuSE内核没有包含KLIPS的 NAT-T补丁，对于这些版，你将需要重新编译内核，因为NAT-T补丁涉及到了内核的TCP/IP部分。如果你用的是FreeS/WAN用户态工具，你还要打这个补丁。Openswan和Strongswan已经包含了这个补丁。打过补丁后的FreeS/WAN在Makefile明确启用了传送模式下 NAT-T。Openswan和Strongswan已经支持传送模式下NA-T。

　　Openswan的NAT-T支持对26sec和KLIPS都有效，在配置文件ipsec.conf中添加“nat_traversal=yes”即可，客户端不在NAT后面不受影响，客户端的任何程序都仍将正常工作。

　　KLIPS的NAT-T补丁目前不支持使用“预共享密钥”认证的连接。如果你在KILPS和NAT-T使用了“预共享密钥”，Openswan将不允许连接，因为发送者的端口不是500，并且NAT-T补丁不能支持它，这应该引起程序员的注意。“预共享密钥”有一些缺点，因此你应该使用证书。 26sec执行者支持“预共享密钥”，但你将不得不使用right=%any、leftid=和rightid=。如果你用right=a.b.c.d指定了一个IP地址，但没有left=和right=，Openswan会提示“no connection authorized”。

　　如果你在同一NAT设备后面有多个客户端，只有第一个客户端可以连接，这大概是Linux内核的一个限制。另一个限制大概是客户端不能共享相同的NAT-ed（internal）地址。当然这十分难以消除，尤其是远程客户端之间的一个小的团队。另一个限制是如果客户端和服务器都位于NAT后，我没有亲自测试过，但是我收到这方面的一份报告，它不能工作，不过我不能断定到底是双重NAT引起的还是其它原因。

　　几乎所有L2TP/IPsec客户端都支持NAT-T。Windows Server 2003也支持NAT-T。像承诺的那样，微软为 Windows XP和Windows 2000 Professional发布了一个IPsec升级包（MS KB Q818043）。这个升级包同样也包含在Windows XP Service Pack 2，可是它制造出来的NAT-T升级包有导致第三方应用程序出现一大堆错误印刷的问题，因此微软要召回它的升级包，2003年8月他们重新发布了一个补丁，这个补丁可能通过Windows Update安装，如果你使用的是 Windows 2000 Professional，你需要先安装Service Pack 3或更高版本，另外，IPsec升级包不会在 Windows Update显示，对于Windows XP，你需要Service Pack 1或更高版本。如果升级包仍没有在 Windows Update中显示，转到Windows Update Catalog并且使用“高档搜索选项”搜索“818043”，如果你想下载 NAT-T升级程序到硬盘并发给更多的客户端，你可以使用Windows Update的Download Basket（见：http: //support.microsoft.com/default.aspx?scid=kb;ZH-CN;323166）或 Software Update Services（见：http: //www.microsoft.com/windowsserversystem/sus/default.mspx）。

 

依据微软员工的信件，也将可以对Windows 2000 Server和ISA Server更新，不过微软宁愿你升级到 Windows 2003。引用微软的话（KB Q818043）：“在 Windows 2000 路由和远程访问中不会增加 NAT-T 服务器端支持。”如果你的服务器运行的Linux，微软的这个决定不会影响到你。

　　除SSH Sentinel之外所有的客户端都会自动检测NAT-T是否启用。SSH Sentinel需要手动在VPN连接的“属性”窗口的“高档”选项中启用“NAT-Traversal”。

　　19.3 L2TP/IPsec客户端支持NAT-T的情况

　　成功测试的（也就是看起来能工作，但是仍认为是试验性的并且不安全的）。

　　• Windows XP Home/Professional（带有IPsec update Q818043或 Service Pack2）。支持Windows需要最新的高于0.6c的NAT-T补丁（检查/var/log/messages里的 Openswan的启动信息来查看你服务器上的NAT-T版本）。这个补丁已经包含在Openswan2.x和Strongswan中，如果你的服务器没有这个补丁，你将在LOG文件中看到“unsupported ID type ID FQDN”错误信息。如果没有http: //www.advancevpn.com/public/super-freeswan-818043NATv3.patch补丁（Openswan 2.x和Strongswan 2.0.2+包含有这个补丁），你将得到“no connection is know”的错误信息（LOG中显示的IP地址和端口号被一个大数代替）。如果你用的是带SP2的Windows XP并且你的Openswan服务器位于NAT后面，你可能需要修改系统注册表。

　　• Windows 2000 Professional（带IPsec update Q818043，这个更新不包含在任何服务包中），参考上边提到的Windows XP。

　　• Windows 2000 Server（当客户端使用）：据一黑客报道，它可以工作，这个版本的Windows在 Windows Update中不会显示IPsec update Q818043，但如果下载Windows 2000 Professional的 IPsec update Q818043补丁并安装。微软大概不支持这样，也就是说它可能会破坏你的“支持合同”。在Widnows Update，到 Windows Update Catalogue并选择“Windows 2000 Professional SP3和你的语言版本，在“高档搜索” 中选择“包含这些字符：818043”，把这个更新加入到“Download Basket”，下载并安装。

　　• Windows Server 2003（当客户端使用）：内建了NAT-T支持，也使用ID_FQDN法子（参考上边提到的Windows XP）。

　　• MSL2TP客户端连接到一个基于Linux的KLIPS服务器。

　　• SafeNet SoftRemote V7.0.5和9.2.1（可能仅用于KLIPS）。

　　• SSH Sentinel V1.4.1 build 98连接到基于KLIPS的服务器。可是有一个断开连接的问题， Sentinel看起来不会发送“Delete SA”数据包，Openswan仍认为这是一个IPsec连接，因此客户端在IPsec连接超时前不能访问Linux机器的在外部接口。

　　• Pocket PC 2003（“Windows Mobile 2003 for Pocket PC”）用证书连接。可以工作，但只有证书比较尺寸比较小时可以。

　　• Pocket PC 2003用“预共享密钥”连接到基于26sec的服务器。

　　不能工作的：

　　• MSL2TP客户端连接到基于26sec的服务器。

　　• SSH Sentinel V1.41 build 98连接到基于26sec的服务器。

　　• SSH Sentinel V1.4 build 177。

　　• SSH Sentinel V1.3或更低。

　　• Pocket PC 2003用“预共享密钥”连接到基于KLIPS的服务器。

　　至今不能工作的：

　　• Mac OS 10.3 Panther。

　　19.4 准备NAT-T

　　启用NAT-T的过程：开始取决于你的发行版的内核是否包含26sec或KLIPS，如果你的内核支持26sec那么内核已经支持NAT-T。如果你的发行版的内核既没有包含26sec也没有包含KLIPS，那么很明显没有为IPsec供给NAT-T支持。即使你的内核支持KLIPS，大概仍不支持NAT-T。发行版根本不带任何IPsec支持或带一个基于内核没有NAT-T补丁的KLIPS大概需要安装一个新的内核。如果你需要安装并且重新启用一个新内核RPM，确认获得了对内核RPM的一般警惕，，也就是不要更新内核，要重新安装新内核来代替当前内核，并且在lilo.conf中为新内核增加一个入口，然后重新运行一下lilo（也可能使用GRUB）。

　　19.4.1 基于内核的26sec使用NAT-T

　　不像KLIPS的NAT-T补丁，26sec执行者支持“预共享密钥”认证的NAT-T。可是你不能用right=a.b.c.d参数指定一个固定IP地址，将将只好指定right=%any并且使用leftid=/rightid=，这意味着“预共享密钥”被所有Road Warriors共享。你也只好在ipsec.secrets中使用%any：

 

123.123.123.123 %any : PSK “thisismytopsecretkey”

　　不能使用l2tpd的listen-addr参数，因为26sec没有使用ipsec0样式的接口。

　　19.4.2 基于内核的KLIPS使用NAT-T

　　KLIPS的NAT-T补丁不支持“预共享密钥”。

　　19.5 关于NAT-T的发行版细节信息

　　略

　　19.6 启用NAT-T的过程

　　当你有一个支持NAT-T的内核和用户态工具，你可以依照下面的过程为L2TP/IPsec客户端启用NAT-T。

　　• 确认L2TP/IPsec客户端支持NAT-T，这常意味着你需要获得最新版或安装更新。

　　• 如果你的NAT设备支持IPsec passthrough，修改它的配置来禁用IPsec passthrough。

　　• 如果你的Openswan服务位于一个NAT设备后面并且你使用的客户端运行的是带SP2的Windows XP，你可能需要修改客户端的注册表。

　　• 在Openswan的配置文件ipsec.conf里添加一行nat_traversal=yes。

　　• 如果用户的工作站位于NAT设备后面，IP地址是私网地址，Openswan在它可以商谈一个连接前需要知道关于这个地址的一点情况，用户NAT设备的公网IP用right=参数指定，有三种法子指定位于NAT设备后面的用户工作站的私网地址：

　　法子1：rightsubnet=192.168.111.40/32

　　法子2：rightsubnetwithin=192.168.111.0/24

　　法子3：rightsubnet=vhost:%no,%priv （推荐）

　　第一种法子Openswan、Strongswan和所有的FreeS/WAN都支持，但明显它不是特别灵活，你的每个 Road Warriors可能使用单独的/32，这种法子不方便。第二种法子是X.509补丁的一个特点，这意味着只有Openswan和 Strongswan支持，FreeS/WAN打过X.509补丁后才能支持。可以接受你指定的一个子网并且客户端使用的私有的地址（/32）位于这个子网。注，这和简单的配置rightsubnetwinthin=0.0.0.0/0相比不是一个好的主意。第三种法子是NAT-T补丁的一个特性。这意味着Openswan和Strong在KLIPS和26sec上都支持，FreeS/WAN需要打过补丁后才支持。首先你在ipsec.conf文件中用 virtual_private=192.168.101.0/24参数指定子网。一些人更愿意使用这个参数来列举所有的RFC1918子网，除这些之外都用在你的Linux服务器上。参考NAT-T文档的示例，客户端的私有地址（/32）在任何这些子网都可以接受。另外，%no允许相同的配置文件用到没有位于NAT设备后面的客户。

　　20 Windows网络（WINS等）

　　在许多方案中，VPN是用来开NetBIOS/SMB/CIFS网络传输（Windows网络）隧道的，不幸的是Windows网络是一个很糟的协议（可以咨询Samba的开发人员）并且它经常导致各种问题，这不是一篇Windows网络指南，因此我不能在那方面帮助你，但是我可以供给一些提示：

　　如果你想通过子网（包含WAN和VPN）浏览“网上邻居”，非常推荐有一台WINS服务器，如果你没有一台可用的 Windows NT/2000/2003或你不想购买它，你可以下载Samba（网址：）并且将它配置成 WINS服务器。记住这个重要的部分：所有计算机必须配置成使用WINS服务，否则一些计算机看其它计算机可能有点麻烦。

　　我也注意到，最好的结果是所有的客户端应该配置成使用相同的工作组名或域名，也就是办公网络。许多客户端都有一个默认的工作组名或域名（比如 WORKGROUP或MSHOME），与实际办公网络的工作组名域名不同，最好将这些改成相同的名字。在ISA Server.org网站（http: //www.tacteam.net/isaserverorg/vpnkitbeta2/vpnclientbrowsing.htm）可以找到类似的技术。

　　微软的客户端有一个“登录到网络”的选项，如果你想登录到域控制器就启用它。

　　Windows XP Home不能加入一个域，可是你应该可以访问域中的资源。

　　自从微软认可L2TP/IPsec协议以来，我还没有真正试过让登录脚本（批处理文件）工作，理论上它应该可以工作。在连接向导的最后一步，计算机询问你这个连接是供“我自己”还是“使用这台计算机的所有人”使用，应该选择“所有人”。你也许喜欢不输入口令，在你下一次登录时点击“选项”按钮，你可以看到出现一个复选框“通过拨号网络登录”，选中这个复选框，用你的Windows用户名和口令登录，你可以看到一个窗口让你选择的连接，其中有你刚才创建的VPN连接，选择它你就可以通过VPN连接登录，并且登录脚本就会启动。