增加境外web接入服务器

[gaoyifan]

由于ustclug.org备案遇到困难，建议将ustclug.org的web接入点迁移到境外。 #157
兽兽给我们赞助了一台位于阿里云香港的VPS。
个人建议将整个ustclug.org域的校外访问都移动出去。

备忘：

• 新机器初始化：tinc (LUGI)、LDAP、ssh cert、salt-minion、telegraf
• 实现web请求转发（待讨论*）
• NS服务增加“科大”分域：校内解析不变，校外解析到香港

目前想到的几个转发方案，请大家一起集思广益：

1. 香港VPS配置nginx反向代理服务。需要修改nginx配置时，同时更新校内的反代服务器，和香港的反代服务器。
   好处是可以针对校内外配置不同的策略，比较灵活。缺陷是更新配置相对麻烦。

2. 校内的反代服务器新增一个内网IP，香港VPS将HTTP/HTTPS流量DNAT到新IP上。反向代理服务器上根据源地址，配置策略路由，走不同的网关回去。
   好处是配置简单，香港的机器不需要同步nginx配置； 缺陷是反代服务器上需要配置策略路由，不算主流方案。

大家觉得哪个比较好？或者其他方案？

---

当前反代方案：
gateway-el -> revproxy-el (via DNAT)
revproxy-el -> backend (via HTTP)
其中gateway-el是网关，单纯处理IP数据。revproxy-el是反向代理服务器，为各个站点统一做反向代理。

---

已迁移域名：

204.ustclug.org
auth.ustclug.org
adrain.ustclug.org
calendar.ustclug.org
docs.ustclug.org
getvpn.ustclug.org
monitor.ustclug.org
myip.ustclug.org
opensuse-guide.ustclug.org
proxy.ustclug.org
qtguide.ustclug.org
servers.ustclug.org
status.ustclug.org
www.ustclug.org

[yangzhaofeng]

將主站遷移出去就可以了吧？ 還有，lug.ustc.edu.cn下掛不了子域名嗎？ 2017-10-03 20:52 GMT+08:00 Yifan Gao <notifications@github.com>:

…

由于ustclug.org遇到备案困难，建议将ustclug.org的web接入点迁移到境外。 #157 <#157> 兽兽给我们赞助了一台位于阿里云香港的VPS。 个人建议将整个ustclug.org域的校外访问都移动出去。 备忘： - 新机器初始化：tinc (LUGI)、LDAP、ssh cert、salt-minion、telegraf - 实现web请求转发（待讨论*） - NS服务增加“科大”分域：校内解析不变，校外解析到香港 目前想到的几个转发方案，请大家一起集思广益： 1. 香港VPS配置nginx反向代理服务。需要修改nginx配置时，同时更新校内的反代服务器，和香港的反代服务器。 好处是可以针对校内外配置不同的策略，比较灵活。缺陷是更新配置相对麻烦。 2. 校内的反代服务器新增一个内网IP，香港VPS将HTTP/HTTPS流量DNAT到新IP上。 反向代理服务器上根据源地址，配置策略路由，走不同的网关回去。 好处是配置简单，香港的机器不需要同步nginx配置； 缺陷是反代服务器上需要配置策略路由，不算主流方案。 大家觉得哪个比较好？或者其他方案？ — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#183>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFj-rMF70Hnvpbh3xiTvNgk5-lE2rCW1ks5soi4fgaJpZM4PsD-2> .

[gaoyifan]

@yangzhaofeng

1. ustclug.org的子域名也有被盯上的先例
2. 之前所有的服务都是挂在lug.ustc.edu.cn下的。但由于这个域名实在太长了（比如gitlab.lug.ustc.edu.cn），因此注册了一个独立域名ustclug.org。（似乎是这样，这段历史我也不是非常清楚）

[yangzhaofeng]

要不將ustclug.org作為goo.gl那樣的短網址如何？ 將*.ustclug.org解析到香港，再HTTP重定向到*.lug.ustc.edu.cn 2017-10-03 21:04 GMT+08:00 Yifan Gao <notifications@github.com>:

…

@yangzhaofeng <https://github.com/yangzhaofeng> 1. ustclug.org的子域名也有被盯上的先例 2. 之前所有的服务都是挂在lug.ustc.edu.cn下的。但由于这个域名实在太长了（比如gitlab.lug.ustc.edu.cn ），因此注册了一个独立域名ustclug.org。（似乎是这样，这段历史我也不是非常清楚） — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#183 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFj-rHDcLIps_xNYBHEhnvzfSkQwKq3Iks5sojDWgaJpZM4PsD-2> .

[gaoyifan]

@yangzhaofeng 这也是一种可行的方案，不过这种方案操作比较繁琐。由于服务众多，每项服务都需要将域名从*.ustclug.org改为*.lug.ustc.edu.cn，而且有一些服务并不容易更改，比如GitLab。

[bojieli]

@gaoyifan

之前所有的服务都是挂在lug.ustc.edu.cn下的。但由于这个域名实在太长了（比如gitlab.lug.ustc.edu.cn），因此注册了一个独立域名ustclug.org。（似乎是这样，这段历史我也不是非常清楚）

确实是这样的。ustclug.org 独立域名是 @StephenPCG 捐赠的。

[bojieli]

我觉得 ustclug.org 可以做 Nginx 反向代理，服务器架设在香港。不管我们以后主要用哪个域名，至少保证原来 ustclug.org 的 URL 可以访问。需要注意 git.ustclug.org，由于 SSH key 的问题，需要从国外代理做 DNAT/SNAT 到校内 gitlab 服务器。

[bojieli]

香港VPS配置nginx反向代理服务。需要修改nginx配置时，同时更新校内的反代服务器，和香港的反代服务器。
好处是可以针对校内外配置不同的策略，比较灵活。缺陷是更新配置相对麻烦。

校内的反代服务器是指？现在 LUG 服务已经有统一的校内入口做反代嘛？

如果已经有的话，考虑到校内反代服务器不是瓶颈，为什么不把校外反代服务器把所有 HTTP 请求全部反代到校内反代服务器，校内反代服务器配置不变。这样校外反代服务器就不用改 nginx 配置了。

不管是校外直接反代到后端，还是通过校内总代理再到后端，都需要在校内和校外的反代上都部署 SSL 证书。不过我们不接受第三方域名，并且证书用了 letsencrypt，事情就变得简单了，只要两边的脚本都自动续期就行，两边分别申请和部署的是两套证书。

校内的反代服务器新增一个内网IP，香港VPS将HTTP/HTTPS流量DNAT到新IP上。反向代理服务器上根据源地址，配置策略路由，走不同的网关回去。
好处是配置简单，香港的机器不需要同步nginx配置； 缺陷是反代服务器上需要配置策略路由，不算主流方案。

我觉得这个是最简单的方案，只是会增加几个 round trip（TCP 握手和 TLS 握手），延迟会稍微高一些。之前 blog 和 freeshell 因为有第三方域名 SSL 证书的问题，用的就是这种反代方案。

[gaoyifan]

校内的反代服务器是指？现在 LUG 服务已经有统一的校内入口做反代嘛？

目前方案是：
gateway-el -> revproxy-el (via DNAT)
revproxy-el -> backend (via HTTP)
其中gateway-el是网关，单纯处理IP数据。revproxy-el是反向代理服务器，为各个站点统一做反向代理。

如果已经有的话，考虑到校内反代服务器不是瓶颈，为什么不把校外反代服务器把所有 HTTP 请求全部反代到校内反代服务器，校内反代服务器配置不变。这样校外反代服务器就不用改 nginx 配置了。

主要是考虑到维护两套证书（及配置）比较繁琐。

不管是校外直接反代到后端，还是通过校内总代理再到后端，都需要在校内和校外的反代上都部署 SSL 证书。不过我们不接受第三方域名，并且证书用了 letsencrypt，事情就变得简单了，只要两边的脚本都自动续期就行，两边分别申请和部署的是两套证书。

目前使用的是兽兽赞助的通配符证书

我觉得这个是最简单的方案，只是会增加几个 round trip（TCP 握手和 TLS 握手），延迟会稍微高一些。之前 blog 和 freeshell 因为有第三方域名 SSL 证书的问题，用的就是这种反代方案。

可以用tcp中继来规避握手延迟的问题。安利一波：https://github.com/gaoyifan/tcp-transparent-repeater

[gaoyifan]

由于LUG的所有机器的内网都是互通的，我觉得香港机器的角色更像是一个网关。
在现有的 “网关”-“反代” 相互独立的架构下，如何做到多网关同时工作是一个比较核心的问题。

1. 如果网关同时做DNAT和SNAT，那么其他机器不需要修改任何配置就可以工作，对内网主机来说是透明的。但会损失源地址。
2. 如果网关只做DNAT。我没有想到有效的方法能够让内网主机透明得使用两个网关，似乎需要配置策略路由之类的东西才能工作。 （师兄有什么想法吗？@StephenPCG @bojieli

如果在香港网关上装上nginx，相当于将网关和反代二合一了。这种模式下网关和反代就变成一一对应的关系了，一个反代只能接受来自某一个固定网关的数据。也是一种不错的选择。

[zhsj]

我支持直接在那台服务器上装个nginx，觉得比较切合题意“web接入服务器”，又没有很多玄学。

[bojieli]

如果网关同时做DNAT和SNAT，那么其他机器不需要修改任何配置就可以工作，对内网主机来说是透明的。但会损失源地址。如果网关只做DNAT。我没有想到有效的方法能够让内网主机透明得使用两个网关，似乎需要配置策略路由之类的东西才能工作。

策略路由当然是一种方案。要实现这种所谓的 overlay IP 网络，更通用的做法是 encapsulation。内网里面所有的包都是 GRE 包，外层是内网地址，内层是公网地址。这样在两个内网中的 end host 看来，不管内网多复杂，看起来都像是只有一跳；在一个内网的 end host 和一个外网的 end host 看来，整个内网像是个大二层网络，从内向外只经过一个出口路由器就到了外网。

如果 overlay IP 网络需要跨 Internet，就需要再打一层 GRE 包，外层是公网地址，内层是内网地址。把两个结合起来，比如新加坡数据中心公网网关 133.130.124.1（内网地址 10.1.0.1），科大数据中心网关 202.38.64.1（内网地址 10.2.0.1），应用服务器实际位于科大的 202.38.95.110（内网地址 10.2.1.110），现有一个来自 8.8.8.8 的用户请求抵达新加坡数据中心，那么它在两个数据中心之间的公网上是双层 GRE 包：(IP4 133.130.124.1 -> 202.38.95.110, GRE) (IP4 10.1.0.1 -> 10.2.1.110, GRE) (IP4 8.8.8.8 -> 202.38.95.110, TCP)。

[bojieli]

可以用tcp中继来规避握手延迟的问题。安利一波：https://github.com/gaoyifan/tcp-transparent-repeater

这个不错，能够把 TCP 的握手延迟降低到（用户 -> 中继器）和（中继器 -> HTTP 服务器）延迟的较大值。不过对于 HTTPS，TLS 握手延迟仍然是没法消除的。

[bojieli]

我支持直接在那台服务器上装个nginx，觉得比较切合题意“web接入服务器”，又没有很多玄学。

我也支持直接装 nginx，兽兽捐赠的泛域名证书也不多，部署一次不算麻烦。另外我们的配置是不是用 saltstack 管理的啊，如果是，改两个也不算麻烦吧。

[gaoyifan]

策略路由当然是一种方案。要实现这种所谓的 overlay IP 网络，更通用的做法是 encapsulation。内网里面所有的包都是 GRE 包，外层是内网地址，内层是公网地址。这样在两个内网中的 end host 看来，不管内网多复杂，看起来都像是只有一跳；在一个内网的 end host 和一个外网的 end host 看来，整个内网像是个大二层网络，从内向外只经过一个出口路由器就到了外网。
如果 overlay IP 网络需要跨 Internet，就需要再打一层 GRE 包，外层是公网地址，内层是内网地址。

目前LUG的需求与师兄描述的 "overlay IP跨越Internet" 非常契合。之前也有考虑过一堆IPSec/GRE隧道的方案。
没这么做是因为配置起来很繁琐，如果有20台机器，就需要创建190 对隧道，手动维护是不可接受的。我记得IOS支持这种overlay封装，在路由器上统一封包，好像也可以使用vxlan封装。但是我在Linux下没找到合适的工具，能够创建点对点的mesh隧道。
后来 @bojieli 师兄介绍了tinc，能够实现分布式mesh vpn，并且维护量相对小很多。于是乎就选择了tinc。

将网关的公网地址通过隧道转发到应用服务器，这就类似于IPVS的IPIP模式。应用服务器上仍然需要创建IPIP隧道（或者师兄提到的GRE隧道）。然而，为了同时保证隧道的网络与原生的网络能够同时工作，似乎仍然需要配置基于源地址的策略路由。

不过对于 HTTPS，TLS 握手延迟仍然是没法消除的。

是的。 除非在edge上部署私钥，否则传输层应该是没办法大幅减少SSL握手延迟的。

另外我们的配置是不是用 saltstack 管理的啊，如果是，改两个也不算麻烦吧。

由于暂时只有一个反代服务器，因此nginx配置是git管理的。webhook触发更新应该很容易实现。