向死而生,方得重生。

Search

2019-10-26

使用 Nginx 反向代理开启HTTPS


有些程序可能会提供Web形式,需要登录但是原生程序还不提供HTTPS配置接口,这种情况下,使用 Nginx 反向代理进行控制是一个不错的选择。

假定网页程序为 http://127.0.0.1:8080(如果Web程序默认监听0.0.0.0且不提供任何设置接口,后期可以通过防火墙屏蔽8080的外网访问,仅允许本机访问即可)

实现目的:通过 https://test.com 直接访问(假设test.com解析到127.0.0.1)

1、准备 crt 和 key 文件上传至服务器。

这里示例给的是/usr/local/nginx/conf/ssl/certification.crt/usr/local/nginx/conf/ssl/certification.key

2、在vhost中建立一个新的配置文件,按照下面的填写。

(这里假定建立了vhost文件夹并导入其内的所有conf文件配置信息;如果你没有这样做,可以追加在/usr/local/nginx/conf/nginx.conf的文件尾)


3、重启Nginx服务加载即可。

可根据个人习惯进行重启,例:systemctl restart nginx

EOF.


2019-10-25

HSTS http 强制重定向到 https 的问题


问题:

Chrome会强制将http重定向到https,就算是在浏览器手动输入http://xxx也不可以。


解决方案:

1. 在chrome的地址栏输入chrome://net-internals/#hsts,在Query HSTS/PKP domain中查询指定的域是否有HSTS记录,如果存在,在Delete domain security policies中删除该域即可。

2. 如果完成第一步后仍不能访问,可以尝试清除浏览器缓存。


原因:

要解释上述情况产生的原因,则必须要先了解浏览器的HSTS功能。

HSTS强制要求浏览器与服务器进行HTTPS通信,例如,如果example.com站点开启了HSTS,则不管是在浏览器输入example.com或是http://example.com,亦或者在网页上点击http://example.com链接,浏览器都会自动将http替换为https,然后再发送请求。这样很大程度上避免了SSL剥离攻击的发生。

SSL剥离攻击其实是中间人攻击的一种,它基于用户很少直接在浏览器中输入https或者是用户经常通过重定向从http跳转到https,这样攻击者可以在用户访问http页面时替换所有的https开头的链接来阻止浏览器和服务器建立HTTPS连接。

之所以说是一定程度上避免,而不是完全避免,是因为HSTS也存在一定的漏洞,这个漏洞就是HSTS的开启方式。浏览器如果探测到一个https请求的response头部包含Strict-Transport-Security,则会为该站点开启HSTS功能。这意味每个站点的第一次请求仍有被攻击可能,所以大多数浏览器都会在本地维护一个HSTS域名列表,该列表默认会包含一些经常访问的域名,并且,在访问https站点时,也会将该站点添加到HSTS列表中。所以说,当用https访问过一个站点后,即使用http再次访问该站点,浏览器也会用https,而解决方法就是将该域名从HSTS列表中删除。

原文地址:https://www.cnblogs.com/philipding/p/7898090.html


补充:服务器端配置

如果这个不需要开启HSTS,只需要 Nginx 的 conf 配置文件中,注释掉add_header Strict-Transport-Security一行即可,下面是一个示例。同样的,去掉注释则开启HSTS。

i.e. add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;


2019-10-17

Raspbian 开启 IPv6


最近中国联通开始陆陆续续下发 IPv6 业务了,可惜树莓派的 Raspbian 网络模块并不是完全采用 Debian 的网络模块,所以有些操作还不太一样。网络上的各种教程乱七八糟,并不好用,自己摸索了一下探索过程,经验总结如下:

1、在 /etc/modprobe.d/ipv6.conf 中将 IPv6 业务打开。

alias net-pf-10 off注释掉,同时将alias ipv6 off改为on

2、在 /etc/sysctl.conf 中开启IPv6

将disable IPv6 标签下的三项全部由1改为0

# disable IPv6
net.ipv6.conf.all.disable_ipv6 = 0
net.ipv6.conf.default.disable_ipv6 = 0
net.ipv6.conf.lo.disable_ipv6 = 0

3、重启网络服务即可。

service networking restart

Enjoy~

2019-10-13

四层、七层负载均衡的区别


四层、七层负载均衡简介


所谓四层就是基于 IP + 端口的负载均衡;(运行在第四层:运输层)
七层就是基于 URL 等应用层信息的负载均衡;(运行在第七层:应用层)

同理,还有基于 MAC 地址的二层负载均衡和基于 IP 地址的三层负载均衡。

换句换说,

  • 二层负载均衡会通过一个虚拟 MAC 地址接收请求,然后再分配到真实的 MAC 地址;
  • 三层负载均衡会通过一个虚拟 IP 地址接收请求,然后再分配到真实的 IP 地址;
  • 四层通过虚拟 IP + 端口接收请求,然后再分配到真实的服务器;
  • 七层通过虚拟的 URL 或主机名接收请求,然后再分配到真实的服务器。


所谓的四到七层负载均衡,就是在对后台的服务器进行负载均衡时,依据四层的信息或七层的信息来决定怎么样转发流量。

比如四层的负载均衡,就是通过发布三层的 IP 地址(VIP),然后加四层的端口号,来决定哪些流量需要做负载均衡,对需要处理的流量进行 NAT 处理,转发至后台服务器,并记录下这个 TCP 或者 UDP 的流量是由哪台服务器处理的,后续这个连接的所有流量都同样转发到同一台服务器处理。

七层的负载均衡,就是在四层的基础上(没有四层是绝对不可能有七层的),再考虑应用层的特征, 比如同一个 Web 服务器的负载均衡,除了根据 VIP 加 80 端口辨别是否需要处理的流量, 还可根据七层的 URL、浏览器类别、语言来决定是否要进行负载均衡。

举个例子,如果你的 Web 服务器分成两组,一组是中文语言的,一组是英文语言的,那么七层负载均衡就可以当用户来访问你的域名时,自动辨别用户语言,然后选择对应的语言服务器组进行负载均衡处理。

负载均衡器通常称为四层交换机或七层交换机。


  1. 四层交换机主要分析 IP 层及 TCP/UDP 层,实现四层流量负载均衡。
  2. 七层交换机除了支持四层负载均衡以外,还有分析应用层的信息,如 HTTP 协议 URI 或 Cookie 信息。

负载均衡分为 L4 Switch(四层交换),即在 OSI 第 4 层工作,就是 TCP 层啦。
此种 Load Balancer 不理解应用协议(如 HTTP/FTP/MySQL 等等)。例子:LVS,F5。

另一种叫做 L7 Switch(七层交换),OSI 的最高层,应用层。
此时,该 Load Balancer 能理解应用协议。例子: HAProxy,MySQL Proxy。

注意:上面的很多 Load Balancer 既可以做四层交换,也可以做七层交换。

当前可以看到对于 F5, Array 等硬件负载均衡设备本身也是支持 7 层负载均衡的,同时在 4 层负载均衡的时候我们还可以设置是否进行会话保持等高级特性。

明白 4 层负载均衡本质是转发,而 7 层负载本质是内容交换和代理,具体说明如下:

区别


1. 技术原理上的区别


所谓四层负载均衡,也就是主要通过报文中的目标地址和端口,再加上负载均衡设备设置的服务器选择方式,决定最终选择的内部服务器。

以常见的 TCP 为例,负载均衡设备在接收到第一个来自客户端的 SYN 请求时,即通过上述方式选择一个最佳的服务器, 并对报文中的目标 IP 地址进行修改(改为后端服务器 IP),直接转发给该服务器。

TCP 的连接建立,即三次握手是客户端和服务器直接建立的,负载均衡设备只是起到一个类似路由器的转发动作。

在某些部署情况下,为保证服务器回包可以正确返回给负载均衡设备,在转发报文的同时可能还会对报文原来的源地址进行修改。



所谓七层负载均衡,也称为“内容交换”,也就是主要通过报文中的真正有意义的应用层内容,再加上负载均衡设备设置的服务器选择方式,决定最终选择的内部服务器。 

以常见的 TCP 为例,负载均衡设备如果要根据真正的应用层内容再选择服务器,只能先代理最终的服务器和客户端建立连接(TCP 三次握手)后,才可能接收到客户端发送的真正应用层内容的报文, 然后再根据该报文中的特定字段,再加上负载均衡设备设置的服务器选择方式,决定最终选择的内部服务器。

负载均衡设备在这种情况下,更类似于一个代理服务器。负载均衡和前端的客户端以及后端的服务器会分别建立 TCP 连接。

所以从这个技术原理上来看,七层负载均衡明显地对负载均衡设备的要求更高,处理七层的能力也必然会低于四层模式的部署方式。

2. 应用场景的需求


七层应用负载均衡的好处,是使得整个网络更“智能化”, 例如访问一个网站的用户流量,可以通过七层的方式,

将对图片类的请求转发到特定的图片服务器并可以使用缓存技术;将对文字类的请求可以转发到特定的文字服务器并可以使用压缩技术。

当然这只是七层应用的一个小案例,从技术原理上,这种方式可以对客户端的请求和服务器的响应进行任意意义上的修改,极大的提升了应用系统在网络层的灵活性。 很多在后台(例如 Nginx 或者 Apache )上部署的功能可以前移到负载均衡设备上,例如客户请求中的 Header 重写,服务器响应中的关键字过滤或者内容插入等功能。

另外一个常常被提到功能就是安全性。网络中最常见的 SYN Flood 攻击,即黑客控制众多源客户端,使用虚假 IP 地址对同一目标发送 SYN 攻击,通常这种攻击会大量发送 SYN 报文,耗尽服务器上的相关资源,以达到 Denial of Service(DoS) 的目的。

从技术原理上也可以看出,四层模式下这些 SYN 攻击都会被转发到后端的服务器上;而七层模式下这些 SYN 攻击自然在负载均衡设备上就截止,不会影响后台服务器的正常运营。

另外负载均衡设备可以在七层层面设定多种策略,过滤特定报文,例如 SQL Injection 等应用层面的特定攻击手段,从应用层面进一步提高系统整体安全。

现在的 7 层负载均衡,主要还是着重于应用广泛的 HTTP 协议,所以其应用范围主要是众多的网站或者内部信息平台等基于 B/S 开发的系统。

4 层负载均衡则对应其他 TCP 应用,例如基于 C/S 开发的 ERP 等系统。

3. 七层应用需要考虑的问题


  1. 是否真的必要,七层应用的确可以提高流量智能化,同时必不可免的带来设备配置复杂,负载均衡压力增高以及故障排查上的复杂性等问题。
  2. 在设计系统时需要考虑四层七层同时应用的混杂情况。
  3. 是否真的可以提高安全性。例如 SYN Flood 攻击,七层模式的确将这些流量从服务器屏蔽,但负载均衡设备本身要有强大的抗 DDoS 能力,
  4. 否则即使服务器正常而作为中枢调度的负载均衡设备故障也会导致整个应用的崩溃。
  5. 是否有足够的灵活度。七层应用的优势是可以让整个应用的流量智能化,但是负载均衡设备需要提供完善的七层功能,满足客户根据不同情况的基于应用的调度。
  6. 最简单的一个考核就是能否取代后台 Nginx 或者 Apache 等服务器上的调度功能。
  7. 能够提供一个七层应用开发接口的负载均衡设备,可以让客户根据需求任意设定功能,才真正有可能提供强大的灵活性和智能性。


转载自:四层、七层负载均衡的区别 - Jamin Zhang
原文地址:https://jaminzhang.github.io/lb/L4-L7-Load-Balancer-Difference/