Alibaba Cloud Anycast EIP is worse than its origin EIP

I created an Alibaba Cloud Anycast EIP to see how big of an improvement it can have compared to my Singapore EIP. It is impressive to see how it has a negative impact on the global latency department.

* Test result only applies to today at this moment. Origin server (SLB) in Singapore.

Anycast EIP

Using their own benchmark method from Tokyo server: (https://www.alibabacloud.com/help/doc-detail/171864.htm#title-mk4-1or-ni4)

# curl -o /dev/null -s -w "time_connect: %{time_connect}\ntime_starttransfer: %{time_starttransfer}\ntime_total: %{time_total}\n" "Anycast EIP"
time_connect: 0.081
time_starttransfer: 0.167
time_total: 0.167

Normal Singapore EIP

# curl -o /dev/null -s -w "time_connect: %{time_connect}\ntime_starttransfer: %{time_starttransfer}\ntime_total: %{time_total}\n" "Singapore EIP"
time_connect: 0.076
time_starttransfer: 0.152
time_total: 0.153

Utilize iptables to monitor traffic (by port|ip)

# iptables -A INPUT -s 10.0.0.1
# iptables -A OUTPUT -d 10.0.0.1
# iptables -vnL
Chain INPUT (policy ACCEPT 7967 packets, 4273K bytes)
 pkts bytes target     prot opt in     out     source               destination
16572 4535K            all  --  *      *       10.0.0.1             0.0.0.0/0
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
Chain OUTPUT (policy ACCEPT 8562 packets, 6767K bytes)
 pkts bytes target     prot opt in     out     source               destination
 2823 2974K            all  --  *      *       0.0.0.0/0            10.0.0.1
# iptables -A INPUT -p tcp --dport 12000
# iptables -A OUTPUT -p tcp --sport 12000
# iptables -vnL
Chain INPUT (policy ACCEPT 9806 packets, 5038K bytes)
 pkts bytes target     prot opt in     out     source               destination
 669K  184M            all  --  *      *       10.0.0.1             0.0.0.0/0
   50  3640            tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:12000
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
Chain OUTPUT (policy ACCEPT 10285 packets, 7196K bytes)
 pkts bytes target     prot opt in     out     source               destination
 665K  687M            all  --  *      *       0.0.0.0/0            10.0.0.1
   10  1288            tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp spt:12000

按照 iptables 的規則語法即可自由組合。需要特定時間的紀錄,用 crontab 導出 iptables -vnL 內容,iptables -D 刪除紀錄,再重新添加即可。

Utilize crontab to run ssh command in tmux

0 22 * * * /usr/bin/tmux new -d && /usr/bin/tmux send-keys -t 0 “vnstat -l” ENTER
0 23 * * * /usr/bin/tmux send-keys -t 0 C-c

Just for reference, please verify if the command fits your needs. Such as, if there are old tmux sessions in place, the new session number won’t be 0, you might want to specify session name with -s.

Enabling DHE cipher on nginx (for IE 11 compatibility)

# generated 2020-10-27, Mozilla Guideline v5.6, nginx 1.17.7, OpenSSL 1.0.2k, intermediate configuration, no HSTS, no OCSP
# https://ssl-config.mozilla.org/#server=nginx&version=1.17.7&config=intermediate&openssl=1.0.2k&hsts=false&ocsp=false&guideline=5.6

ssl_dhparam /path/to/dhparam;

# intermediate configuration
ssl_protocols TLSv1.2;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;
ssl_prefer_server_ciphers off;
}

To add support on IE 11 on Windows 7 / 8.1, add the following ciphers to the ssl_ciphers list.

ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384

Realize that dhparam is a must for nginx to enable DHE Cipher, oopsie…

Foward traffic (filter by source ip and dst port) to other public ip

Check it on Gist: https://gist.github.com/richardevs/355d24b25f6c19b698b7134504843dc6

# run all these on the bastion vm
# iptables can not directly route traffic to public ip ( in my test )
# so I insert a socat here to help get the job done

iptables -t nat -F # flush all the current NAT rule ( be careful )
iptables -t nat -A PREROUTING -s 1.1.1.1 -p tcp --dport 443 -j DNAT --to-destination :4433 # all traffic to port 443 from 1.1.1.1 get routed to port 4433
iptables -t nat -A POSTROUTING -j MASQUERADE # let iptables do the NAT work
iptables -t nat -nL # double check if iptables are correctly showing the rules

nohup socat TCP4-LISTEN:4433,reuseaddr,fork TCP4:2.2.2.2:443 & # use socat to forward traffic to final destination, in the demo here, 2.2.2.2:443

【GPG Key Rotation Notice】

– 330CDE83C3337CEADA44CE70BB180B9415CDC81B 已停止使用並遞交 Revoke
– Superseeded by 8C095E600D83C696586E0BAAF41C815ACDD22938
– 新舊 Key 之間存在相互簽名
– Keybase 情報已同步更新
– 新 Key 主要使用 SubKey 進行簽名,SubKey 四年有效期,MasterKey 永久有效

– 330CDE83C3337CEADA44CE70BB180B9415CDC81B has ceased operation and revoked
– Superseeded by 8C095E600D83C696586E0BAAF41C815ACDD22938
– They are cross-signed
– Keybase has all the updated information
– Future operations will mainly be using the SubKey with 4-year validity, while MasterKey never expires