多条宽带的分流
2020-09-11又好久没有写文章了，想起来写一篇。
最近组网，发现有些场景下，这个地方有多条宽带，然后需要充分利用这么多宽带，用来优化上网体验或是提供更多的对外服务。于是就需要一个可以分流的方案，把入站流量以及出站流量分到不同的宽带里面，充分利用这些宽带的上行或者下行优势。
经过这一段时间的研究，算是研究出来了几种可行的方案，这里列举一下。本文默认内网 IP 段为 10.0.0.0/24。
PPPoE 多拨
这里顺便提供一下 PPPoE 多拨在 Linux 下的正确姿势。PPPoE 多拨需要有不同的 MAC 地址才能拨号。因此我们这里用 macvlan 模拟多个 MAC 地址进行拨号。这种方法不需要添加物理交换机，从墙上或者光猫直接插网线就行。
这里以 Debian 为例，在 /etc/network/interfaces 这样写即可。这里假设 PPPoE 所在的物理网卡为 ens3，只拨 2 个号。如果有 VLAN 的话，可以写成 ens3.10 这样的形式。
auto ens3
iface ens3 inet manual
auto ppp0
iface ppp0 inet ppp
pre-up /bin/ip link add link ens3 dev pppm0 type macvlan && /bin/ip link set pppm0 up
post-down /bin/ip link del dev pppm0
provider ppp0
auto ppp1
iface ppp1 inet ppp
pre-up /bin/ip link add link ens3 dev pppm1 type macvlan && /bin/ip link set pppm1 up
post-down /bin/ip link del dev pppm1
provider ppp1
然后创建 /etc/ppp/peers/pppX 文件（X为ppp编号，从0开始排多个），如下。记得自行更换 ppp0 以及 pppm0 为其他数字。
noipdefault
hide-password
noauth
persist
plugin rp-pppoe.so pppm0
ifname ppp0
user "宽带帐号"然后在 /etc/ppp/pap-secrets 和 /etc/ppp/chap-secrets 各添加一行宽带帐号信息。
"宽带帐号" * "宽带密码"需要注意的是，Ubuntu 的 netplan 是不可以拨 PPPoE 的，不过可以把 ifupdown 装回来，就可以如同 Debian 那样配置了。在这种情况下，只需要在/etc/network/interfaces 写和 PPPoE 的虚拟网卡相关的配置就行，物理网卡的启动可以继续放在 netplan 里面。
源进源出
还是从这个古老的话题说起。源进源出之前也研究的很成熟了，尤其是折腾各种 VDIP 和隧道的时候研究的最多的。
先做一个小小的科普，VDIP 这个名词出自 Sakura Frp 之前的附属服务（现在消亡了），全称是 Virtual Dedicated IP Address，给没有公网 IP 的用户提供一条虚拟的公网 IP，并且可以保证用户源 IP。然而这个服务的主人 Akkariin Meiko 也没能悟出这个服务的精髓，即源进源出，即正常的入站流量正常走，而从隧道进来的流量从隧道回去。这里说一个常见的用于 wireguard 的源进源出的命令配置。这里 10.0.1.0/24 为隧道网段。
ipset create mycard hash:net family inet || true
ipset add mycard 10.0.0.0/24 || true
ip rule add pref 80 to 10.0.0.0/24 lookup main || true
ipset add mycard 10.0.1.0/24 || true
ip rule add pref 80 to 10.0.1.0/24 lookup main || true
ip -4 route add 10.0.1.0/24 dev wgmc || true
ip rule add pref 90 fwmark 777 lookup 777 || true
iptables -t mangle -A PREROUTING -i wgmc -m set ! --match-set mycard src -j CONNMARK --set-xmark 777/0xffffffff
iptables -t mangle -A PREROUTING -m connmark --mark 777 -j CONNMARK --restore-mark --nfmask 0xffffffff --ctmask 0xffffffff
iptables -t mangle -A OUTPUT -m connmark --mark 777 -j CONNMARK --restore-mark --nfmask 0xffffffff --ctmask 0xffffffff上面的 mycard 这个 ipset ，代表全部内网的地址段的 ipset，如果有多个子网或者和隧道连接的其他地方，则都需要写上，ip rule pref 80 lookup main 也是如此。本文后面出现的 mycard ipset 也是这个意思，将不再列举。
这里稍微变通一下，在多宽带的场景下，每条宽带都需要做一个源进源出的规则，然后在 DNS 方面设置一条解析记录，均匀返回两个宽带的 IP，即可完成基本的入站带宽叠加，宽带就有了两倍的对外服务能力。
本人比较习惯于，在 PPPoE 或者其他宽带形式的 PostUp 脚本内，设置 ip rule 和 ip route 规则，而在 wireguard 的 PostUp 脚本内，设置 iptables 规则。这是因为 iptables 会涉及 ipset，而这个 ipset 由于涉及众多节点，只会在wireguard 的脚本内进行添加。
本人使用的 PPPoE 的 PostUp脚本如下，可以参考。
#!/bin/bash
INIT_ID=$[400 + $(echo "$PPP_IFACE" | sed "s/ppp//g")]
INIT_ID_2=$[510 + $(echo "$PPP_IFACE" | sed "s/ppp//g")]
iptables -t mangle -A FORWARD -o "$PPP_IFACE" -p tcp -m tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1452:1460 -j TCPMSS --set-mss 1452
iptables -t mangle -A FORWARD -i "$PPP_IFACE" -p tcp -m tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1452:1460 -j TCPMSS --set-mss 1452
ip6tables -t mangle -A FORWARD -o "$PPP_IFACE" -p tcp -m tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1432:1460 -j TCPMSS --set-mss 1432
ip6tables -t mangle -A FORWARD -i "$PPP_IFACE" -p tcp -m tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1432:1460 -j TCPMSS --set-mss 1432
iptables -t nat -o "$PPP_IFACE" -A POSTROUTING -j MASQUERADE
ip route add default dev "$PPP_IFACE" table $INIT_ID
ip route add default dev "$PPP_IFACE" metric $INIT_ID
ip rule add pref 300 fwmark $INIT_ID lookup $INIT_ID
ip rule add pref 400 fwmark $INIT_ID_2 lookup $INIT_ID
iptables -t mangle -A POSTROUTING -o "$PPP_IFACE" -j TTL --ttl-set 64
iptables -t mangle -A OUTPUT -o "$PPP_IFACE" -j TTL --ttl-set 64
iptables -t mangle -A FORWARD -o "$PPP_IFACE" -j TTL --ttl-set 64
iptables -t mangle -A FORWARD -i "$PPP_IFACE" -j TTL --ttl-set 64
iptables -t mangle -A PREROUTING -i "$PPP_IFACE" -j TTL --ttl-set 64
iptables -t mangle -A INPUT -i "$PPP_IFACE" -j TTL --ttl-set 64这里简要说明一下，INIT_ID 取值和 pppX 的数值 X 相关，用于批量配置多个 ppp 方便。INIT_ID_2 是另一个辅助 ID。这两个 ID 用于两个不同的 mark。第一个 mark 是用于源进源出的，第二个 mark 是用于分流的。
后 4 行与 mss 相关的规则，是用来协调 PPPoE 的 MTU 的。之后一行是 NAT 。而后面的 ip 开头的命令是用来添加默认路由和策略路由的。这里后面的 iptables 会用到。最后 6 行是用来规范 PPPoE 网卡的数据包的 TTL 的，防止部分运营商通过这个来查到共享上网。
最后是 iptables 部分，放置于 WireGuard 的 PostUp 脚本内，设置源进源出使用的。
ipset create mycard hash:net family inet || true
ipset add mycard 10.0.0.0/24 || true
ip rule add pref 80 to 10.0.0.0/24 lookup main || true
restore_mark() {
OPTION=$1
MARK=$2
iptables -t mangle "$OPTION" PREROUTING -m connmark --mark "$MARK" -j CONNMARK --restore-mark
iptables -t mangle "$OPTION" OUTPUT -m connmark --mark "$MARK" -j CONNMARK --restore-mark
}
ppp_origin() {
OPTION=$1
INTERFACE=$2
INIT_ID=$[400 + $(echo "$INTERFACE" | sed "s/ppp//g")]
INIT_ID_2=$[$INIT_ID + 110]
iptables -t mangle "$OPTION" PREROUTING -i "$INTERFACE" -m set ! --match-set mycard src -j CONNMARK --set-xmark "$INIT_ID"
restore_mark "$OPTION" "$INIT_ID"
}
ppp_origin -A ppp0
ppp_origin -A ppp1,18002这里的 INIT_ID 与 PPPoE 的脚本吻合，对应两个 ppp 网卡。这里主要使用与 INIT_ID 相关的规则。INIT_ID_2 相关的规则将在下一节使用。
这样，每个宽带的入站请求都会打上 mark，通过 mark 把流量送回，而实现源进源出。
出站分流
说到这个，就是一个痛苦的话题了。各种出站的需求都不一样。很难有一个统一的出站分流方案。比如有些人想要最快的下载速度，用两份带宽同时下载。有些人需要银行这种场景的 IP 稳定性，不能让 IP 左右跳来影响 IP 触发网银风控。而有些情况下需要某些重要的人使用一份独立的宽带，其他人用其他宽带。
这里我们就分别说几种方案，分开来讨论。不过不管使用哪种方案，上面的源进源出的规则必须带着走，否则对外服务可能会出现问题。
Plan A: 均衡
均衡是最通用的一种方法。就是按均分所有的连接到每一个出口，进行带宽叠加。这种方法可以直接叠加带宽上去。但是呢对于网银等有些 IP 敏感的业务，可能会被风控。
下面上规则代码。注意需要与上面的 PPPoE 启动脚本一起使用，用于添加配合的 ip rule 策略路由。
ipset create mycard hash:net family inet || true
ipset add mycard 10.0.0.0/24 || true
ip rule add pref 80 to 10.0.0.0/24 lookup main || true
restore_mark() {
OPTION=$1
MARK=$2
iptables -t mangle "$OPTION" PREROUTING -m connmark --mark "$MARK" -j CONNMARK --restore-mark
iptables -t mangle "$OPTION" OUTPUT -m connmark --mark "$MARK" -j CONNMARK --restore-mark
}
ppp_origin() {
OPTION=$1
INTERFACE=$2
INIT_ID=$[400 + $(echo "$INTERFACE" | sed "s/ppp//g")]
INIT_ID_2=$[$INIT_ID + 110]
iptables -t mangle "$OPTION" PREROUTING -i "$INTERFACE" -m set ! --match-set mycard src -j CONNMARK --set-xmark "$INIT_ID"
restore_mark "$OPTION" "$INIT_ID"
}
ppp_origin -A ppp0
ppp_origin -A ppp1
iptables -t mangle -A PREROUTING -s 10.0.0.0/24 -m set ! --match-set mycard dst -m statistic --mode nth --every 2 --packet 0 -j CONNMARK --set-xmark 510
iptables -t mangle -A PREROUTING -s 10.0.0.0/24 -m set ! --match-set mycard dst -m statistic --mode nth --every 2 --packet 1 -j CONNMARK --set-xmark 511
restore_mark -A 510
restore_mark -A 511注意这里的 iptables 规则顺序。源进源出规则必须在分流规则之前，避免内网对外服务失效。
Plan B: 奇偶 IP
Plan A 比较适合需要大量下载的场景。但是在需要访问外网源 IP 稳定的场景，这里奇偶 IP 的方法是比较好的，可以做到相同内网源 IP 和目标 IP 访问的出口 IP 一致。
首先，科普一下非标掩码的概念。在通常的情况下，子网掩码是从左往右叠加的。如 /24 的完整掩码是 255.255.255.0。在特殊的子网的情况下，不一定每一位是255。如 /22 是 255.255.252.0，是 /24 的 IP 数量的 4 倍。然而还有一种更特殊的，也就是我们这里需要用到的。形如 255.255.255.1这样的掩码，二进制分解之后就是 11111111.11111111.11111111.00000001，也就是判断前三端以及最后一段的最后一位，表示的意思是 “头三段完全一致以及最后1位一致” 的地址。
这里的用途在于，可以构造一个非标掩码子网段，用来把一个网段分割成两部分，按奇偶分开，实现负载均衡。如 10.0.0.0/255.255.255.1 为内网内 IP 末位是偶数的地址，而 10.0.0.1/255.255.255.1 则为内网内 IP 末位是奇数的地址。类似的，0.0.0.0/0.0.0.1则为全部 IP 末位是偶数的地址，0.0.0.1/0.0.0.1 同理。
非标掩码支持的地方有限。目前只知道 iptables 支持，但是 ip rule 不支持。因此规则如下。
ipset create mycard hash:net family inet || true
ipset add mycard 10.0.0.0/24 || true
ip rule add pref 80 to 10.0.0.0/24 lookup main || true
restore_mark() {
OPTION=$1
MARK=$2
iptables -t mangle "$OPTION" PREROUTING -m connmark --mark "$MARK" -j CONNMARK --restore-mark
iptables -t mangle "$OPTION" OUTPUT -m connmark --mark "$MARK" -j CONNMARK --restore-mark
}
ppp_origin() {
OPTION=$1
INTERFACE=$2
INIT_ID=$[400 + $(echo "$INTERFACE" | sed "s/ppp//g")]
INIT_ID_2=$[$INIT_ID + 110]
iptables -t mangle "$OPTION" PREROUTING -i "$INTERFACE" -m set ! --match-set mycard src -j CONNMARK --set-xmark "$INIT_ID"
restore_mark "$OPTION" "$INIT_ID"
}
ppp_origin -A ppp0
ppp_origin -A ppp1
iptables -t mangle -A PREROUTING -m mark --mark 0 -s 10.0.0.0/255.255.255.1 -d 0.0.0.0/0.0.0.1 -m set ! --match-set mycard dst -j CONNMARK --set-xmark 510
iptables -t mangle -A PREROUTING -m mark --mark 0 -s 10.0.0.1/255.255.255.1 -d 0.0.0.0/0.0.0.1 -m set ! --match-set mycard dst -j CONNMARK --set-xmark 511
iptables -t mangle -A PREROUTING -m mark --mark 0 -s 10.0.0.0/255.255.255.1 -d 0.0.0.1/0.0.0.1 -m set ! --match-set mycard dst -j CONNMARK --set-xmark 511
iptables -t mangle -A PREROUTING -m mark --mark 0 -s 10.0.0.1/255.255.255.1 -d 0.0.0.1/0.0.0.1 -m set ! --match-set mycard dst -j CONNMARK --set-xmark 510
restore_mark -A 510
restore_mark -A 511这里奇偶性错位稍微有一点小技巧。这里把源和目标 IP 奇偶性相同的放在一个宽带里面，把不同的放在另一个宽带里面。至于为什么这么错位，是为了保证，在不同内网机器访问同一外网网站，以及同一内网机器访问不同外网网站的情况下，都能把流量分开。
题外话
本文的场景都是 PPPoE 或者其他三层隧道的情况下的分流。如果是 IDC 网络，涉及三层寻址找网关的，则需要这么写源进源出规则。
ppp_origin() {
OPTION=$1
ADDRESS=$2
NEIGH_LINE=$(ip neigh show $ADDRESS)
INTERFACE=$(echo $NEIGH_LINE | awk '{print $3}')
MAC=$(echo $NEIGH_LINE | awk '{print $5}')
INIT_ID=$3
INIT_ID_2=$[$INIT_ID + 110]
iptables -t mangle "$OPTION" PREROUTING -i "$INTERFACE" -m mac --mac-source $MAC -m set ! --match-set mycard src -j CONNMARK --set-xmark "$INIT_ID"
restore_mark "$OPTION" "$INIT_ID"
}这里第二个参数是机房提供的网关的 IP 地址，第三个参数是 mark 以及 table 的取值。
最近开的一些新网站
2020-03-22Taiko Web由于版权原因，不能继续开在 MyCard 那边了，于是搬到了 https://tg.lv5.ac 继续开。Namco 的法务部简直比任天堂的还厉害，没办法。
Namco 说域名里面的 taiko 他们也是有商标的，我这边不许用。为了妥协，只好改成了tg（太鼓）了。
搬过来之后，虽然比以前慢了一些，恋恋也尽可能优化这个网站的质量给大家最棒的打鼓体验了。同时，也增加了皇冠记录系统，魂槽也接近本家了。
另外，恋恋自己搭建了一个 ooi，在 https://ooi.momobako.com 。相比官方的ooi好在国内接入，然后国外落地的，完全就是机场的姿势。虽然我不怎么喜欢做机场。
舰C那边，前几次受到了莫名的网络攻击，现在防火墙变得更厉害了。会封禁所有非日本IP，还有所有数据中心的IP。也就是传统的梯子也没办法访问了，于是只能用日本家宽来开。幸运的是，恋恋还是找到了一个日本家宽来用。
目前只有一个日本落地节点。以后其实还打算新增多几个节点用来落地，拭目以待吧。国内访问这一块，目前就复用的萌卡CDN系统，尽可能保证大家的访问速度。
不知道为什么北娘要做付费的IPLC ooi了。不知道授权系统会怎么授权。IPLC确实比较贵，应该还能理解。
关于 Minecraft
2019-09-03Minecraft 是一个沙盒类游戏，自由度很高，玩家可以创作自己喜欢的东西，也可以运营一个自己的服务器给大家参观或者玩耍。
这也给 Minecraft 服务器出租带来了不少市场。于是市面上出现了不少的 Minecraft 服务商，提供 Minecraft 服务器出租业务，赚了不少。恋恋也有点想入这个局，利用现有的服务器资源，提供 Minecraft 服务器出租，来补贴一些服务器的租金支出。
恋恋之前卖过少量的 VPS 服务器供客户搭建 Minecraft 服务器使用。但是总有人觉得 VPS 使用难度比较大，隔一段时间就有人问我 Minecraft 服务器怎么安装，或者 Java 怎么安装，甚至是让恋恋帮他们调试他们的服务端。恋恋自己对Minecraft 服务器的了解程度有限，只能从运维的角度来帮忙解决问题。而遇到具体到应用的问题，恋恋也只能查阅文档来进行处理。令人沮丧的是，还有人觉得 VPS 不好用，偏要用面板服。
借助一次契机，恋恋和 MyCard 的人员搭建好了一个翼龙面板，让出租简单易用 Minecraft 面板服成为了可能。由于翼龙基于 Docker 环境，服务器被熊被提权的概率小了好多。此外，也研究好了 WHMCS 的系统，让销售服务器变成了自动化过程，省了好多事，可以自动化出售服务器。
但是，恋恋通过一些渠道了解到，Minecraft 的圈子有一些不太好的地方。如，有些玩家脾气非常怪异，和服务器其他人相处有问题就对服务器发动 DDoS 攻击，让服务器的主人以及服务商陷入难堪。而且，服务器遭到 DDoS 攻击还会影响其他的生产环境的应用，带来一定的损失。因此，恋恋只能在路由策略上下一点工夫，让遭到 DDoS 带来的损失降到最小。
恋恋目前在犹豫的是，自己和 MyCard 这边，相比其他商家能带来什么优势呢？其他服务商的服务器动不动就是好几线 BGP 线路，优势非常大。恋恋这边只能使用部署过的冗余的机器进行搭建，效果没那么好。Minecraft 服务器出租，到底又什么出路呢？
新的服务器
2019-07-26新的服务器的名字，叫 Hatsuki Yura（叶月由罗）
地址: hatsukiyura.yuzurisa.com
配置: 1C512M（有点小）
叶月由罗是一个非常不错的歌手，唱的哥特风格的歌曲非常的多。下面会放一首歌来给大家听听。
这个服务器目前作为各个比赛服访问Challonge的代理，通过Wireguard通信转发，来保证速度。
设置这个服务器的原因是有一次战队联盟的个人赛，服务器到Challonge的通信被万恶的墙挡住了，服务器崩溃了6次，于是恋恋设置了这个代理来保证正常。自从搭建好之后，比赛服务器再也不卡了，也给恋恋洗白了。
512M的内存比较小，还好够塞的下一个Nginx。从之前Kuroko反向代理的数据来看，内存也就用200M左右，因此完全够了。
Libevent 2.1
2019-07-09自从YGOPro的1.034.B版本开始，终于可以用上libevent 2.1了。
之前恋恋苦苦每次安装服务器的时候，都得编译安装libevent 2.0.22才能装好。直接使用apt安装libevent最新版本的话，非常容易决斗结束的时候挂掉，非常气。Docker也是，有一大段RUN语句，用来编译安装的。改了之后，所有的环境安装，一个RUN apt install …..就够了。
不过YGOPro的修改过程可谓非常艰辛。YGOPro客户端夏娜这么改之后，libvent就可以用最新版本了。然而，在YGOPro服务端就是另一个景象了。恋恋找了好久原因服务器为什么会卡住。结果各种方法都尝试了。最后发现，其实就是一个非常细小的问题。
不管怎么说，能用libevent 2.1是一个非常大的进步，再也不需要编译安装libevent 2.0.22了。不少兼容性问题也得到了解决。
东方联机暴露IP的弊端
2019-06-22在国内，大家要联机《东方非想天则》的时候，一般会选用MyCard这样的平台，为第三方提供内网穿透的平台，来解决NAT或者CGN等得不到公网IP的问题。恋恋一般要联机《东方非想天则》的话，在家里就直接IP直连，来自公网流量通过yuzurisa-storage.mycard.moe这台服务器转发。
但是，在国外，在公网IP资源比较富裕的地方，经常就是直接把IP暴露在房间列表里面，挂出来让大家联机使用。例如在则的Discord群里面，有一个Discord Bot的房间列表，大概是这样的。
ParvatiBOT05/25/2018 Current Hosts are:(UTC-04:00)For 8m 55.0s R 1.3Yosupall170.52.96.89:10800(edited) NEW MESSAGES ParvatiBOTToday at 9:36 AM Last Changes: @soku(UTC-04:00)For 2.8s R 1.3Yosupall170.52.96.89:10800
这种平台，自己的IP直接暴露给大家看，用来连接对方的电脑直接打。但是呢，不太好的地方是，如果是电脑直接连接公网，或者路由器设置了DMZ的话，如果电脑没有做适当的安全配置，电脑很容易被黑掉。尤其是135，139，445，3389这几个端口是重灾区。
在一些国内的则群里面，还甚至有人把自己的电脑IP挂在自己的群名片上面，方便大家联机。这也是安全隐患的来源之一。不过大部分人都是用路由器NAT上网，只开一个10800端口应该问题不是很大。虽然只开10800/udp也会被UDP Flood让家里断网。
在这里，恋恋推荐大家使用Wireguard搭建反向代理隧道，用iptables或者Nginx转发则的流量玩则。或者，不会的话。使用MyCard来联机则也是一个很好的选择。这样自己使用的IP就是一次性的，不会带来额外的安全风险。
服务器租不出去了
2019-06-17最近服务器变得难租了，不管是YGOPro方面，还是Minecraft方面。
恋恋本来想出租YGOPro的服务器，然后给每一个租客一个虚拟机用来部署业务。结果就发现，那些客户，都不知道怎么维护服务器。每次YGOPro更新的时候，就来了一堆人叫唤，说要恋恋帮忙更新。一个人还好，好几个人的话同一天，恋恋根本受不了。
Minecraft的话，相对来说，那些人的水平比较高，知道怎么开服怎么维护，不需要恋恋来操心。但是，不好竞争。上次有个人过来开口第一句问要什么CPU的服务器。不过也有那些特别笨的人，上来问恋恋Java怎么安装，什么服务器启动不了，然后好多恋恋自己也不会。恋恋不太会使用Windows来开服。
服务器出租是恋恋平时生活费的一个大头。为自己加油好了。
DDNS的那些事
2019-06-08DDNS是将用户的动态IP地址映射到一个固定的域名解析服务上，用户每次连接网络的时候客户端程序就会通过信息传递把该主机的动态IP地址传送给位于服务商主机上的服务器程序，服务器程序负责提供DNS服务并实现动态域名解析。
DDNS有一个最大的用途就是，可以在一般的动态公网IP的宽带上搭建服务器。最开始恋恋听说这个技术的时候，其实还是挺反感的，觉得用这个方法开服务器的人都是穷人，没钱买IDC的服务，或者阿里云的这些。
后来呢，恋恋和zh99998约会的那一次，恋恋改变了这个印象。因为DDNS开的服务器，除了一点点TTL的问题以外，都开得很好。于是呢恋恋也尝试了一下，用no-ip的服务开Yuzurisa服务器。结果表现得比恋恋想象的好很多。Yuzurisa服务器正式上线之后，因为家庭带宽非常的大，有50M上500M下，足够对外提供服务，所以表现得比想象中好很多。
再后来，恋恋就想充分利用各种家里能用的带宽来开服务器。恋恋入手了Ayane服务器，利用另一个房子的带宽，成功让服务器上线。Ayane服务器运行的还不错。目前位置，恋恋在Ayane服务器上部署了好几个KVM虚拟机。
一般的宽带都是封80端口的，防止私人建站。目前的解决方法是，用没有封闭的443端口通过HTTPS建站。另外，还可以加一层HSTS来防止用户敲错成HTTP。不过恋恋听说过Sakura Frp的那批人的家庭宽带被封的情况，但愿不要遇到吧。
但是DDNS很尴尬的地方就是，IP变的交接时间，服务器就访问不到了，业务也中断了。虽说名义上人家的DNS的TTL写的是10分钟，可是实际上部分黑心运营商的DNS服务器会人为放大TTL，就导致DNS的延迟更长。如果这发生在比赛的时候，就非常麻烦。
所以说，DDNS的确是一个成本很低的解决方案，不需要缴纳昂贵的IDC托管费用，就能用比较大的带宽完成业务部署。不过另一方面，TTL的问题还是挺让人头疼的。总的来说，有得有失吧。
恋恋的服务器家族
2019-06-05陆陆续续，到写这个博客的时候，恋恋在国内已经有4台独服，4个云服务了，可以拿来做很多事情。
恋恋的服务器命名方法继承了MyCard的命名，用可爱的名字来命名的，有一部分是人物的名字，但是另外一部分就是某些歌曲或者专辑的名字，这个完全看部署的时候的心情。另外呢，恋恋最早一批服务器的域名是*.ygopro.cn，后来有一部分是*.mycard.moe，再后来，还有一部分是*.momobako.com和*.yuzurisa.com。
Note: 下面的图片只是展示一个大致印象，并没有像osu娘，hostker娘那样的东西，把具体事物拟人化的意思。
Koishi
- 地址：koishi.moecube.com
- 操作系统：CentOS 7.5
- 类型：物理服务器
- 配置：E5-2670*2 128G 300G*4 20M
恋恋最早部署的上线的服务器就是Koishi服务器了，目前由恋恋自己，Millux，MyCard共同维持经费。这也是感情最深的一台服务器了。
这个服务器最开始在阿里云上面，但是呢由于7210服的玩家增长非常快，很快就超过了服务器能承受的负载量。一开始恋恋和Millux想商量升配，但是升配之后，月租就高达833一个月，恋恋和Millux无力承受这么高的月租，于是撤出阿里云。刚好恋恋想买一个新的独服，于是就把这个服务器托管到了一家IDC里面，目前在那里躺的很好。虽然中间出过几次大姨妈的问题，不过都解决得比较顺利。
再后来，恋恋和zh99998合作之后，这个服务器也用来作为恋恋和MyCard用的Web服务出口。这个服务商的ICP备案是非常松的，只要已经备案过，转入进来非常容易，马上就能上线的程度。
其实呢，这个服务器最早的地址是koishi.ygopro.cn，但是很遗憾的是，有一次恋恋和zh99998部署Nginx的反向代理服务的时候，忘了清除Nginx空主机头，结果服务器的IP惨遭电信封停。于是这个服务器的域名只好用koishi.moecube.com了。
Koishi服务器上面部署的业务挺多的，目前资源已经用尽了。上面开了YGOPro Koishi（7210）服，YGOPro 222DIY服，Taiko Web，还有Nanahira & Momobako本身。和MyCard正式合作之后，上面还开了YGOPro社区，NW社区这些业务的流量入口。
Nanahira
- 地址：koishi.222diy.gdn
- 操作系统：Ubuntu 16.04.6
- 类型：VPS
- 配置：4C 4G 80G 500M
这个是恋恋的第二台服务器，位于Hostker的VPS，由Nemoma维持赞助。
这台服务器最早用来用作YGOPro 222DIY服的自动更新的源。后来KoishiPro也推出自动更新功能之后，也用来做KoishiPro的自动更新的源。再后来KoishiPro2 iOS上线之后，还用来提供卡图。
这个服务器的资源最大的优势就是带宽，有500M上下行的大带宽，用都用不完的程度，因此做文件资源下载再合适不过啦！此外，因为是美国的服务器，所以不需要备案，这一点也很适合开网站。
不过KoishiPro刚刚在日本流行的时候，日本YGOPro的Discord群的管理，居然教大家利用自动更新程序下载完整的KoishiPro客户端，因此消耗了大量的带宽，直接导致服务器被Hostker发邮件警告，还封了一天。最后经过恋恋和日本人交涉，他们答应把流量引到GitHub Release上面，解决了问题。
除了文件下载服务以外，恋恋还用来开YGOPro Koishi服官网，本质和下载资源是放在一起的。本来好好的，结果呢KoishiPro2 iOS发布之后，大量玩家涌入这个网站下载游戏，结果这个网站就被标记为危险网站了。所以恋恋下一步的计划是，把这个官网搬走，搬到别的国内的备案过的服务器。
Halozy
- 地址：halozy.ygopro.cn
- 操作系统：Ubuntu 18.04.2
- 类型：云服务器
- 配置：1C 2G 50G 1M
Halozy是Nanahira所在的乐团，发行了不少专辑，都是特别可爱的那种。
Halozy服务器是恋恋的腾讯云学生机，10块一个月，非常划算，恋恋一口气喂食了3年。
尤其过年的时候，各大QQ群就开始发红包了，恋恋抢了不少，过个年从QQ上收个几百很正常。但是这些QQ钱包的余额就尴尬了，那么多钱，提现是需要手续费的。于是恋恋就想在QQ上把这些钱消费掉，于是就给Halozy喂食了那么多。
Halozy最开始是用来做YGOPro的测试服务器的。之前测试过断线重连，操作续时等功能，都测试得比较顺利。后来呢，恋恋就把服务器的用途改成了部署Docker服务，充分利用了服务器资源。
Senya
- 地址：senya.mycard.moe
- 操作系统：VMware ESXi 6.7.1
- 类型：物理服务器
- 配置：E5-2680v2*2 192G 600G*8 200M
恋恋的第二台独服，也是恋恋最高配的独服了。目前放在zh99998的机房里面托管。上面跑大部分MyCard的服务，也跑一些恋恋自己的奇怪的东西，比如恋恋试着开的Minecraft服务器。
这台服务器也是恋恋和MyCard的合作的内容之一。恋恋出服务器硬件的资金，然后zh99998那边提供网络环境，来得以部署成功。那一次zh99998来深圳的机会，恋恋就去和zh99998见了面，然后在景点玩了一个下午和一个晚上。中途还谈了不少东西，包括MyCard的未来的发展方向。
VMware ESXi操作系统是zh99998的主意。之前恋恋都用的是KVM来搭建虚拟化环境，而对VMware ESXi最开始很抗拒。后来恋恋适应了就觉得还好了，目前用的好好的。不过，恋恋到现在为止，还没亲自装出来过一个VMware ESXi的服务器过。
关于开虚拟机的习惯，恋恋和zh99998的习惯相差有点大。恋恋开的虚拟机，都是只有1C或者2C的小鸡。而zh99998喜欢划分掉机器的大部分资源，尤其硬盘100G起步，有时候还1T的。后来恋恋明白了原因：恋恋一般一个虚拟机就部署一个业务，直接运行。而zh99998部署出来就是一整套Docker的解决方案，可以部署多个业务，用资源大也是很正常的。
这个服务器的起名是恋恋要求起为Senya的。因为呢，在恋恋的想法里面，Senya是创造了整个世界的人，拥有很大的名义，也是N领域的创始人。因此这个服务器取名为Senya，象征着一个新的开始。
Poker Face
- 地址：pokerface.yuzurisa.com
- 操作系统：Ubuntu 18.04.2
- 类型：云服务器
- 配置：1C 2G 40G 1M
恋恋的阿里云学生机，也是恋恋2018年收到的生日礼物。目前上面跑着Docker，里面有两个空的WordPress来应付检查的，还有几个SRVPro用于YGOCore战队联盟的比赛。
Poker Face（不是Lady Gaga的歌曲），是柚木梨沙唱的最好的一首歌，讲的是一个长得奇怪的孩子最后被遗弃，而从这个世界上消失的故事。说实话，听这首歌非常容易感动的流泪。可能恋恋的泪点比较低吧。
Yuzurisa
- 地址：yuzurisa-storage.mycard.moe
- 操作系统：Ubuntu 18.04.2
- 类型：物理服务器
- 配置： i7-8700K 32G 1.1T 50M
梨沙是那个被遗弃的孩子，最后消失在大家的视野里。（具体请见上面Poker Face的剧情）
Yuzurisa的前身是恋恋家里的台式工作机，后来因为恋恋经常在家和学校流动，因此没办法经常使用，所以恋恋把操作系统改装成了Ubuntu Server，申请了公网IP之后，正式当作服务器来用。Yuzurisa上面跑的业务大部分都是测试业务，极少有生产环境上线的。但是恋恋在家的时候管理Yuzurisa服务器就非常方便，直接内网操作即可。
中国电信最良心的地方就是，家里的宽带是提供443端口的，建站也不是问题。于是上面有一个https://virt.yuzurisa.com用来管理各个物理服务器的虚拟机的。但是，恋恋听说Sakura Frp的负责人家里的网拿来开Sakura Frp，结果带宽被电信封了这种事情，自己也有一点点慌。但愿这种事情不要降临在自己头上吧。
Yuzurisa的硬件资源的计算方法，和其他的物理服务器还不太一样。i7-8700K的CPU的主频非常高，一个核心相当于其他物理服务器的两个核心那么多。因此，恋恋也经常拿来跑密集计算的业务。
Lapis Lazuli
- 地址：lapis.momobako.com
- 操作系统：Ubuntu 18.04.2
- 类型：云服务器
- 配置：1C 2G 40G 1M
Lapis Lazuli是恋恋的华为云学生机。华为云的学生机比其他的云计算厂商便宜一些，只需要100一年。目前阶段上面还是空的，还没做规划以后要在上面跑什么，也可能拿来扫爆用。
Lapis Lazuli是一个专辑，里面的歌有些黑暗的感觉。不过，上面这个图，这个黑头发的人和黄头发的人到底是谁，恋恋现在还没有答案，还在调查中。
华为云有一个特别气的地方。华为云最开始推出了两种不同的学生机，100一年和200一年的。Lapis Lazuli就是100一年的那种。200一年的配置了一倍，2C4G，但是一直是缺货状态。于是恋恋等呀等，终于等到了补货。结果呢，噩耗来了。补货的云服务器是入门型的，类似于阿里云T5那种，CPU用太多会强制降速或者计费的。这个华为云，好抠门哦！
Ayane
- 地址：yuzurisa-storage.mycard.moe
- 操作系统：Ubuntu 18.04.2
- 类型：物理服务器
- 配置：E5-2670*2 128G 300G*5 50M
恋恋的想法里面，最最最开始，Senya和彩音是在一起的（现在和梨沙在一起），两人有说有笑的，过着幸福的生活。
Ayane服务器恋恋买的时候资金特别吃紧，买来之后，能花的钱只剩下几百，要吃一个月的饭，所以那个月非常艰难，能坚持过来已经是特别不容易的了。
Ayane服务器托管在一个公司的机房里面，不过基本上是恋恋自己的服务。此外，恋恋还拿来当跳板来访问公司的内网用。在恋恋的物理服务器里面，目前Ayane的资源是最空余的。因此，恋恋有新的业务的时候，都部署在Ayane服务器上面。虽然Yuzurisa服务器也可以部署，但是没这台那么稳定，而且只有12核CPU可以用，很珍贵。
对于Ayane服务器来说，目前缺一个导轨，装进机柜里面，非常尴尬。目前Ayane服务器还躺在桌子底下，勉强能放。不过呢，Ayane服务器是恋恋唯一一台从硬件到软件都是亲手安装的机架式服务器，从调iDRAC开始，到装系统，装软件环境，折腾了恋恋一晚上。但是还有一个坑恋恋没填好的，就是iDRAC的SSL的部署。racadm套件不支持Ubuntu 18操作系统，非常尴尬。用Docker来安装Ubuntu 16的容器，最后发现需要装驱动，恋恋怕把服务器搞坏，就没继续往下搞。
Realidea
- 地址：realidea.yuzurisa.com
- 操作系统：Debian 9.9
- 类型：云服务器
- 配置： 1C 2G 40G 1M
Realidea是柚木梨沙的一首歌，不过恋恋没太听懂里面在唱什么，大家可以听听看。
Realidea是恋恋的天翼云学生机，恋恋在Ayane服务器之后资金吃紧的月底，还有点钱，就买了这个云服务器来玩。
天翼云有一个很不好的地方就是，Ubuntu 18.04系统居然没有，CentOS也只有7.3版本的。恋恋需求一个高版本的Linux内核来开TCP BBR用。恋恋不想装Ubuntu 16.04然后do-release-upgrade，有一定概率把系统升坏。最后恋恋选择装Debian 9.0，然后正常apt upgrade到9.9来TCP BBR。不过恋恋安装Docker的时候就吃坑了，Debian并没有docker.io这个库，非常尴尬。最后恋恋找了一堆教程，说要安装一个新的源，才装好了Docker。
目前阶段，Realidea里面还是空的，等有需求再部署吧。
这些就是恋恋目前上线的服务器了，是不是有点可爱的感觉呢！
终于基本上做完啦~
2019-06-03WordPress部署真累，要一个一个页面调，累死人！不过幸运的是，不需要改太多代码，来适配HTTPS，上次部署Discuz恋恋就被恶心了一次。
Nanahira & Momobako使用的部署方式还是Docker，放在Koishi服务器上面的，和Taiko Web放在一个虚拟机里面的。总算不需要费大力气装LNMP，还一不小心装坏系统。
不过目前，恋恋对Nanahira & Momobako的规划还没太做好。目前先随便写写东西，听听歌，找找感觉。