mirror of
https://github.com/chaitin/SafeLine.git
synced 2026-02-06 00:33:56 +08:00
94 lines
6.3 KiB
Markdown
94 lines
6.3 KiB
Markdown
---
|
||
title: "配置防护站点"
|
||
---
|
||
|
||
# 配置防护站点
|
||
|
||
## 界面操作
|
||
|
||
|
||
添加后，在客户端执行 `curl -H "Host: <域名>" http://<雷池 IP>:<雷池监听端口>` ，若能获取到业务网站的响应，并且站点上 “今日访问量” 增加，则代表配置成功。
|
||
|
||
## 如何配置域名、端口、上游服务器
|
||
### 工作原理
|
||
|
||
雷池社区版主要以 **反向代理** 的方式工作，类似于一台 nginx 服务。部署时，需要让网站流量先抵达雷池，经过雷池检测和过滤后，再转给原来的网站业务。
|
||
|
||
如果你不了解反向代理的工作原理，可以通过以下几种雷池常见的工作场景，来了解如何配置站点。
|
||
|
||
假设你的网站域名为 `example.com`，如图：
|
||
|
||
|
||
|
||
### 在单独设备上部署雷池（推荐）
|
||
|
||
如果你可以提供一台独立设备部署雷池，那么你需要：
|
||
1. **将网站流量指向雷池**。例如将域名解析到雷池
|
||
2. 禁止网站服务器上，所有除了雷池之外的访问。例如配置防火墙，或者直接把网站服务器放到内网
|
||
|
||
效果大致如下：
|
||
|
||
|
||
|
||
雷池上相应的站点配置为：
|
||
* 域名：公网域名 `example.com`
|
||
* 端口：80 或 443/ssl
|
||
* 上游服务器：网站服务器的地址 `http://192.168.10.10`
|
||
|
||
### 直接在网站服务器上部署雷池
|
||
|
||
提示：不建议这样部署，因为这样单机的负载更高、设备宕机的概率更大。非纯净的环境还会提高安装失败的概率，故障排查也会比较困难。
|
||
|
||
如果能接受这些风险，雷池也可以直接部署在网站服务器上。你需要：
|
||
1. 将原本监听 80 或 443/ssl 端口的网站服务改到其他端口，**让雷池监听设备的 80 或 443/ssl 端口**
|
||
2. 使网站服务仅允许本机访问。例如配置系统防火墙、Iptables
|
||
|
||
效果大致如图：
|
||
|
||
|
||
|
||
此时雷池上的站点配置为：
|
||
* 域名：公网域名 `example.com`
|
||
* 端口：80 或 443/ssl
|
||
* 上游服务器：`http://127.0.0.1:<网站服务改后的端口>`
|
||
|
||
### 和其他反代设备一起部署的情况
|
||
|
||
雷池作为反代设备，可以在任意位置接入主链路。只要将接入位置的流量指向雷池，并在雷池的 “上游服务器” 处填写请求的下一跳服务器地址即可。例如：
|
||
|
||
|
||
|
||
## 配置后网站无法访问，如何排查
|
||
|
||
如果按照上文指引部署雷池、配置了站点，但网站仍无法访问，建议按照以下步骤排查：
|
||
|
||
1. 明确 “网站无法访问” 的具体表现：
|
||
* 如果 `502 Bad Gateway tengine`：
|
||
|
||
|
||
|
||
大概率是是雷池的上游服务器配置不正确，或者雷池无法访问到上游服务器。请继续按下面步骤排查，重点排查步骤 6、7
|
||
* 如果请求能够返回但是十分缓慢
|
||
* 首先确认服务器负载是否正常
|
||
* 在客户端执行命令，检查雷池服务器与上游服务器的网络：`curl -H "Host: <SafeLine-IP>" -vv -o /dev/null -s -w 'time_namelookup: %{time_namelookup}\ntime_connect: %{time_connect}\ntime_starttransfer: %{time_starttransfer}\ntime_total: %{time_total}\n' http://<上游服务器地址>`
|
||
* 如果 time_namelookup 时间过大，请检查 dns server 配置
|
||
* 如果 time_connect 时间过大，请检查雷池与上游服务器之间的网络状态
|
||
* 如果 time_starttransfer 时间过大，请检查上游服务器状态，是否出现资源过载情况
|
||
* 如果不是以上情况，继续下一步
|
||
2. 在客户端执行 `curl -H "Host: <域名>" http://<雷池 IP>:<雷池监听端口>` 。正常情况下，应能获取到业务网站的响应，并且站点的 “今日访问量” +1
|
||
* 如果浏览器无法访问，但这一步正常获取到响应，大概率是因为：
|
||
* 测试过程中，网站域名还没有切到雷池，浏览器测试时访问的是 `http(s)://<雷池 IP>`，恰好业务服务上有 Host 验证，所以拒绝了该请求。这种情况需要修改本机 host，把域名解析到雷池 IP，再访问 `http(s)://<域名>`，才能准确测试
|
||
* 网站业务做了其他一些特殊处理。例如访问后 301 跳转到了其他地址，需要具体排查网站业务的响应内容
|
||
* 如果不能获取到响应，继续下一步
|
||
3. 在雷池设备上执行 `curl -H "Host: <域名>" http://<雷池 IP>:<雷池监听端口>`。正常情况下，应能获取到业务网站的响应，并且站点上 “今日访问量” +1
|
||
* 如果步骤 2 失败而这里成功，说明客户端到雷池之间的网络存在问题。请排查网络，保证客户端可访问到雷池
|
||
* 如果不能获取到响应，继续下一步
|
||
4. 在雷池设备上执行 `curl -H "Host: <域名>" http://127.0.0.1:<雷池监听端口>`。正常情况下，应能获取到业务网站的响应，并且站点的 “今日访问量” +1
|
||
* 如果步骤 3 失败而这里成功，且 `telnet <雷池 IP> <雷池监听端口>` 返回 `Unable to connect to remote host: Connection refused`，大概率是被雷池设备上的防火墙拦截了。可能是操作系统本身的防火墙，还有可能是云服务商的防火墙。请根据实际情况逐项排查，开放雷池监听端口的访问
|
||
* 如果不能获取到响应，继续下一步
|
||
5. 在雷池设备上执行 `netstat -anp | grep <雷池监听端口>` 确认端口监听情况。正常情况下，应该有一个 nginx 进程监听在 `0.0.0.0:<雷池监听端口>`。没有的话请通过社群或者 Github issue 提交反馈，附上排查过程。有的话继续下一步
|
||
6. 在雷池设备上 `curl -H "Host: <域名>" <上游服务器地址>`。正常情况下，应能获取到业务网站的响应
|
||
* 如果步骤 4 失败而这里成功，请通过社群或者 Github issue 提交反馈，附上排查过程
|
||
* 如果这步失败，说明雷池和上游服务器之间的网络存在问题。请排查网络，确保雷池可以访问到上游服务器
|
||
|
||
如果排查后问题还是没有解决，请通过社群或者 Github issue 提交反馈，并附上排查的过程和截图。 |