|
4层正向代理是透传上层HTTPS流量，不需要HTTP CONNECT来建立隧道，也就是说不需要客户端设置HTTP(S)代理。如果我们在客户端手动设置HTTP(s)代理是否能访问成功呢? 我们可以用curl -x来设置代理为这个正向服务器访问测试，看看结果：
- # curl https://www.baidu.com -svo /dev/null -x 39.105.196.164:443
- * About to connect() to proxy 39.105.196.164 port 443 (#0)
- * Trying 39.105.196.164...
- * Connected to 39.105.196.164 (39.105.196.164) port 443 (#0)
- * Establish HTTP proxy tunnel to www.baidu.com:443
- > CONNECT www.baidu.com:443 HTTP/1.1
- > Host: www.baidu.com:443
- > User-Agent: curl/7.29.0
- > Proxy-Connection: Keep-Alive
- >
- * Proxy CONNECT aborted
- * Connection #0 to host 39.105.196.164 left intact
可以看到客户端试图于正向NGINX前建立HTTP CONNECT tunnel，但是由于NGINX是透传，所以把CONNECT请求直接转发给了目的服务器。目的服务器不接受CONNECT方法，所以最终出现"Proxy CONNECT aborted"，导致访问不成功。
2) 客户端没有带SNI导致访问不成功
上文提到用NGINX stream做正向代理的关键因素之一是利用ngx_stream_ssl_preread_module提取出Client Hello中的SNI字段。如果客户端客户端不携带SNI字段，会造成代理服务器无法获知目的域名的情况，导致访问不成功。
在透明代理模式下(用手动绑定hosts的方式模拟)，我们可以在客户端用openssl来模拟：
- # openssl s_client -connect www.baidu.com:443 -msg
- CONNECTED(00000003)
- >>> TLS 1.2 [length 0005]
- 16 03 01 01 1c
- >>> TLS 1.2 Handshake [length 011c], ClientHello
- 01 00 01 18 03 03 6b 2e 75 86 52 6c d5 a5 80 d7
- a4 61 65 6d 72 53 33 fb 33 f0 43 a3 aa c2 4a e3
- 47 84 9f 69 8b d6 00 00 ac c0 30 c0 2c c0 28 c0
- 24 c0 14 c0 0a 00 a5 00 a3 00 a1 00 9f 00 6b 00
- 6a 00 69 00 68 00 39 00 38 00 37 00 36 00 88 00
- 87 00 86 00 85 c0 32 c0 2e c0 2a c0 26 c0 0f c0
- 05 00 9d 00 3d 00 35 00 84 c0 2f c0 2b c0 27 c0
- 23 c0 13 c0 09 00 a4 00 a2 00 a0 00 9e 00 67 00
- 40 00 3f 00 3e 00 33 00 32 00 31 00 30 00 9a 00
- 99 00 98 00 97 00 45 00 44 00 43 00 42 c0 31 c0
- 2d c0 29 c0 25 c0 0e c0 04 00 9c 00 3c 00 2f 00
- 96 00 41 c0 12 c0 08 00 16 00 13 00 10 00 0d c0
- 0d c0 03 00 0a 00 07 c0 11 c0 07 c0 0c c0 02 00
- 05 00 04 00 ff 01 00 00 43 00 0b 00 04 03 00 01
- 02 00 0a 00 0a 00 08 00 17 00 19 00 18 00 16 00
- 23 00 00 00 0d 00 20 00 1e 06 01 06 02 06 03 05
- 01 05 02 05 03 04 01 04 02 04 03 03 01 03 02 03
- 03 02 01 02 02 02 03 00 0f 00 01 01
- 140285606590352:error:140790E5:SSL routines:ssl23_write:ssl handshake failure:s23_lib.c:177:
- ---
- no peer certificate available
- ---
- No client certificate CA names sent
- ---
- SSL handshake has read 0 bytes and written 289 bytes
- ...
openssl s_client默认不带SNI，可以看到上面的请求在TLS/SSL握手阶段，发出Client Hello后就结束了。因为代理服务器不知道要把Client Hello往哪个目的域名转发。 （编辑：牡丹江站长网）
【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!
|
