经过之前的折腾，正常使用了几个月，现在客户那边又有了新政策，几乎所有的服务都只能通过内网访问，甚至包括git（甚至在内网通过http拉取git也需要加proxy）。
客户开发部门的建议是直接用客户机开发，但是客户机孱弱的性能和瞎眼的屏幕，我肯定是选择铤而走险。
最合规的方案
在我折腾的同时，也给了团队其他人一个合理合规的建议：
- 开启日常开发机上的ssh，将项目的repo作为一个Bare Git Repository
- 客户机上作为git client，同时追踪bitbucket和开发机上的git repository，手动或者脚本将两个remote同步成一致。
基础选择
直接选择了最方便的VM+OpenWRT的方案。客户机器通过wifi接入互联网，给OpenWRT VM分配双网卡
OpenWRT WAN <---> NAT Network <---> VPN Network
LAN <---> Bridge Ethernet <---> Mac
依然是用网线将开发机和客户机连接起来。这样就能直接使用客户机的网络了。
强力的安全软件及应对
（这一环节是推测，并无实质证据）
发现这样配置好之后，开发机和客户机的OpenWRT只能短暂通信几秒钟，就会被断开。将开发机（Mac），客户机宿主（Windows）VM（OpenWRT）设置成同一个内网之后。发现
| Window | OpenWRT | Mac | |
|---|---|---|---|
| Window | - | ✅ | ✅ |
| OpenWRT | ✅ | - | ❎ |
| Mac | ✅ | ❎ | - |
推测应该是安全软件在网卡底层直接判断了Dest，直接一刀切了，不让入站。
所以没有办法使用桥接的有线网卡了，所以我选择USB网卡，直接把USB挂载到VM里去。所以网络变成了：
OpenWRT WAN <---> NAT Network <---> VPN Network
LAN <---> USB Network Adapter <---> Mac
选择性的使用客户网络
实际上只需要内网IP走客户网络即可。让所有流量默认走原来的网络，特定网络走OpenWRT。有两种方案，一种是临时的路由表
sudo route -n add -net 100.X.Y.0/24 OpenWRT_IP
sudo route -n add -net 10.X.Y.0/24 OpenWRT_IP
sudo route -n add -net 10.X.Y.0/24 OpenWRT_IP
一种是给网卡设置路由表
sudo networksetup -setadditionalroutes "AX88179A(mac network adapter)" \
100.X.Y.0 255.255.255.0 OpenWRT_IP \
10.X.Y.0 255.255.255.0 OpenWRT_IP \
10.X.Y.0 255.255.255.0 OpenWRT_IP
DNS
利用一些软件，将DNS做一个分流，将内网的域名交给OpenWRT，同时也需要关闭OpenWRT上Dnsmasq的Rebind protection选项，允许其返回内网IP。