使用kcptun加速搬瓦工VPS

以下以搬瓦工contOS 64位系统为例:
假设你的shadowsock地址为: 23.106.147.91端口为:444

部署服务端

kcptun地址, 按需选择对应32或者64位版本.

mkdir /root/kcptun
cd /root/kcptun
wget https://github.com/xtaci/kcptun/releases/download/v20170221/kcptun-linux-amd64-20170221.tar.gz
tar -zxf kcptun-linux-amd64-20170221.tar.gz

创建 start.sh

vim /root/kcptun/start.sh

写入以下内容:

#!/bin/bash
cd /root/kcptun/
./server_linux_amd64 -c /root/kcptun/server-config.json 2>&1 &
echo "Kcptun started."

创建配置文件server-config.json

vi /root/kcptun/server-config.json

写入以下内容:

{
    "listen": ":29900",
    "target": "127.0.0.1:444",
    "key": "test",
    "crypt": "salsa20",
    "mode": "fast2",
    "mtu": 1350,
    "sndwnd": 1024,
    "rcvwnd": 1024,
    "datashard": 70,
    "parityshard": 30,
    "dscp": 46,
    "nocomp": false,
    "acknodelay": false,
    "nodelay": 0,
    "interval": 40,
    "resend": 0,
    "nc": 0,
    "sockbuf": 4194304,
    "keepalive": 10,
    "log": "/root/kcptun/kcptun.log"
}

“listen”: “:29900” 29900可以随便填写一个自己喜欢的
“target”: “127.0.0.1:444” 127.0.0.1是写死的, 444换成你的ss的端口

创建 stop.sh

vi /root/kcptun/stop.sh

写入以下内容

#!/bin/bash
echo "Stopping Kcptun..."
PID=`ps -ef | grep server_linux_amd64 | grep -v grep | awk '{print $2}'`
if [ "" !=  "$PID" ]; then
  echo "killing $PID"
  kill -9 $PID
fi
echo "Kcptun stoped."

创建 restart.sh

vi /root/kcptun/stop.sh

写入以下内容

#!/bin/bash
cd /root/kcptun/
sh stop.sh
echo "Restarting Kcptun..."
sh start.sh

启动服务端

/root/kcptun/start.sh

停止服务端

/root/kcptun/stop.sh

重启服务端

/root/kcptun/restart.sh

监听日志信息

tail -f /root/kcptun/kcptun.log

按 control + c 退出监听

添加开机启动

chmod +x /etc/rc.d/rc.local;echo "sh /root/kcptun/start.sh" >> /etc/rc.d/rc.local

配置客户端

首先下载 Kcptun 的客户端文件,最好单独放到一个文件夹中
Windows 和 Mac 按需下载.

darwin即代表Mac
版本要和服务端一致. 服务端为v20170221, 这里也要20170221

下面要进行客户端配置,我选择的是GUI的方式,图形界面比较清晰. 你也可以选择用命令配置.

参考这里:

小内存福音,Kcptun Shadowsocks加速方案
在openwrt上部署kcptun给搬瓦工加速
下载Mac GUI工具 或者 Windows GUI工具并安装

设置看图:

  1. 点击1添加一个客户端
  2. 点击2浏览,指定前面下载的Mac版客户端文件.
  3. 处随便填写一个端口.
  4. 处填写你的ss地址
  5. 处填写服务端配置文件server-config.json中的29900
  6. 画圈圈打星星的部分,必须按照server-config.json配置文件中的填写.

Shadowsocks 客户端配置

在客户端中新建服务器:

服务器 IP 填写本机:127.0.0.1 (此处写死,不要改😀)
服务器端口填写:8388 这个8388就是你上一步3处的本地侦听端口
正确填写你的 Shadowsocks 密码,加密方式,协议和混淆方式。

切换到该服务器上,测试是否正确运行。

全部OVER.

06/20/2022 11:21 上午 posted in  VPN

搬瓦工高级教程:使用Python调用KiwiVM面板API

其实这些Python代码都很简单。就是调用一下了上面的API。官方给出的示例是PHP的(世界上最好的语言)。

Read more   12/26/2019 11:37 上午 posted in  VPN

iOS开发之VPN协议(理论)

作者:dengshuai_super
出处:
http://blog.csdn.net/dengshuai_super/article/details/51872474

1 概述

虚拟专用网(英语:Virtual Private Network,简称VPN),是一种常用于连接中、大型企业或团体与团体间的私人网络的通讯方法。虚拟私人网络的讯息透过公用的网络架构(例如:互联网)来传送内联网的网络讯息。它利用已加密的通道协议(Tunneling Protocol)来达到保密、发送端认证、消息准确性等私人消息安全效果。这种技术可以用不安全的网络(例如:互联网)来发送可靠、安全的消息。需要注意的是,加密消息与否是可以控制的。没有加密的虚拟专用网消息依然有被窃取的危险。

以日常生活的例子来比喻,虚拟专用网就像:甲公司某部门的A想寄信去乙公司某部门的B。A已知B的地址及部门,但公司与公司之间的信不能注明部门名称。于是,A请自己的秘书把指定B所属部门的信(A可以选择是否以密码与B通信)放在寄去乙公司地址的大信封中。当乙公司的秘书收到从甲公司寄到乙公司的信件后,该秘书便会把放在该大信封内的指定部门信件以公司内部邮件方式寄给B。同样地,B会以同样的方式回信给A。

在以上例子中,A及B是身处不同公司(内部网路)的计算机(或相关机器),通过一般邮寄方式(公用网络)寄信给对方,再由对方的秘书(例如:支持虚拟专用网的路由器或防火墙)以公司内部信件(内部网络)的方式寄至对方本人。请注意,在虚拟专用网中,因应网络架构,秘书及收信人可以是同一人。许多现在的操作系统,例如Windows及Linux等因其所用传输协议,已有能力不用通过其它网络设备便能达到虚拟专用网连接。--维基百科

iPhone上设置–>通用–>VPN–>添加VPN配置–>类型中,有四种协议:IKEV2,IPSec,L2TP和PPTP。

2.1 PPTP:

PPTP(Point to Point Tunneling Protocol),即点对点隧道协议。该协议是在PPP协议(点对点协议(Point to Point Protocol))的基础上开发的一种新的增强型安全协议,支持多协议虚拟专用网(VPN),可以通过密码验证协议(PAP)、可扩展认证协议(EAP)等方法增强安全性。可以使远程用户通过拨入ISP、通过直接连接Internet或其他网络安全地访问企业网。—百度百科

点对点隧道协议(英语:Point to Point Tunneling Protocol,缩写为PPTP)是实现虚拟专用网(VPN)的方式之一。PPTP使用传输控制协议(TCP)创建控制通道来发送控制命令,以及利用通用路由封装(GRE)通道来封装点对点协议(PPP)数据包以发送数据。这个协议最早由微软等厂商主导开发,但因为它的加密方式容易被破解,微软已经不再建议使用这个协议。—维基百科

PPTP的协议规范本身并未描述加密或身份验证的部分,它依靠点对点协议(PPP)来实现这些安全性功能。因为PPTP协议自带在微软视窗系统家族的各个产品中,在微软点对点协议(PPP)协议堆栈中,提供了各种标准的身份验证与加密机制来支持PPTP 。 在微软视窗系统中,它可以搭配PAP、CHAP、MS-CHAP v1/v2或EAP-TLS来进行身份验证。通常也可以搭配微软点对点加密(MPPE)或IPSec的加密机制来提高安全性。—维基百科

2.2 L2TP

第二层隧道协议(英语:Layer Two Tunneling Protocol,缩写为L2TP)是一种虚拟隧道协议,通常用于虚拟专用网。L2TP协议自身不提供加密与可靠性验证的功能,可以和安全协议搭配使用,从而实现数据的加密传输。经常与L2TP协议搭配的加密协议是IPsec,当这两个协议搭配使用时,通常合称L2TP/IPsec。

L2TP支持包括IP、ATM、帧中继、X.25在内的多种网络。在IP网络中,L2TP协议使用注册端口UDP 1701。[1]因此,在某种意义上,尽管L2TP协议的确是一个数据链路层协议,但在IP网络中,它又的确是一个会话层协议。—维基百科

L2TP是一种工业标准的Internet隧道协议,功能大致和PPTP协议类似,比如同样可以对网络数据流进行加密。不过也有不同之处,比如PPTP要求网络为IP网络,L2TP要求面向数据包的点对点连接;PPTP使用单一隧道,L2TP使用多隧道;L2TP提供包头压缩、隧道验证,而PPTP不支持。—百度百科

在VPN连接中要设置L2TP连接,方法同PPTPVPN设置,同样是在VPN连接属性窗口的“网络”选项卡中,将VPN类型设置为“L2TP IPSec VPN”即可。
第二层隧道协议(L2TP)是用来整合多协议拨号服务至现有的因特网服务提供商点。PPP 定义了多协议跨越第二层点对点链接的一个封装机制。特别地,用户通过使用众多技术之一(如:拨号 POTS、ISDN、ADSL 等)获得第二层连接到网络访问服务器(NAS),然后在此连接上运行 PPP。在这样的配置中,第二层终端点和 PPP 会话终点处于相同的物理设备中(如:NAS)。
L2TP 扩展了 PPP 模型,允许第二层和 PPP 终点处于不同的由包交换网络相互连接的设备来。通过 L2TP,用户在第二层连接到一个访问集中器(如:调制解调器池、ADSL DSLAM 等),然后这个集中器将单独得的 PPP 帧隧道到 NAS。这样,可以把 PPP 包的实际处理过程与 L2 连接的终点分离开来。—百度百科

L2TP协议结构:

L2TP直观示意图:

2.2.1 与PPTP比较:

PPTP和L2TP都使用PPP协议对数据进行封装,然后添加附加包头用于数据在互联网络上的传输。尽
管两个协议非常相似,但是仍存在以下几方面的不同:

1.PPTP要求互联网络为IP网络。L2TP只要求隧道媒介提供面向数据包的点对点的连接。L2TP可以在IP(使用UDP),帧中继永久虚拟电路(PVCs),X.25虚拟电路(VCs)或ATM VCs网络上使用。
2.PPTP只能在两端点间建立单一隧道。L2TP支持在两端点间使用多隧道。使用L2TP,用户可以针对不同的服务质量创建不同的隧道。
3.L2TP可以提供包头压缩。当压缩包头时,系统开销(overhead)占用4个字节,而PPTP协议下要占用6个字节。
4.L2TP可以提供隧道验证,而PPTP则不支持隧道验证。但是当L2TP或PPTP与IPSEC共同使用时,可以由IPSEC提供隧道验证,不需要在第2层协议上验证隧道
5.L2TP访问集中器(L2TP Access Concentrator,LAC)是一种附属在网络上的具有PPP端系统和L2Tpv2协议处理能力的设备,它一般就是一个网络接入服务器软件,在远程客户端完成网络接入服务的功能。
6.L2TP网络服务器(L2TP Network Server,LNS)是用于处理L2TP协议服务器端的软件。

L2TP支持的协议:
IP协议、IPX协议和NetBEUI协议

2.3 IPsec

互联网安全协议(英语:Internet Protocol Security,缩写为IPsec),是一个协议组合,透过对IP协议的分组进行加密和认证来保护IP协议的网络传输协议族(一些相互关联的协议的集合)。

IPsec由两大部分组成:(1)创建安全分组流的密钥交换协议;(2)保护分组流的协议。前者为因特网密钥交换(IKE)协议。后者包括加密分组流的封装安全载荷协议(ESP协议)或认证头协议(AH协议)协议,用于保证数据的机密性、来源可靠性(认证)、无连接的完整性并提供抗重播服务。

IPsec协议工作在OSI模型的第三层,使其在单独使用时适于保护基于TCP或UDP的协议(如安全套接子层(SSL)就不能保护UDP层的通信流)。这就意味着,与传输层或更高层的协议相比,IPsec协议必须处理可靠性和分片的问题,这同时也增加了它的复杂性和处理开销。相对而言,SSL/TLS依靠更高层的TCP(OSI的第四层)来管理可靠性和分片。

2.3.1 IPsec做什么?

IPsec通过使一个系统提供在IP层的安全服务来选择所需的安全协议,确定算法(多个)到用于服务(s)和到位的任何加密密钥,以提供所请求的服务所需的。IPsec的可用于保护一对主机之间的一个或多个的“路径”,一对之间的安全网关,或一个安全网关和一个主机之间。(该术语“安全网关”用于整个的IPsec文件指的是实现IPsec协议的中间系统。对于例如,路由器或实施的IPsec防火墙是一个安全网关。)

一组安全服务的IPsec可以提供包括访问控制,无连接的完整性,数据源认证,拒绝播放包的(部分序列完整性的一种形式),保密性(加密)和有限的流量保密。因为在IP层提供这些服务,它们可通过任何更高层协议,例如,TCP,UDP,可使用的ICMP,BGP等

IPsec DOI也支持IP压缩协商[ SMPT98 ],由部分动机观察当使用加密功能,从而在IPsec的,它较低的协议阻止有效压缩层。----维基百科

IPsec VPN
指采用IPSec协议来实现远程接入的一种VPN技术,IPSec全称为Internet Protocol Security,是由Internet Engineering Task Force (IETF) 定义的安全标准框架,用以提供公用和专用网络的端对端加密和验证服务。

2.3.2 导入协议原因

导入IPSEC协议,原因有2个,一个是原来的TCP/IP体系中间,没有包括基于安全的设计,任何人,只要能够搭入线路,即可分析所有的通讯数据。IPSEC引进了完整的安全机制,包括加密、认证和数据防篡改功能。
另外一个原因,是因为Internet迅速发展,接入越来越方便,很多客户希望能够利用这种上网的带宽,实现异地网络的的互连通。
IPSEC协议通过包封装技术,能够利用Internet可路由的地址,封装内部网络的IP地址,实现异地网络的互通。

2.3.3 包封装协议

设想现实一种通讯方式。假定发信和收信需要有身份证(成年人才有),儿童没有身份证,不能发信收信。有2个儿童,小张和小李,他们的老爸是老张和老李。现在小张和小李要写信互通,怎么办?
一种合理的实现方式是:小张写好一封信,封皮写上 “小张–>小李”, 然后给他爸爸,老张写一个信封,写上“老张–>老李”,把前面的那封信套在里面,发给老李,老李收到信以后,打开,发现这封信是给儿子的,就转给小李了。小李回信也一样,通过他父亲的名义发回给小张。
这种通讯实现方式要依赖以下几个因素:

  • 老李和老张可以收信发信
  • 小张发信,把信件交给老张。
  • 老张收到儿子的来信以后,能够正确的处理(写好另外一个信封),并且重新包装过的信封能够正确送出去。
  • 另外一端,老李收到信拆开以后,能够正确地交给小李。
  • 反过来的流程一样。
    把信封的收发人改成Internet上的IP地址,把信件的内容改成IP的数据,这个模型就是IPsec的包封装模型。小张小李就是内部私网的IP主机,他们的老爸就是VPN网关,本来不能通讯的两个异地的局域网,通过出口处的IP地址封装,就可以实现局域网对局域网的通讯。
    引进这种包封装协议,实在是有点不得已。理想的组网方式,当然是全路由方式。(这里注意理想的组网方式虽然是全路由方式,但VPN的应用也不会因全网而没有用武之地,因为VPN的根本还是为了方便外网访问内网)任意节点之间可达(就像理想的现实通讯方式是任何人之间都可以直接写信互通一样)。
    Internet协议最初设计的时候,IP地址是32位,当时是很足够了,没有人能够预料到将来Internet能够发展到现在的规模(相同的例子发生在电信短消息上面,由于160字节的限制,很大地制约了短消息的发展)。按照2的32次方计算,理论上最多能够容纳40亿个左右IP地址。这些IP地址的利用是很不充分的,另外大约有70%左右的IP地址被美国分配掉了(谁让人家发明并且管理Internet呢?)所以对于中国来说,可供分配的IP地址资源非常有限。
    既然IP地址有限,又要实现异地lan-lan通讯,包封包,自然是最好的方式了。

2.3.4 安全协议

依然参照上述的通讯模型。
假定老张给老李的信件要通过邮政系统传递,而中间途径有很多好事之徒,很想偷看小张和小李(小张小李作生意,通的是买卖信息)通讯,或者破坏其好事。
解决这个问题,就要引进安全措施。安全可以让小李和小张自己来完成,文字用暗号来表示,也可以让他们的老爸代劳完成,写好信,交给老爸,告诉他传出去之前重新用暗号写一下。
IPSEC协议的加密技术和这个方式是一样的,既然能够把数据封装,自然也可以把数据变换,只要到达目的地的时候,能够把数据恢复成原来的样子就可以了。这个加密工作在Internet出口的VPN网关上完成。

数据认证
还是以上述通讯模型为例,仅仅有加密是不够的。
把数据加密,对应这个模型中间,是把信件的文字用暗号表示。
好事之徒无法破解信件,但是可以伪造一封信,或者胡乱把信件改一通。这样,信件到达目的地以后,内容就面目全非了,而且收信一方不知道这封信是被修改过的。
为了防止这种结果,就要引入数据防篡改机制。万一数据被非法修改,能够很快识别出来。这在现实通讯中间可以采用类似这样的算法,计算信件特征(比如统计这封信件的笔划、有多少字),然后把这些特征用暗号标识在信件后面。收信人会检验这个信件特征,由于信件改变,特征也会变。所以,如果修改人没有暗号,改了以后,数据特征值就不匹配了。收信人可以看出来。
身份认证
还是假定小张小李通讯模型。
由于老张和老李不在一个地方,他们互相不能见面,为了保证他们儿子通讯的安全。老张和老李必须要相互确认对方是否可信。这就是身份认证问题。
假定老李老张以前见过面,他们事先就约定了通讯暗号,比如1234567890对应abcdefghij, 那么写个255,对应就是一个bee。
常见的VPN身份认证可以包括预共享密钥,通讯双方实现约定加密解密的密码,直接通讯就可以了。能够通讯就是朋友,不能通讯就是坏人,区分很简单。
其他复杂的身份认证机制包括证书(电子证书比如x509之类的),比较罗里啰嗦,这里就不具体展开了,怕有兄弟看了打瞌睡。如果需要,可以找我要更具体的技术白皮书以及相关的身份认证文档。
如果有身份认证机制,密钥的经常更换就成为了可能。

2.4 IKEv2

因特网密钥交换(英语:Internet Key Exchange,简称IKE或IKEv2)是一种网络协议,归属于IPsec协议族之下,用以创建安全联结(Security association,SA)[1]。它创建在奥克利协议(Oakley protocol)与ISAKMP协议的基础之上[2]。使用X.509安全认证。

V2和V1对比:

在 IKEv1 里,一般都需要 9 个包交换,除了 EZVPN VPN 预共享密钥 6 个包除外。而在 IKEv2 里,最少 4 个包就可以完成 VPN 建立了,因此就产生一对的 IPSEC SA 了。由此可以看出,IKEv2 更精简了。但是事实并不是这样啵,只是最小的情况下而已,但是如果要加其它的认证什么的话,包的数量就会增加的。看环境而定。

2.5 iOS VPN

2.5.1 VPN概述

使用成熟的行业标准虚拟专用网络 (VPN) 协议,可在 iOS 和 OS X 中安全地访问专用公司网络。ios 和 OS X 原生支持 IKEv2、Cisco IPSec、IPSec 上的 L2TP 和 PPTP。如果您所在的组织支持上述某个协议,则无需额外的网络配置或第三方应用即可将 Apple 设备连接至虚拟专用网络。

iOS 和 OS X 支持主流 VPN 提供商的 SSL VPN。与 iOS 和 OS X 支持的其他 VPN 协议一样,SSL VPN 既可在 Apple 设备上手动配置,也可以使用配置描述文件或 MDM 解决方案进行配置。

iOS 和 OS X 也支持 IPv6、代理服务器和隧道分离等技术,可在连接到组织网络时提供灵活的 VPN 体验。iOS 和 OS X 还兼容多种认证方式,包括密码、双因子令牌、数字证书以及用于 OS X 的 Kerberos。对于使用基于证书进行认证的环境,iOS 和 OS X 提供了“请求 VPN 域”功能来简化连接过程,该功能会在需要时发起 VPN 会话来连接到特定域。有关更多信息,请参阅本章的“请求 VPN 域”概览小节。

通过 iOS 7 或更高版本以及 OS X Yosemite 或更高版本,可将每个应用配置为独立于其他应用使用 VPN 连接。这样可以确保公司数据始终通过 VPN 连接传输,而其他数据(例如员工从 App Store 获得的个人应用)则不然。有关更多信息,请参阅本参考的“为 App 单独设置 VPN”小节。

iOS 还提供“始终打开 VPN”,这要求 iOS 设备在连接到任何其他网络服务前连接到经过批准的 VPN。您可以在被监督的设备上为蜂窝移动网络和无线局域网连接配置“始终打开 VPN”。若要实施此功能,您的 VPN 提供商必须支持“始终打开 VPN”。有关信息,请参阅本参考的“始终打开 VPN”概览小节。

2.5.2 支持的协议和认证方式

iOS 和 OS X 支持以下协议和认证方式:

IKEv2:支持 IPv4 和 IPv6 以及:

认证方式:共享密钥、证书、EAP–TLS 和 EAP–MSCHAPv2

Suite B 密码系统:ECDSA 证书、使用 GCM 的 ESP 加密以及针对 Diffie–Hellman 群组的 ECP 群组

附加功能:MOBIKE、IKE 碎片、服务器重定向、分离隧道

IPSec 上的 L2TP:使用 MS–CHAP v2 密码、双因子令牌、证书进行用户认证,使用共享密钥或证书进行机器认证

SSL VPN:使用第三方 VPN 客户端通过密码、双因子令牌和证书进行用户认证

Cisco IPSec:使用密码、双因子令牌进行用户认证,使用共享密钥和证书进行机器认证

PPTP:使用 MS–CHAP v2 密码、证书和双因子令牌进行用户认证

OS X 还可以通过共享密钥或证书(通过“IPSec 上的 L2TP”和“PPTP”)使用 Kerberos 机器认证。

2.5.3 SSL VPN 客户端

SSL VPN 客户端

某些 SSL VPN 提供商创建了专门的应用,用来帮助配置 iOS 设备,以便与他们的解决方案结合使用。要配置设备以使用特定的解决方案,可从 App Store 安装供应商的配套应用,也可以提供包含必要设置的配置描述文件。

iOS 支持以下 SSL VPN 解决方案(可在 App Store 上获取):

Aruba Networks SSL VPN:Aruba Networks Mobility Controller。若要配置,请安装 Aruba Networks VIA 应用。

如需获取联系信息,请访问 Aruba Networks 网站。

Check Point Mobile SSL VPN:包含完全第 3 层 VPN 隧道的 Check Point Security Gateway。安装 Check Point Mobile 应用。

Cisco AnyConnect SSL VPN:运行建议的软件版本 8.2.5 或更高版本的 Cisco Adaptive Security Appliance (ASA)。安装 Cisco AnyConnect 应用。

F5 SSL VPN:F5 BIG–IP Edge Gateway、Access Policy Manager 和 FirePass SSL VPN 解决方案。安装 F5 BIG–IP Edge Client 应用。

有关 F5 技术简介的更多信息,请参阅保护 iPhone 访问公司 Web 应用程序时的安全。

OpenVPN SSL VPN:OpenVPN Access Server、Private Tunnel 和 OpenVPN Community。若要配置,请安装 OpenVPN Connect 应用。

Palo Alto Networks GlobalProtect SSL VPN:Palo Alto Networks 的 GlobalProtect 网关。安装 iOS 版 GlobalProtect 应用。

SonicWALL SSL VPN:10.5.4 或更高版本的 SonicWALL Aventall E–Class Secure Remote Access 设备、5.5 或更高版本的 SonicWALL SRA 设备,以及 SonicWALL Next–Generation Firewall 设备(包括运行 SonicOS 5.8.1.0 或更高版本的 TZ、NSA 和 E–Class NSA)。安装 SonicWALL Mobile Connect 应用。

有关更多信息,请访问 SonicWALL 网站。

AirWatch SSL VPN:有关信息,请访问 AirWatch 网站。

Pulse Secure SSL VPN:包含 Pulse Secure IVE package 7.0 或更高版本的 Pulse Secure SA Series SSL VPN Gateway 6.4 或更高版本。

有关更多信息,请参阅 Pulse Secure 网站上的 Junos Pulse。

Mobile Iron SSL VPN:有关信息,请访问 Mobile Iron 网站。

NetMotion SSL VPN:有关信息,请访问 NetMotion 网站。

2.5.4 VPN 设置指南

2.5.4.1 代理设置

在进行所有这些配置时,可以指定 VPN 代理:

为所有连接配置单个代理:使用手动设置,提供地址、端口和认证(如有必要)。

使用 PAC 或 WPAD 为设备提供自动代理配置文件:使用自动设置。对于 PACS,请指定 PACS 或 JavaScript 文件的 URL。对于 WPAD,iOS 会请求 DHCP 和 DNS 以进行适当的设置。

要使用 VPN 代理配置,VPN 应提供以下方面:

默认解析器和默认路由:VPN 代理可供系统上的所有 Web 请求使用。

分离隧道:只有连接到与 VPN 的 DNS 搜索域相匹配的主机时才使用 VPN 代理。

2.5.4.2 证书

设置和安装证书时:

服务器身份证书的 SubjectAltName 栏必须包含服务器的 DNS 名称或 IP 地址。设备使用此信息来验证证书是否属于服务器。为了获得更高的灵活性,可以使用通配符来指定 SubjectAltName,以达到按名称段匹配的目的,如 vpn.*.mycompany.com。如果未指定 SubjectAltName,则可以将 DNS 名称放在“通用名称”栏中。

为服务器证书签名的证书颁发机构 (CA) 的证书需要安装在设备上。如果该证书不是根证书,请安装信任链的剩余部分以便证书得到信任。如果使用客户端证书,请确保为客户端证书签名的可信 CA 证书已安装在 VPN 服务器上。使用基于证书的认证时,请确保服务器已设置为根据客户端证书中的栏位来识别用户的群组。

【重要事项】证书和 CA 必须有效(例如,可信且未过期)。不支持通过服务器发送整个证书信任链。

2.5.4.3 IKEv2 设置

以下是受支持的 IKEv2 功能及相应的配置描述文件键。

认证方式
IKEv2 支持以下认证方式。使用 AuthenticationMethod 键指定认证级别:

共享密钥:您创建的预置键。

证书:对于证书认证,LocalIdentifier 和 RemoteIdentifier 键常用于识别 iOS IKEv2 客户端和 IKEv2 服务器。

LocalIdentifier 键通常应匹配用户/设备证书的身份(SubjectAltName 或 Subject CommonName),因为服务器实施策略可能要求其匹配以验证客户端的身份。

RemoteIdentifier 键应匹配服务器证书的身份(SubjectAltName 或 Subject CommonName)。

【注】如果 RemoteIdentifier 与服务器证书的身份不匹配,可以使用 ServerCertificateCommonName 键来指定服务器证书的身份。

您还可以使用 ServerCertificateIssuerCommonName 键来指定服务器 CA 的通用名称。指定此键将触发向服务器发送 IKEv2 CERTREQ,这是某些实施策略的要求。

EAP:EAP–MSCHAPv2、EAP–TLS 和 EAP–PEAP

您必须使用 ExtendedAuthEnabled 键来启用 EAP:

指定 EAP–MSCHAPv2 的 AuthName 和 AuthPassword

指定 EAP–TLS 的用户/设备证书。EAP–TLS 需要 ServerCertificateIssuerCommonName 键

指定 EAP–PEAP 的 AuthName 和 AuthPassword 以及用户/设备证书

对于服务器认证,您也可以使用 AuthenticationMethod 键来指定 IKEv2 的认证级别。

IKE 和 Child 提议
适用于 iOS 的 IKEv2 支持一个 IKE 提议和一个 Child 提议。每个提议允许指明一个加密算法、一个完整性算法以及一个 Diffie–Hellman 群组。服务器配置必须允许客户端 IKE 和 Child 提议。

IKE 和 Child 提议还允许指明客户端发起的 IKE 和 Child 密钥更新。此外,服务器发起的密钥更新独立于客户端发起的密钥更新,而且可以在您的服务器上配置。对于“始终打开 VPN”,建议停用服务器发起的密钥更新。

失效对等体检测
适用于 iOS 的 IKEv2 支持失效对等体检测。服务器失效对等体检测独立于客户端失效对等体检测,并且可以在您的服务器上配置。对于“始终打开 VPN”,建议停用服务器失效对等体检测。

分离隧道
适用于 iOS 的 IKEv2 支持分离隧道。默认情况下,服务器通过 IKEv2 流量选择器将分离隧道路由发送到客户端。如果服务器实施策略需要 INTERNAL_IP4_SUBNET 和 INTERNAL_IP6_SUBNET 属性来将路由发送到客户端,您可以使用 UseConfigurationAttributeInternalIPSubnet 键。

【注】IKEv2 不支持从服务器分离 DNS。但是,iOS VPN 有效负载支持允许分离 DNS 的 DNS 字典。

MOBIKE、服务器重定向和 PFS
适用于 iOS 的 IKEv2 支持 MOBIKE、服务器重定向和完全正向保密 (PFS),所有这些都有默认值。要获得这些选项的完整功能,需要服务器支持和配置。

MOBIKE:默认启用。使用 DisableMOBIKE 键来停用它。

服务器重定向:默认启用。使用 DisableRedirect 键来停用它。

PFS(需要 Child Diffie–Hellman 群组):默认停用。使用 EnablePFS 键来启用它。

NAT Keepalive 负载转移
适用于 iOS 的 IKEv2 支持针对“始终打开 VPN”连接的 NAT Keepalive 负载转移,且默认启用。它可以在设备处于睡眠状态时将发送 NAT Keepalive 到硬件的负载转移。NATKeepAliveInterval 键用来控制 Keepalive 负载转移的频率,而 NATKeepAliveOffloadEnable 键用来启用和停用此功能。此功能使设备在睡眠期间仍保持“始终打开 IKEv2”连接活跃。

2.5.4.4 Cisco IPSec 设置

参考本节来配置 Cisco VPN 服务器,以便与 iOS 设备配合使用。虽然 iOS 7.2 或更高版本支持 Cisco ASA 5500 Security Appliance 和 PIX 防火墙,但建议使用 iOS 8.0 或更高版本。iOS 还支持 IOS v12.4(15)T 或更高版本的 Cisco IOS VPN 路由器。VPN 3000 系列集中器不支持 iOS VPN 功能。

认证方式
iOS 支持以下认证方式:

预共享密钥 IPSec 认证,通过 xauth 进行用户认证。

利用客户端和服务器证书进行 IPSec 认证,可选择通过 xauth 进行用户认证。

混合认证,服务器提供证书,客户端提供预共享密钥,进行 IPSec 认证。要求用户认证(通过 xauth 提供),包括以下认证方式:

用户名和密码

RSA SecurID

CRYPTOCard

认证群组
Cisco Unity 协议根据一组常见参数,使用认证群组来分组用户。应创建一个针对 iOS 用户的认证群组。对于预共享密钥认证和混合认证,群组名称必须在设备上配置,并且使用群组的共享密钥(预共享密钥)作为群组密码。

使用证书认证时,没有共享密钥。用户的群组根据证书中的栏位来确定。Cisco 服务器设置可用于将证书中的栏位对应到用户群组。

在 ISAKMP 优先级列表中,RSA–Sig 必须拥有最高优先级。

IPSec 设置和描述
您可以指定这些设置以定义 IPSec 的实施方式:

模式:隧道模式。

IKE 交换模式:“积极模式”(适用于预共享密钥认证和混合认证)或“主模式”(适用于证书认证)。

加密算法:3DES、AES–128 或 AES256。

认证算法:HMAC–MD5 或 HMAC–SHA1。

Diffie–Hellman 群组:预共享密钥认证和混合认证需要群组 2,证书认证需要配合 3DES 和 AES–128 使用群组 2,以及配合 AES–256 使用群组 2 或群组 5。

完全正向保密 (PFS):对于 IKE 阶段 2,如果使用 PFS,则 Diffie–Hellman 群组必须与用于 IKE 阶段 1 的群组相同。

模式配置:必须启用。

失效对等体检测:推荐。

标准 NAT 遍历:受支持并且可以启用(不支持 IPSec over TCP)。

负载均衡:受支持且可以启用。

阶段 1 的密钥更新:当前不受支持。建议将服务器上的密钥更新时间设定为一小时。

ASA 地址掩码:确保所有设备地址池掩码都未设定或都设定为 255.255.255.255。例如:

asa(config-webvpn)# ip local pool vpn_users 10.0.0.1-10.0.0.254 mask 255.255.255.255。

如果使用建议的地址掩码,则可能会忽略 VPN 配置所采用的某些路由。若要避免发生这种情况,请确保路由表包含所有必要的路由,并且验证子网地址可以访问,然后再进行部署。

应用程序版本:客户端软件版本会被发送到服务器,使服务器能够根据设备的软件版本接受或拒绝连接。

横幅:横幅(如果是在服务器上配置的)会显示在设备上,用户必须接受它,否则会断开连接。

分离隧道:支持。

分离 DNS:支持。

默认域:支持。

2.5.5 为 App 单独设置 VPN

在 iOS 和 OS X 中,VPN 连接可以基于每个应用建立,从而可以更精确地控制哪些数据可以通过 VPN 进行传输。而采用设备级 VPN 时,任何客户端进程均有可能通过隧道提供的路由传输流量。这种在应用级别分离通信的功能可将个人数据从组织数据分离。因此,“为 App 单独设置 VPN”可为内部使用的应用提供安全网络,同时保护个人设备活动的隐私。

通过“为 App 单独设置 VPN”,可使每个处于移动设备管理 (MDM) 范围内的应用使用安全隧道与专用网络通信,同时禁止未处于管理范围内的应用使用专用网络。对于处于管理范围内的每个应用,可以配置不同的 VPN 连接以进一步保护数据安全。例如,销售报价应用可使用完全不同于应付帐款应用的数据中心。

要使用“为 App 单独设置 VPN”,应用必须由 MDM 管理并使用标准联网 API。为任意 VPN 连接启用“为 App 单独设置 VPN”后,您需要将该连接与使用该连接的应用进行关联,以确保这些应用的网络流量的安全性。该过程使用配置描述文件中的“为 App 单独设置 VPN”映射有效负载来完成。

在 iOS 9 或更高版本中,“为 App 单独设置 VPN”可以配置为与 iOS 上内建的 VPN 客户端配合使用,支持 IPSec (IKEv1) 和 IKEv2 VPN 客户端。

IKEv2 受 IPSec 客户端支持。有关“为 App 单独设置 VPN”支持的信息,请联系第三方 SSL 或 VPN 供应商。

2.5.6 请求VPN域

2.5.6.1 概述

“请求 VPN 域”可使 Apple 设备在需要时自动建立连接。它要求基于证书的认证,且不论使用何种协议均适用。

“请求 VPN 域”通过配置描述文件的 VPN 有效负载中的 OnDemandRules 键配置。系统分两个阶段应用规则:

网络检测阶段:定义当设备的主要网络连接发生更改时适用的 VPN 要求。

连接计算阶段:定义根据需要向域名发起连接请求时的 VPN 要求。

规则可以用来执行以下操作:

识别因 Apple 设备连接至内部网络而不需要 VPN 的情况

识别因使用未知无线局域网络而需要对所有网络活动采取 VPN 的情况

在针对指定域名的 DNS 请求失败后要求使用 VPN

2.5.6.2 阶段

“请求 VPN 域”通过两个阶段连接到网络。

网络检测阶段
当设备的主要网络接口发生变化时,例如当 Apple 设备切换至不同的无线局域网络或者从无线局域网切换至 iOS 上的蜂窝移动网络或 OS X 上的以太网时,将对“请求 VPN 域”规则进行计算。如果主要接口为虚拟接口(例如,VPN 接口),将忽略“请求 VPN 域”规则。

只有当每个组(字典)中的匹配规则全部匹配时,才会执行关联的操作。如果任意一项规则不匹配,将对列表中的下一个字典进行计算,直至抵达 OnDemandRules 列表末尾。

最后一个字典应定义默认配置,即没有匹配的规则,只有操作。这会找出没有与之前的规则匹配的所有连接。

连接计算阶段
VPN 可基于对某些域的连接请求按需触发,而不是基于网络接口单方面断开或连接。

2.5.6.3 规则和操作

规则帮助定义与“请求 VPN 域”相关联的网络类型。操作帮助定义在匹配规则为真时,所执行的操作。

请求匹配规则
为所有 SSL、IKEv2 和 Cisco IPSec 客户端指定以下一个或多个匹配规则:

InterfaceTypeMatch:可选。“蜂窝移动网络(对于 iOS)或以太网(对于 OS X)”或“无线局域网”的字符串值。如果指定此规则,则当主要接口硬件为指定的类型时,即与此规则匹配。

SSIDMatch:可选。要基于当前网络匹配的 SSID 列表。如果网络不是无线局域网络,或者其 SSID 未显示在列表中,则匹配失败。如果省略此键及其列表,将忽略 SSID。

DNSDomainMatch:可选。搜索域字符串列表。如果为当前主要网络配置的 DNS 搜索域包括在此列表中,将与此属性匹配。支持通配符前缀 ();例如 .example.com 将与 anything.example.com 匹配。

DNSServerAddressMatch:可选。DNS 服务器地址字符串列表。如果当前为主要接口配置的所有 DNS 服务器地址都位于列表中,则将与此属性匹配。支持通配符 ();例如 1.2.3. 将匹配前缀为 1.2.3. 的任何 DNS 服务器。

URLStringProbe:可选。要探查其可访问性的服务器。不支持重定向。URL 应当为可信的 HTTPS 服务器。设备会发送 GET 请求来验证是否可以访问该服务器。

Action
此必选键定义当指定的所有匹配规则都计算为真时的 VPN 行为。Action 键的值包括:

Connect:在下一次尝试建立网络连接时无条件启动 VPN 连接。

Disconnect:断开 VPN 连接,不按需触发任何新的连接。

Ignore:保留任何现有的 VPN 连接,但不按需触发任何新的连接。

EvaluateConnection:对每次连接尝试计算 ActionParameters。使用此值时,需要通过键 ActionParameters(见下文)指定计算规则。

Allow:对于运行 iOS 6 或更低版本的 iOS 设备,请参阅本参考的“向后兼容性”小节。

ActionParameters
这是一组字典,包含了以下描述的键,按照键的显示顺序计算。当 Action 为 EvaluateConnection 时,此为必选键。

Domains:必选。定义此计算规则适用的域的字符串列表。支持通配符前缀,例如 *.example.com。

DomainAction:必选。定义 Domains 的 VPN 行为。DomainAction 键的值包括:

ConnectIfNeeded:如果对 Domains 的 DNS 解析失败,将触发 VPN。例如,DNS 服务器指示其不能解析域名、DNS 响应遭到重定向或者连接失败或超时。

NeverConnect:不对 Domains 触发 VPN。

当 DomainAction 为 ConnectIfNeeded 时,还可以在连接计算字典中指定以下键:

RequiredDNSServers:可选。要用于解析 Domains 的 DNS 服务器的 IP 地址列表。这些服务器不必是设备当前网络配置的一部分。如果无法访问这些 DNS 服务器,则会触发 VPN。对于一致的连接,请配置内部 DNS 服务器或可信的外部 DNS 服务器。

RequiredURLStringProbe:可选。要使用 GET 请求探查的 HTTP 或 HTTPS(首选)URL。如果对此服务器的 DNS 解析成功,则探查也一定会成功。如果探查失败,将触发 VPN。

2.5.6.4 向后兼容性

在 iOS 7 之前,域触发规则从域的列表中进行配置:

OnDemandMatchDomainAlways

OnDemandMatchDomainOnRetry

OnDemandMatchDomainNever

iOS 7 或更高版本仍然支持 OnRetry 和 Never 情形,但更倾向于 EvaluateConnection 操作。

要创建同时适用于 iOS 7 和更早版本的描述文件,除了使用 OnDemandMatchDomain 列表外,还要使用新的 EvaluateConnection 键。

指定 Allow 操作的旧配置描述文件仍适用于 iOS 7 或更高版本,但 OnDemandMatchDomainsAlways 域除外。

2.5.7 始终打开VPN

2.5.6.1 概述

“始终打开 VPN”可让您的组织将所有 IP 流量通过隧道返回到组织,从而让组织完全控制设备流量。默认隧道协议 IKEv2 通过数据加密保护流量传输安全。您的组织现在可以监控和过滤经由设备的流量、保护网络内的数据安全并限制设备访问互联网。

“始终打开 VPN”激活需要设备监督。“始终打开 VPN”描述文件安装到设备上后,“始终打开 VPN”将自动激活,无需任何用户交互,并且会保持激活状态(包括在重新启动过程中),除非卸载“始终打开 VPN”描述文件。

设备上的“始终打开 VPN”处于激活状态时,VPN 隧道的初启和清除与接口 IP 状态有关。当接口可访问 IP 网络后,则会尝试建立隧道。当接口 IP 状态不可用时,隧道会清除。

“始终打开 VPN”也支持每个接口隧道。对于 iOS 设备,每一个活跃的 IP 接口都有一个隧道(蜂窝移动网络接口和无线局域网接口各有一个隧道)。只要 VPN 隧道可用,所有的 IP 流量均会经过隧道。流量包括所有 IP 路由流量和所有 IP 范围流量(来自于第一方应用如 FaceTime 和“信息”的流量)。如果隧道不可用,则会丢弃所有 IP 流量。

设备的所有隧道流量会经过 VPN 服务器。您可以先应用可选过滤和监视处理,然后将流量转移到组织网络或互联网中的目的位置。同样地,可以将设备流量发送到组织的 VPN 服务器,而过滤和监视进程可能会在转移到设备前进行应用。

2.5.6.2 配置

iOS 设备以单用户模式运行。设备身份和用户身份联系在一起。当 iOS 设备建立到 IKEv2 服务器的 IKEv2 隧道时,该服务器会将 iOS 设备识别为单个对等实体。通常,在一台 iOS 设备和一台 VPN 服务器之间会有一个隧道。由于“始终打开 VPN”采用的是每个接口隧道,因此单个 iOS 设备和 IKEv2 服务器之间可同时建立多个隧道。

“始终打开 VPN”配置支持以下两种配置:

仅支持蜂窝移动网络的设备
如果您的组织选择在仅支持蜂窝移动网络的 iOS 设备上部署“始终打开 VPN”(此时无线局域网接口永久性退出或不激活),则会在每台设备和 IKEv2 服务器之间通过蜂窝移动网络 IP 接口建立一个 IKEv2 隧道。这与传统 VPN 模型中类似。iOS 设备充当一个 IKEv2 客户端,拥有一个身份(例如,一个客户端证书或一个用户和密码),可使用 IKEv2 服务器建立 IKEv2 隧道。

蜂窝移动网络设备和无线局域网设备
如果您的组织在同时包含蜂窝移动网络和无线局域网接口的 iOS 设备上部署“始终打开 VPN”,设备会同时建立两个 IKEv2 隧道。使用可通过蜂窝移动网络和无线局域网两者连接的设备有以下两个场景:

蜂窝移动网络隧道和无线局域网隧道在不同的 IKEv2 服务器上终止。

凭借“始终打开 VPN”每个接口隧道配置键,组织可以对设备进行配置,以建立到一台 IKEv2 服务器的蜂窝移动网络隧道和到第二台 IKEv2 服务器的无线局域网隧道。此模型有一个好处,因为隧道在不同的服务器上终止,设备可以对两个隧道使用相同的客户端身份(即客户端证书或用户/密码)。借助不同的服务器,组织也可在每个接口类型流量(蜂窝移动网络流量对无线局域网流量)的隔离和控制方面拥有更大的灵活性。不足之处在于组织必须拥有客户端认证策略相同的两台不同 IKEv2 服务器。

蜂窝移动网络隧道和无线局域网隧道在相同的 IKEv2 服务器上终止。

凭借“始终打开 VPN”每个接口隧道配置,组织还可以对设备进行配置,以建立到同一台 IKEv2 服务器的蜂窝移动网络隧道和无线局域网隧道。

每台设备有一个客户端身份:如果 IKEv2 服务器支持每个客户端有多个隧道,那么组织就可为蜂窝移动网络隧道和无线局域网隧道配置相同的客户端身份(即一个客户端证书或一个用户/密码对)。好处是可以避免为每台设备配置其他的客户端身份,以减轻服务器上的额外配置/资源负担。不足之处在于因为设备不断进出网络,会建立新的隧道,而旧的隧道会逐渐失效。基于服务器的实施策略,服务器可能无法高效、准确地清理失效的隧道。组织必须实施策略来清理服务器上的失效隧道。

每台设备有两个客户端身份:组织可以配置两个客户端身份(即两个客户端证书或两对用户/密码),一个用于蜂窝移动网络隧道,一个用于无线局域网隧道。IKEv2 服务器会看到建立了自己隧道的两个不同客户端。此模型的好处是,由于许多服务器通过其客户端身份区分隧道且仅允许一个客户端有一个隧道,所以它适用于大多数服务器实现策略。不足之处在于,此模型需要请求两次服务器上的客户端身份、配置和资源管理。

2.5.6.3 配置描述文件

“始终打开 VPN”配置描述文件可以通过使用一种 Apple 配置描述文件编辑器(如“描述文件管理器”或 Apple Configurator 2)来手动组成,或使用 MDM 解决方案来创建。有关更多信息,请参阅“描述文件管理器帮助”或“Apple Configurator 2 帮助”,或联系您的首选 MDM 供应商。

用户交互键
若要防止用户停用“始终打开 VPN”功能,可禁止删除“始终打开 VPN”描述文件,方法是将顶层的描述文件键“PayloadRemovalDisallowed”设为“true”。

若要防止用户安装其他配置描述文件来更改“始终打开 VPN”功能的行为,可禁止安装 UI 描述文件。方法是,将“com.apple.applicationaccess”有效负载下方的“allowUIConfigurationProfileInstallation”键设为“false”。组织可使用相同有效负载下方的其他支持键来实施其他限制。

证书有效负载
证书颁发机构 (CA) 是服务器证书的颁发者。

服务器 CA 证书:如果 IKEv2 隧道的认证方式使用证书,则 IKEv2 服务器会将其服务器证书发送到 iOS 设备,以验证服务器身份。为了让 iOS 设备验证服务器证书,需要服务器的 CA 证书,该证书可能已经安装。若未安装,您的组织可以为服务器 CA 证书创建证书有效负载来包括该证书。

客户端 CA 证书:如果 IKEv2 隧道的认证方式使用证书或 EAP–TLS,则 iOS 设备会将其客户端证书发送到 IKEv2 服务器,以验证客户端身份。客户端可能有一个或两个客户端证书,这取决于部署模型。组织需要为客户端证书创建证书有效负载,才能包括客户端证书。为了让 IKEv2 服务器验证客户端身份,IKEv2 服务器必须已安装客户端的 CA 证书。

“始终打开 VPN”IKEv2 证书支持:目前“始终打开 VPN”IKEv2 仅支持 RSA 证书。

2.5.6.4 有效负载

以下适用于“始终打开 VPN”有效负载:

只能在被监督的 iOS 设备上安装。

配置描述文件只能包含一个“始终打开 VPN”有效负载。

一次只能在 iOS 设备上安装一个“始终打开 VPN”配置描述文件。

在 iOS 中自动连接
“始终打开 VPN”提供可选“UIToggleEnabled”键,以便在 VPN 设置中启用自动连接开关。如果此键未在描述文件中指定或被设为 0,“始终打开 VPN”会尝试触发一个或两个 VPN 隧道。如果此键被设为 1,则 VPN“设置”面板中会显示开关,这样用户就可以打开或关闭 VPN。如果用户关闭 VPN 隧道,系统将不会建立隧道,设备会丢弃所有的 IP 流量。这在无法访问 IP 且用户仍想拨打电话时很有用。用户可关闭 VPN 隧道以避免意外触发 VPN 隧道。

每个接口隧道配置列表
“TunnelConfigurations”列表中至少需要一个隧道配置。该配置可应用于蜂窝移动网络接口(针对仅支持蜂窝移动网络的设备),或应用于蜂窝移动网络和无线局域网接口。但是,可以包括两个隧道配置(一个用于蜂窝移动网络接口,一个用于无线局域网接口)。

强制流量例外
“始终打开 VPN”仅支持强制自动登录(自动登录到受支持的强制网络,该网络带有预分配的凭证,例如来自 SIM 的凭证)。

“始终打开 VPN”也支持对强制处理的控制,支持以下内容:

AllowCaptiveWebSheet:允许内建的强制 WebSheet(网络表单)应用中的流量从隧道外通过的键。WebSheet(网络表单)应用是一个浏览器,可在无其他第三方强制应用存在的情况下,处理强制登录。在使用此键时,组织应注意其存在的安全风险,因为 WebSheet(网络表单)是功能浏览器,能够渲染来自于响应的强制服务器的任何内容。允许 WebSheet(网络表单)应用流量会使设备受到不良行为或恶意强制服务器的攻击。

AllowAllCaptiveNetworkPlugins:允许所有满足条件的第三方强制应用的流量从隧道外通过的键。此键优先于 AllowedCaptiveNetworkPlugins 字典。

AllowedCaptiveNetworkPlugins:满足条件的第三方强制应用的捆绑包 ID 列表。允许来自第三方强制应用的流量从隧道外通过。如果还配置了 AllowAllCaptiveNetworkPlugins 键,则此列表不适用。

服务例外
“始终打开 VPN”默认所有 IP 流量通过隧道,包括所有本地流量和蜂窝移动网络运营商服务的流量。因此,默认的“始终打开 VPN”行为不支持任何本地 IP 服务或 IP 运营商服务。“始终打开 VPN”的“服务例外”可让您的组织更改对服务流量的默认处理方法:允许流量从隧道外通过或丢弃流量。当前支持的服务例外为“语音信箱”和“AirPrint”,其允许的操作是允许(允许数据从隧道外通过)或丢弃(不论隧道设置,直接丢弃)。

有关“始终打开 VPN”IKEv2 协议键和属性的更多信息,请参阅 Developer Library(开发者资源库)网站上的《Configuration Profile Key Reference》(配置描述文件键参考)。

2.6 配置VPN三个类:NEVPNProtocol,NEVPNManager,NEVPNConnection

2.6.1 NEVPNProtocol

该NEVPNProtocol类是一个抽象基类,一个子类为每种类型支持的隧道协议。

这个类的实例是线程安全的。

通用隧道协议属性:

VAR serverAddress :String?
隧道服务器的地址

VAR 用户名:String?
隧道协议认证证书的用户名组成部分。

VAR passwordReference :Data?
持久性钥匙扣参阅包含隧道协议认证证书的密码组成一个钥匙串项目。

VAR 的IdentityReference :Data?
持久性钥匙扣参阅包含证书和隧道协议认证证书的私钥组件的钥匙串项。

VAR identityData :Data?
证书和隧道协议认证证书的私钥部件,PKCS12格式编码。

VAR identityDataPassword :String?
密码被用于解密PKCS12数据中所设定的identityData属性。

VAR disconnectOnSleep :BOOL
当设备休眠表示如果VPN的标志应断开。

VAR proxySettings :NEProxySettings?
一个NEProxySettings对象含有待用于HTTP代理设置和HTTPS它们通过VPN路由连接。

2.6.2 NEVPNManager

NEVPNManager用于创建和管理VPN的配置和控制所得VPN隧道连接。

每个应用程序被允许建立一个单一的VPN配置。该NEVPNManager类有一个类方法(NEVPNManager),提供访问单个NEVPNManager实例。这个单一实例对应一个VPN配置,显示在iOS和网络首选项设置应用的VPN设置面板窗格在OS X系统预置的应用程序

由创建的VPN配置NEVPNManager实例被归类为个人VPN配置。在iOS和Mac OS X的,非个人VPN配置优先于个人的VPN配置。如果两个个人VPN配置和一个非个人的VPN配置同时连接,并且两个VPN隧道被配置为充当网络流量需要到达Internet缺省路由,则非个人VPN隧道实际上将默认路由到因特网,只要它是连接。

在使用NEVPNManager类要求com.apple.developer.networking.vpn.api权利。您可以通过启用“个人VPN”能力在Xcode您的应用程序得到这个权利为您的应用程序。

所管理的VPN配置NEVPNManager被存储在由网络扩展的框架管理的网络扩展偏好。VPN配置必须明确装入从网络扩展喜好内存可以使用它之前,并配置所做的任何更改,必须采取系统的影响之前明确地保存到网络扩展的偏好。

这个类的实例是线程安全的。

管理VPN配置:

class func shared()
访问的单个实例NEVPNManager。

func loadFromPreferences(completionHandler: (NSError?) -> Void)
从网络加载扩展喜好VP​​N配置。

func saveToPreferences(completionHandler: ((NSError?) -> Void)? = nil)
保存在网络扩展喜好VP​​N配置。

func removeFromPreferences(completionHandler: ((NSError?) -> Void)? = nil)
从网络扩展喜好删除VPN配置。

设置VPN配置参数:
var onDemandRules: [NEOnDemandRule]?
连接的有序列表按需规则

var isOnDemandEnabled: Bool
用它来打开按需连接功能的布尔值。

var localizedDescription: String?
包含VPN配置的显示名称的字符串。

VAR isEnabled :BOOL
一个布尔值,用来切换VPN配置的启用状态。

VAR protocolConfiguration :NEVPNProtocol?
一个NEVPNProtocol包含VPN隧道协议的配置设置对象。

控制VPN连接:
var connection: NEVPNConnection
一个NEVPNConnection用于控制由VPN配置中指定的VPN隧道对象。
通知:
static let NEVPNConfigurationChange: NSNotification.Name
发布存储在网络扩展偏好的变化VPN配置之后。
实例方法:
FUNC setAuthorization (AuthorizationRef)

2.6.3 NEVPNConnection

概述:NEVPNConnection对象不会直接实例化。相反,每个NEVPNManager对象具有相关联的NEVPNConnection对象作为只读属性。

该NEVPNConnection类提供了启动和编程停止VPN方法。该VPN可以启动和停止的另一种方式是通过VPN点播。见onDemandRules物业NEVPNManager和NEOnDemandRule。
这个类的实例是线程安全的。

控制VPN连接:
FUNC startVPNTunnel ()
开始连接该VPN的过程

func startVPNTunnel(options: [String : NSObject]? = [:])
开始连接该VPN的过程

FUNC stopVPNTunnel ()
开始断开的VPN的过程。

获取有关的VPN连接:

VAR 状态:NEVPNStatus
VPN连接的当前状态

VAR connectedDate :Date?
的日期和时间时,连接状态变更为NEVPNStatusConnected。

常量:
NEVPNStatus
VPN状态码

通知:
static let NEVPNStatusDidChange: NSNotification.Name
发布时的VPN连接的状态发生变化。

实例属性:
var manager: NEVPNManager (Beta)

参考:
https://help.apple.com/deployment/ios/#/ior69b9b7600
https://developer.apple.com/reference/networkextension/
https://zh.wikipedia.org/wiki/Vpn

07/13/2017 09:00 上午 posted in  VPN

VPN的分类方式

VPN的分类方式比较混乱。不同的生产厂家在销售它们的VPN产品时使用了不同的分类方式,它们主要是产品的角度来划分的。不同的ISP在开展VPN业务时也推出了不同的分类方式,他们主要是从业务开展的角度来划分的。而用户往往也有自己的划分方法,主要是根据自己的需求来进行的。下面简单介绍从不同的角度对VPN的分类。
##一、按接入方式划分
这是用户和运营商最关心的VPN划分方式。一般情况下,用户可能是专线上(因特)网的,也可能是拨号上网的,这要根据拥护的具体情况而定。建立在IP网上的VPN也就对应的有两种接入方式:专线接入方式和拨号接入方式。
(1)专线VPN:它是为已经通过专线接入ISP边缘路由器的用户提供的VPN解决方案。这是一种“永远在线”的VPN,可以节省传统的长途专线费用。
(2)拨号VPN(又称VPDN):它是向利用拨号PSTN或ISDN接入ISP的用户提供的VPN业务。这是一种“按需连接”的VPN,可以节省用户的长途电话费用。需要指出的是,因为用户一般是漫游用户,是“按需连接的,因此VPDN通常需要做身份认证(比如利用CHAP和RADIUS)
##二、按协议实现类型划分
这是VPN厂商和ISP最为关心的划分方式。根据分层模型,VPN可以在第二层建立,也可以在第三层建立(甚至有人把在更高层的一些安全协议也归入VPN协议。)
(1)第二层隧道协议:这包括点到点隧道协议(PPTP)、第二层转发协议(L2F),第二层隧道协议(L2TP)、多协议标记交换(MPLS)等。
(2)第三层隧道协议:这包括通用路由封装协议(GRE)、IP安全(IPSec),这是目前最流行的两种三层协议。
第二层和第三层隧道协议的区别主要在于用户数据在网络协议栈的第几层被封装,其中GRE、IPSec和MPLS主要用于实现专线VPN业务,L2TP主要用于实现拨号VPN业务(但也可以用于实现专线VPN业务),当然这些协议之间本身不是冲突的,而是可以结合使用的。
##三、按VPN的发起方式划分
这是客户和IPS最为关心的VPN分类。VPN业务可以是客户独立自主实现的,也可以是由ISP提供的。
(1)发起(也称基于客户的):VPN服务提供的其始点和终止点是面向客户的,其内部技术构成、实施和管理对VPN客户可见。需要客户和隧道服务器(或网关)方安装隧道软件。客户方的软件发起隧道,在公司隧道服务器处终止隧道。此时ISP不需要做支持建立隧道的任何工作。经过对用户身份符(ID)和口令的验证,客户方和隧道服务器极易建立隧道。双方也可以用加密的方式通信。隧道一经建立,用户就会感觉到ISP不在参与通信。
(2)服务器发起(也称客户透明方式或基于网络的):在公司中心部门或ISP处(POP、Point of presence)安装VPN软件,客户无须安装任何特殊软件。主要为ISP提供全面管理的VPN服务,服务提供的起始点和终止点是ISP的POP,其内部构成、实施和管理对VPN客户完全透明。
在上面介绍的隧道协议中,目前MPLS只能用于服务器发起的VPN方式。
##四、按VPN的服务类型划分
根据服务类型,VPN业务大致分为三类:接入VPN(Access VPN)、内联网VPN(Intranet VPN)和外联网VPN(Extranet VPN)。通常情况下内联网VPN是专线VPN。
(1)接入VPN:这是企业员工或企业的小分支机构通过公网远程访问企业内部网络的VPN方式。远程用户一般是一台计算机,而不是网络,因此组成的VPN是一种主机到网络的拓扑模型。需要指出的是接入VPN不同于前面的拨号VPN,这是一个容易发生混淆的地方,因为远程接入可以是专线方式接入的,也可以是拨号方式接入的。
(2)内联网VPN:这是企业的总部与分支机构之间通过公网构筑的虚拟网,这是一种网络到网络以对等的方式连接起来所组成的VPN。
(3)外联网VPN:这是企业在发生收购、兼并或企业间建立战略联盟后,使不同企业间通过公网来构筑的虚拟网。这是一种网络到网络以不对等的方式连接起来所组成的VPN(主要在安全策略上有所不同)。
##五、按承载主体划分
营运VPN业务的企业;既可以自行建设他们的VPN网络,也可以把此业务外包给VPN商。这是客户和ISP最关心的问题。
(1)自建VPN:这是一种客户发起的VPN。企业在驻地安装VPN的客户端软件,在企业网边缘安装VPN网关软件,完全独立于营运商建设自己的VPN网络,运营商不需要做任何对VPN的支持工作。企业自建VPN的好处是它可以直接控制VPN网络,与运营商独立,并且VPN接入设备也是独立的。但缺点是VPN技术非常复杂,这样组建的VPN成本很高,QoS也很难保证。
(2)外包VPN:企业把VPN服务外包给运营商,运营商根据企业的要求规划、设计、实施和运维客户的VPN业务。企业可以因此降低组建和运维VPN的费用,而运营商也可以因此开拓新的IP业务增值服务市场,获得更高的收益,并提高客户的保持力和忠诚度。笔者将目前的外包VPN划分为两种:基于网络的VPN和基于CE(用户边缘设备)的管理型VPN(Managed VPN)。基于网络的VPN通常在运营商网络的呈现点(POP)安装电信级VPN交换设备。基于CE的管理型VPN业务是一种受信的第三方负责设计企业所希望的VPN解决方案,并代表企业进行管理,所使用的安全网关(防火墙、路由器等)位于用户一侧。
##六、按VPN业务层次模型划分
这是根据ISP向用户提供的VPN服务工作在第几层来划分的(注意不是根据隧道协议工作在哪一层划分的)。
(1)拨号VPN业务(VPDN):这是第一种划分方式中的VPDN(事实上是按接入方式划分的,因为很难明确VPDN究竟属于哪一层)。
(2)虚拟租用线(VLL):这是对传统的租用线业务的仿真,用IP网络对租用线进行模拟,而从两端的用户看来这样一条虚拟租用线等价于过去的租用线。
(3)虚拟专用路由网(VPRN)业务:这是对第三层IP路由网络的一种仿真。可以把VPRN理解成第三层VPN技术。
(4)虚拟专用局域网段(VPLS):这是在IP广域网上仿真LAN的技术。可以把VPLS理解成一种第二层VPN技术。

##分类方式 类型名称 说明/举例
接入方式 拨号VPN(VPDN) 为利用拨号公用交换电话网(PSTN)或综合业务数字网(ISDN)接入ISP的用户提供的VPN业务
专线VPN 为已经通过专线接入ISP边缘路由器的用户提供的VPN业务
协议层 应用层 S/MIME、Kerberose、IPSec(ISAKMP)
传输层 SSL/TLS、SOCKS
IP层 用户数据在协议栈的第三层被封装,如IPSec(AH和ESP)
第二层隧道 用户数据在协议栈的第二层被封装,如L2TP、PPTP、L2F和MPLS
隧道的
发起方式 客户发起 基于客户的VPN。隧道的起始点和终止点是面向客户的,其内部技术构成、实施和管理都由VPN客户负责
服务器(网络)发起 ISP提供并管理的VPN服务,服务提供的起始点和终止点是ISP的呈现点(POP),其内部构成、实施和管理都由ISP负责
业务类型 接入VPN 企业员工或企业的小分支机构通过公网远程拨号等方式构筑的VPN
内联网VPN 企业总部与分支机构LAN之间通过公网构筑的VPN
外联网VPN 企业发生收购、兼并或企业间建立战略联盟后,不同企业间通过公网构筑的VPN
承建和
运维主体 企业自建 基于客户的VPN。隧道的起始点和终止点是面向客户的,其内部技术构成、实施和管理都由VPN客户负责
外包 基于网络 ISP提供并管理的VPN服务,服务提供的起始点和终止点是ISP的呈现点(POP),其内部构成、实施和管理都由ISP负责
托管方式 VPN设备位于用户一侧。运营商负责安装、配置和监视、维护设备的运转情况
服务在网络中的层次 VPDN 为利用拨号公用交换电话网(PSTN)或综合业务数字网(ISDN)接入ISP的用户提供的VPN业务
VLL 对传统的租用线业务的仿真
VRPN 是对第三层IP路由网络的一种仿真
VPLS 是在IP广域网上仿真LAN的技术

07/13/2017 08:45 上午 posted in  VPN

ShadowSocks的翻墙原理

所周知,天朝局域网通过 GFW 隔离了我们与外界的交流,当然,这个隔离并非完全隔离,而是选择性的,天朝不希望你上的网站就直接阻断。每一个网络请求都是有数据特征的,不同的协议具备不同的特征,比如 HTTP/HTTPS 这类请求,会很明确地告诉 GFW 它们要请求哪个域名;再比如 TCP 请求,它只会告诉 GFW 它们要请求哪个 IP。

GFW 封锁包含多种方式,最容易操作也是最基础的方式便是域名黑白名单,在黑名单内的域名不让通过,IP 黑白名单也是这个道理。如果你有一台国外服务器不在 GFW 的黑名单内,天朝局域网的机器就可以跟这一台机器通讯。那么一个翻墙的方案就出来了:境内设备与境外机器通讯,境内想看什么网页,就告诉境外的机器,让境外机器代理抓取,然后送回来,我们要做的就是保证境内设备与境外设备通讯时不被 GFW 怀疑和窃听。

ssh tunnel 是比较具有代表性的防窃听通讯隧道,通过 ssh 与境外服务器建立一条加密通道,此时的通讯 GFW 会将其视作普通的连接。由于大家都这么玩,GFW 着急了,于是它通过各种流量特征分析,渐渐的能够识别哪些连接是 ssh 隧道,并尝试性的对隧道做干扰,结果还是玩不过 GFW,众多隧道纷纷不通。

Shadowsocks 及其部署
如果你理解了上面那道隐形的墙的原理,那 Shadowsocks 的原理就可以用一句简单的描述来理解了:它发出的 TCP 包,没有明显包特征,GFW 分析不出来,当作普通流量放过了。

具体而言,Shadowsocks 将原来 ssh 创建的 Socks5 协议拆开成 Server 端和 Client 端,两个端分别安装在境外服务器和境内设备上。

Clowwindy分享并开源了他提出的Shadowsocks翻墙解决方案。它的翻墙原理是什么?有什么优点和缺点?

简单理解的话,Shadowsocks是将以前通过SSH创建的Socks5协议拆开成Server端和client端,下面这个原理图能简单介绍其翻墙原理,基本上和利用SSH tunnel大致类似:

  1. PC客户端(即你的电脑)发出请求基于Socks5协议跟SS-Local端进行通讯,由于这个SS-Local一般是本机或路由器等局域网的其他机器,不经过GFW,所以解决GFW通过特征分析进行干扰的问题。
  2. SS-Local和SS-Server两端通过多种可选的加密方法进行通讯,经过GFW的时候因为是常规的TCP包,没有明显特征码GFW也无法对通讯数据进行解密,因此通讯放行。
  3. SS-Server将收到的加密数据进行解密,还原初始请求,再发送到用户需要访问的服务网站,获取响应原路再返回SS-04,返回途中依然使用了加密,使得流量是普通TCP包,并成功穿过GFW防火墙。

因此,Shadowsocks的优点在于它通过流量混淆隐秘解决了GFW通过分析流量特征从而干扰的问题,这是它优于SSH和VPN翻墙的地方(但VPN更注重加密安全性)。缺点也依然明显,需要一点点技术和资源(墙外VPS服务器)来搭建Shadowsocks服务,好在已经有人搭建相应的服务出售翻墙服务了。

07/12/2017 13:59 下午 posted in  VPN