vpn：代理协议原理介绍

站内链接:

网页代理

介绍

默认情况下, 所有浏览器的代理都是基于系统的代理配置, postman 需要进行配置为走系统代理.
关于网页代理, 这里有几点注意事项:

网页代理的最终生效都在系统代理中的网页代理中呈现
网页代理的使用者, 可以是浏览器, 也可以是其他所有的 http/https 流量
网页代理的配置者, 可以是代理服务器, 也可以是抓包应用, 例如 charles, Fiddler 等都是通过更改该设置来截取流量

即一旦配置了网页代理, 实际上当前系统所有的 http/https 流量都会经过该配置所涉及的代理, 除非在进行此类判断
之前, 流量就已经被截胡, 由其他出口偷税漏税了, 例如终端上配置 http_proxy/https_proxy, 此时流量就
不会经过系统代理-->网页代理所涉及的代理服务器.

网页代理流程:

关于网页代理配置, 如何使用浏览器实现科学上网, 请见

firefox

foxyproxy 配置, 首先安装浏览器的扩展应用, 这里指 foxyproxy

方式 1: 设置代理服务器(全局)

新建代理服务器(127.0.0.1, 1080, socks5)
工作模式: 为全部 URLS 使用代理

此时就可以进行全局的翻墙浏览

方式 2: 设置代理服务器(科学上网-订阅模式)

gfwlist 网址: https://raw.githubusercontent.com/gfwlist/gfwlist/master/gfwlist.txt
代理服务器: 设置代理服务器, 见全局代理配置
更新频率: 720
format: autoproxy
Obfuscation: Base64, 等待订阅完成，请确保 gfwlist 无误
更改工作模式: 使用基于其预定义模板的代理服务器

chrome

方式 1: 浏览器全局代理配置: 设置->高级->代理服务器配置

方式 2: 使用SwitchyOmega进行自动代理配置工作

安装 SwitchyOmega
下载 gfwlist.bak 文件
在 SwitchyOmega 中导入 gfwlist.bak 文件，自动的设置各种情景模式
开启 shadowsocks 代理服务器
启动自动转换(需要相应的规则处理)

Socks 代理

shadowsocks

socks 代理的主要在于穿透, 关于 SOCKS 的原理, 在前面章节已经阐述, 目前大部分科学上网都是通过
shadowsocks, 结合 PAC 与 SOCKS5 来进行流量分流操作. 关于shadowsocks的工作原理见下图:

shadowsocks-theory

关于 VPS 的配置见vps 配置

iphone: 下载 Wingy 等代理终端, 配置 VPN 线路, 可购买或者自行配置
mac: 下载 Shadowsocks-NG, 配置线路, 更新 PAC 即可实现全局代理/自动代理上网
ubuntu: 安装 shadowsocks 并启动客户端服务即可, 实际上这个也适用于 mac

关于 ubuntu 配置:

# 安装
sudo pip install shadowsocks
# 启动sslocal, 连接远程代理服务器
sslocal -s server-name -p server-port -b 127.0.0.1 -l 1080 -k server-passwd -m aes-256-cfb

配置完上述的相关信息之后就可以使用浏览器, 基于 socks5 进行科学上网了.

自动代理配置

priority

对于各个代理的优先级, 目前试验过的仅仅是pac和网页代理, 由此可以推到出(猜的), 整个代理的优先级根据系统代理
中从上至下的顺序(_), 分别是(MAC): WAPD->PAC->HTTP/HTTPS->SOCKS5->RTSP->Goher. 所以一旦配置了 PAC, 则即使配置 HTTP/HTTPS,
则流量一般都是经过 PAC 来进行分发的.

这也就是为何在 MAC 上同时配置 Shadowsocks 的PAC和 charles 的系统代理之后, 包流量没有经过 charles.
在设置 Shadowsocks 的全局代理-socks5之后, 再配置External Proxy就能让流量经过
charles(实际上 Socks5 和 http 代理不能同时存在).

socks5

PAC 会根据配置文件(一个 javascript 脚本)来进行分流操作, 对于内部流量, 直接使用正常的访问, 对于外网请求, 则最终还是
根据 SOCKS5 来进行代理访问.

整个 Shadowsocks 都是基于 SOCKS5 为基础, 以便进行穿透访问, 关于 SOCKS5 的功能见上面章节介绍.

正向和反向代理

正向代理

在开始介绍前, 让我们带着如下疑问:

何为正向?
何为反向?
两者的功能? 两者的使用场景?

Forward Proxy是一个客户端和服务端之间的中间代理服务器, 此时客户端实际上知晓整个网络拓扑:

我知道中间代理服务器 IP/PORT
我知道我要访问的资源所在的目标服务器
我知道我的流量会通过中间正向代理服务器和目标服务器进行交互

在正向代理过程中, Client是被代理角色, 和代理一起配合, 以达到消费目标服务器资源的目的. 一般而言, 正向代理和 Client 都是同属于一个内部网络, 注意, 这里仅仅是逻辑上的内部网络. 比如, 有可能某一个笨蛋配置了一个正向代理离自己非常远, 比如你配置一个欧洲的 HTTP 代理, 然后目标服务器是美国.

正向代理网络拓扑图如下: 反向代理

正向代理的使用场景:

用于为防火墙内部的使用者提供访问外部网络的途径
对于公司而言, 使用代理的缓存特性, 减少网络的使用率, 这个一般很少有
匿名代理功能, 让 Client 以匿名方式访问目标服务器, 但是你得确保有足够多的正向代理服务器

正向代理在 nginx 服务器上的配置如下, 一般很少使用到:

server {
    resolver 192.168.1.1; #指定DNS服务器IP地址
    listen 8080;
    location / {
        proxy_pass https://$http_host$request_uri; #设定代理服务器的协议和地址
    }
}

反向代理

reverse proxy也是一种中间代理服务器, 不过对client而言是透明的, 即客户端不知道这是一个代理, 而将其当成目标服务器.

我被告知网址 A/B/C 在 IP1 上面
我访问 IP1 获取内容

整个过程对普通用户而言就是这么简单透明, 此时reverse proxy作为一个web服务角色, 对外提供服务. 相比正向代理, 客户端:

无需指定代理服务器
无需配置代理服务器 IP 地址

一般而言, 反向代理和webserver同处于一个局域网里, 以便实现负载均衡等功能, 方向代理的网络拓扑如下:

正向代理

另外, 注意一点, 反向代理服务器并非一定和目标服务器靠的很近, 考虑如下场景: 我提供一个反向代理服务器, 然后告知我的客户端目标网站都在代理服务器所在的 IP 上, 此时所有的流量仍旧走代理, 但是实际上反向代理到目标网站有很长的距离, 当然, 这种使用场景实际上很少会发生.

反向代理的使用场景:

对访问者透明, 以保护和隐藏原始的资源服务器
负载均衡, 确保服务的稳定
缓存静态内容, 在这里做缓存的意义就非常大, 大规模的访问会因为缓存的原因带来性能非常大的提升
处于安全保护等原因

反向代理的 nginx 配置如下:

server {
    listen       80;
    location /demo {
        proxy_pass https://127.0.0.1:8081;
    }
    location /demo1 {
        proxy_pass https://127.0.0.1:8082;
    }
}

其中对外统一使用 80端口, 但是对于不同的服务, 会进行引流, 访问真正的资源服务器.

透明代理

基于正向代理的网络拓扑结构, 但是实际上代理仅仅网络管理员知晓, 从而实现包的改动, 包的过滤, 比如 charles 的抓包功能.

trojan

需求

由于防护墙的封禁技术加强, 目前对于 SSR 流量已经达到了非常快的封禁效果, 比如我这个平常只用 google
进行资料查询的 vps 服务器情况.

1
2
3

1. 香港腾讯云服务器: 已经全端口封禁, 连ssh都连接不上了, 更改了ssh端口也不行..
2. 美国SSR 服务器, 以前的 IP 已经完全不能用了, 花了 10 美刀换了一个 IP, 更改了端口密码之后,
    使用大概 1 个小时候后, 发现刚刚使用的端口已经无法使用了.....

ip 和端口可用情况见ip 端口扫描.

被动检测: 防火墙在早期仅仅只是对出境流量进行截获和审查, ss 加密设计随机比特流可用绕过防火墙
主动检测: 防火墙发现一个可疑的无法识别的连接时(13 次+), 主动连接服务端口, 重放之前捕获到的流量,
Shadowsocks 服务器检测到不正常的连接，将连接断开, 从而被防火墙检测.

trojan 提出的目的就是为了解决此类情况.

原理

trojan 不同于 ss, 使用自己的加密协议隐藏自身, 而是基于TLS协议进行封装, 这样就确保流量和正常
流量是一样的, 这样就导致防火墙只能通过无差别封锁和大规模的中间人攻击才能达到效果. 使用 tls
的优点:

保密性(GFW 无法得知传输的内容)
完整性(一旦 GFW 试图篡改传输的密文，通讯双方都会发现)
不可抵赖(GFW 无法伪造身份冒充服务端或者客户端)
前向安全(即使密钥泄露，GFW 也无法解密先前的加密流量)

trojan 对于主动检测和被动检测是如何反应的?

被动检测: trojan 流量几乎和 https 保持一致, tls 握手后流量为密文, 无法解析
主动检测: 一旦防火墙主动发出探测包, 则 trojan 不会像 ss 那样主动断开(这个重要), 而是将流量
导向用户配置好的有效域名以及权威CA签名的HTTPS证书的网址, 从而防火墙就无法区别.