@lilifenghao44

QQ 上搜 Siril ，（注意大写首字母）， 应该只有 1 个结果，
头顶个面具的就是我。

本人现在是某小公司打杂的 网管 /技术支持， 常有空闲时间。

@lilifenghao44

避免 vps 中转所有流量， 还要穿透 nat ， 则 vpn 貌似只能用 udp ， tcp 的不行；
udp 在许多地方的 ISP 有明显的限速， 你试过就知道了；

可以试试 n2n 或 tinc 。

@lilifenghao44

提到 ip_forwarding ， 你检查下这个，是不是相关。



另外， 标准的 vnc 是无加密的，不建议搞成公网可访问。

@lilifenghao44

vps 上一个 vpn ，内网 linux 上一个 vpn ， 其他设备就不需要了。
分别作 DNAT + SNAT ， 可以转发任意内网 linux 可访问的 tcp/udp 端口 从 vps 访问， 很灵活。

只是。。。 你明显没有公司出口路由器(或防火墙)的控制权限， 如此这般在防火墙上开洞， 也不太合适吧。


给例子：
vps IP 1.2.3.4 ， 隧道接口的 ip 192.168.1.1
内网 linux 的 隧道接口 192.168.1.2 ， 内网接口 192.168.2.2.
目的为从外网 ssh 到 192.168.2.3:22 ， 可以这样：
vps 上打开 ip forwarding ，然后
iptables -t nat -A PREROUTING -d 1.2.3.4 -p tcp --dport 2222 -j DNAT --to-destination 192.168.1.2:1001
iptables -t nat -A POSTROUTING -d 192.168.1.2 -p tcp --dport 1001 -j SNAT --to-source 192.168.1.1
内网 linux 上也打开 ip forwarding ， 然后
iptables -t nat -A PREROUTING -d 192.168.1.2 -p tcp --dport 1001 -j DNAT --to-destination 192.168.2.3:22
iptables -t nat -A POSTROUTING -d 192.168.2.3 -p tcp --dport 22 -j SNAT --to-source 192.168.2.2

然后 ssh 到 1.2.3.4:2222 等同于 192.168.2.3:22

个人认为比较简单易配置的有 openvpn 、 n2n 、 tinc ， 当然 pptp 、 ipsec 之类也可。

在内网机和 vps 上弄个 n2n / tinc / openvpn 呗。

我弄错了， 貌似你是用的 ssh 反向连接。

先在 vps 上看下监听的地址。

感觉你描述不清。。。

是不是这种场景：

例如 vps 的 ip 1.2.3.4 ， 公司 出口路由器 公网 ip 2.3.4.5 ， 公司出口路由器上做好了映射。

然而出于跨 ISP 速度蛋疼之类的原因，由 VPS 转发：
例如 vps 的 2222 转发到公司的 22:
iptables -t nat -A PREROUTING -d 1.2.3.4 -p tcp --dport 2222 -j DNAT --to-destination 2.3.4.5:22
iptables -t nat -A POSTROUTING -d 2.3.4.5 -p tcp --dport 22 -j SNAT --to-source 1.2.3.4

如此这般，就等价于微林了。

插到 2.0 的口上用。


另外，装几台啊？ 试试网络启动安装？

楼上说的对。


这一点非常之烦， 比如说 你有时需要使用 vpn 服务 A ，有时需要使用 vpn 服务 B 。

A 不支持加密， B 支持加密（实为禁止不加密）。

那么每次断开 A 连接 B ，或者断开 B 连接 A 的时候都要改注册表然后重启。

如果 A 和 B 原本完全隔离，网段重叠并且不能改，那么需要做个 nat

否则，按简单的情况，举例：
A 网络 192.168.1.0/24 ， B 网络 192.168.2.0/24
路由器 a 的内网口 192.168.1.1 ，路由器 b 的内网口 192.168.2.1

此时明显需要一台具备路由功能的设备，此设备
接 A 的端口 192.168.1.2 ， 接 B 的端口 192.168.2.2 ，不设默认网关。

然后
a 路由器上加静态路由 192.168.2.0/24 via 192.168.1.2 ，
b 路由器上加静态路由 192.168.1.0/24 via 192.168.2.2 。
若路由器上不能加（家用 tplink 之类的吧？），那就在服务器和 pc 上加。

由于此新路由器（或三层交换机）并无默认网关，
所以无须检查两个路由器的 nat 功能。


感觉我真 tmd 闲。。。

vlan 不顶用，

1.
你需要 1 台路由器~ 或三层交换机~
或者现有路由器（无论两个中的哪个），
有个空闲端口（或者可以做 vlan 子接口）接到另一网络；

2.
然后，在另一网络的路由器上加静态路由指过来，
或者在另一网络需要操作的服务器上加静态路由。

这样一来，在 “另一网络” 上存在两个路由器，可能可以选择哪个作为出口。
若“另一网络”为 B ， 则无须担心从 A 网络使用 B 的出口。

----------------------------------
至于从 A 网络使用 B 网络的出口，或者从 B 网络使用 A 网络的出口，
一般来说是在两个路由器的 nat 功能上限制掉，
比如*避免*使用 permit ip any 这种就好。

------------------------------------------------------------
实际的路由器可能功能比较简单，
是否能添加静态路由、
nat 功能具体允许如何设置，默认行为如何，

请自行测试。

装系统时断电了，上面没数据吧。

瞅一眼 smart 数据 ， 然后返修

0. smartctl 之， 确认一下磁盘健康状况。

1. 准备一块容量不低于此盘的新盘，用 dd_rescue 倒腾全盘数据过去；
dd_rescue 可以自动跳过坏扇区。
2. 在倒腾出来的磁盘上，尝试修复分区表、修复分区，恢复数据。
3. 返修坏硬盘。若磁盘已无保修，拆盘片玩。


有坏扇区的硬盘就别用了，即使坏的不是 0 扇区，可以把损坏区域分出来不用。


曾经遇到类似难题：
需要一块坏硬盘上的数据，却又不值得使用专业数据恢复服务。
曾经尝试进 pe 用 ghost 、 winhex 弄镜像，然而 windows 一插上坏盘就直接卡死，
包括 pe ，而且无论是不是热插拔。

dd_rescue 大法好。

如果是 windows ，有时诡异的情况出现就是 nslookup 测试正常， 用浏览器打开新网站，却没有发出 dns 请求。
此时重启 dnscache 服务、清 dns 缓存、再关闭并重新打开浏览器。

@wuyanteng2016

肯定能查到原因的。
iphone 上也有 nslookup 、 ping 等工具，你自己找一下，记得有免费的。


先检查 dnsmasq 监听的端口，应有 0.0.0.0:53 。 netstat -anpl | grep :53
linux 系统有无 firewalld 之类的。 iptables-save
路由对不对（从 wifi 网络 ping 通 dns 服务器）。

1. 在 dns 服务器上 tcpdump -i 对应端口 -nn udp and port 53 and src 笔记本的 IP
在笔记本上 nslookup google.com 10.0.100.10
观察 dns 服务器是否收到查询请求，是否回应。
在笔记本上装 wireshark 或 microsoft network monitor 之类抓包观察。

2. 打开 dnsmasq 的日志。 dnsmasq.conf 中（临时）添加
log-queries
log-facility=/var/log/dnsmasq.log
（调试完毕记得来此注释掉并重启 dnsmasq 并删除此文件，
否则文件尺寸飞速增长至几十 G ）
然后 systemctl restart dnsmasq ，（一般新的 linux 发行版都这样吧）
在笔记本上 nslookup 测试， tail 此日志文件观察。

思路就是检查
dns 服务器有没有收到查询请求，
有没有转发给上游 dns 服务器并得到结果（看日志），
以及结果是否返回给 windows ，

然后可知问题出在 dns 服务器还是 ROS 。

我认为楼主问的不是在哪个接口上监听端口，那不难吧。

而是一个更纠结的问题： reverse path filter.
也可能是另一个纠结的问题：策略路由。

如果 eth0 、 eth1 、 eth2 上的 ip ，从客户端都能路由过来，
而且 3 个接口无论从哪个接口的网关（如果有的话） 出去都能路由到客户端，

那么在 linux 机器上关了 rpf 就行。。。几行 sysctl 的事儿。。。 无所谓客户端连接这 3 个 ip 中的哪个。。。


举个栗子：
三层交换机上弄 4 个 vlan ，
vlan1 192.168.1.1 ，
vlan2 192.168.2.1 ，
vlan3 192.168.3.1 ，
vlan4 192.168.4.1 。
此 linux 服务器的
eth0 接 vlan1 ， ip 192.168.1.2/24 ，
eth1 接 vlan2 ， ip 192.168.2.2/24 ，
eth3 接 vlan3 ， ip 192.168.3.2/24 。

需要从 客户端 192.168.4.123 上访问到 192.168.1.2:8000 ， 192.168.2.2:8001 ， 192.168.3.2:8002 。

如果 linux 服务器默认启用 rpf ，则只有 linux 服务器的默认网关在哪个接口上，对应的服务才能访问到。 对于另外两个 ip ，数据包进来的端口和出去的不是同一个端口，所以被 rpf 过滤掉而不通。


或者另一种情况：
linux 服务器上弄策略路由，根据源 ip 源端口 指定路由。 这个我没试过，楼下补充。

推测： 延迟对吞吐量产生影响。


假设从楼主到香港，从香港到美国的测速都大于 “ 2000-4000Kbits ”。


再假设楼主使用普通电信 /联通网络，连接香港路由会绕道美国，那么比如说：
楼主 ping 美国至少 200ms ；
楼主 ping 香港至少 300ms ；
香港 ping 美国至少 100ms 。


则 SS 建立 tcp 连接，实际延迟至少 400ms （楼主到香港的延迟+香港到美国的延迟+iptables 转发的延迟）。
[据说] 只要 linux 主机负载不高， iptables 的延迟可以忽略。



对于 tcp 来说，延迟和丢包的增加，都会导致吞吐量剧减，适当优化窗口大小之类的可以缓解此情形。



奇怪的是， 香港也无墙吧， 有必要多倒腾一次么。

@helihuo 测试有一定效果。


另外， archlinux 上的 dnscrypt-proxy 的服务文件里可以选择上游服务器。
pacman -Ql dnscrypt-proxy ，发现：
/usr/share/dnscrypt-proxy/dnscrypt-resolvers.csv 里面有一大堆，
然而
/usr/lib/systemd/system/dnscrypt-proxy.service 里默认使用
-R dnscrypt.eu-nl （位于欧洲）
好坑。。。
将其改为香港或美国的， 解析速度大为改观。

cp /usr/lib/systemd/system/dnscrypt-proxy.socket /usr/lib/systemd/system/dnscrypt-proxy-viaUS.socket
cp /usr/lib/systemd/system/dnscrypt-proxy.service /usr/lib/systemd/system/dnscrypt-proxy-viaUS.service
并修改 dnscrypt-proxy-viaUS.socket 中监听的端口，和
dnscrypt-proxy-viaUS.service 的描述、 Requires=、 Also=、使用的上游服务器、添加 --tcp-only

systemctl daemon-reload
systemctl enable dnscrypt-proxy-viaUS
systemctl start dnscrypt-proxy-viaUS
systemctl restart dnscrypt-proxy

然后 dnsmasq 里面同时用这两个解析， 顿时稳定多了。