这是一个创建于 3290 天前的主题，其中的信息可能已经有所发展或是发生改变。
一台在Internet上（A），另一台在NAT防火墙后面（B），求助：
1、搭l2tp隧道的正确姿势
2、搭fou隧道的正确姿势
具体地说，B的local要填公网ip还是内网ip，A的remote要填什么。。
我抓包啥都抓不到估计是ip填得不对吧TvT
求大神指导orz 感激不尽！
第 1 条附言 · 2015-04-30 15:47:37 +08:00
ip fou、ip link 已get√
现在主要问题是服务端怎么配nat QAQ
现在主要问题是服务端怎么配nat QAQ
 |
1
liwei 2015-04-30 12:13:29 +08:00
说实话iproute的命令行接口设计的实在是不好，我就没记得一次我能够不查help正确的把命令写出来的，再加上错误信息提示也是莫名其妙，用起来经常要去看代码。
|
 |
2
kiritoalex 2015-04-30 13:15:49 +08:00 via Android
所以解决楼上问题的办法就是用Gentoo把配置写到文件里而不是用命令
|
 |
3
efi 2015-04-30 13:23:57 +08:00
google naive-vpn.md
|
|
5
efi 2015-04-30 13:51:44 +08:00
为什么没有成功 怎么失败了
|
 |
6
jxwzhx OP @efi 两边配好之后ping不通啊。。抓包一看啥都没有 隧道完全没生效。。client的local是填局域网ip么？
|
|
7
efi 2015-04-30 14:07:14 +08:00
iproute2是模仿思科的，ip的语法已经很好了，tc的语法才叫难。
一共就几个IP，多试试总能试出来。 ip -s link dev l2tpeth0或者iptables -L -nv可以看有多少流量在走。 |
 |
8
KCheshireCat 2015-04-30 14:25:15 +08:00
Naive-VPN.md 做启发思路是不错的，告诉你有这个方法，做一个引导性的文章还是不行。
CLIENT_IP确实填的是本机的内网IP，但只有这个应该是没法工作的，应该是要配合本地网关的SNAT 文中提到cookie其实是无所谓的，因为是静态所以没用，不设置还能缩小报头 文中mtu完全没有计算过，或者说连ping一下都没做，如果本地是pppoe接入mtu应该设置1430，不设置cookie还能+8 netfilter的链接跟踪产生的3分钟问题也没有很好解决。 sysctl -w net.netfilter.nf_conntrack_udp_timeout_stream=10 sysctl -w net.netfilter.nf_conntrack_udp_timeout=10 个人是修改这两项来回避3分钟，是不是有效还是没有验证 |
|
9
efi 2015-04-30 14:33:11 +08:00
@KCheshireCat
NAT是服务端做的，中间不需要配置 cookie是防DoS的 新建interface有pmtu discovery，不需要手动 conntrack的状态是一个feature，让服务端保留客户端地址 |
|
10
efi 2015-04-30 14:34:32 +08:00
我珍藏的一个书签，帮助理解如何正确使用tc：
http://www.coverfire.com/articles/queueing-in-the-linux-network-stack/ |
|
11
KCheshireCat 2015-04-30 14:52:21 +08:00
@efi
服务端做隧道内的包的NAT，本地做隧道外的包的NAT 本地SNAT是将服务端发回来的隧道包的目标地址恢复为本机内网IP 隧道是检验IP和端口的，不正确就会丢弃 静态隧道cookie不会变，真的有需要就再套一层IPsec隧道 pmtu discovery我并不了解所以针对原文提了一个合理的mtu 3分钟问题是ISP的NAT是黑箱，公网IP什么时候会变，源端口会不会被强行修改都是不确定的 我经常遇到突然无法ping通隧道的情况 有时iptables上有包记录，有时没有 所以再找解决方法 |
|
12
efi 2015-04-30 15:05:33 +08:00
@KCheshireCat
总之有很多NAT啦 l2tp cookie是在IPsec下层的，IPsec无法给l2tp提供authentication；或者把l2tp放在IPsec里面的话，IPsec本身没法穿越NAT，IPsec的udpencap需要用户来协调。 如果公网IP变的很快的话，嗯。端口映射保存时间太短是一个安全问题，和性能问题。现在靠的是抢占排他3分钟来防止安全问题。可以用iptables m32检查l2tp cookie去验证端口映射是你发起的，这个是可以的。 |
|
13
jxwzhx OP @efi @KCheshireCat 我刚才试了下，通过在服务端的INPUT链上做SNAT，服务端可以收到封装后的ping包，但是回复的时候发给了那个SNAT到的地址（文中的10.53.0.255）=。=
所以说应该怎么设置DNAT把地址转换回去（回到客户端的公网IP&PORT）呢？MASQUERADE好像可以两头换，但是只能设置在POSTROUTING链上TvT |
|
15
KCheshireCat 2015-05-01 00:25:41 +08:00
@efi
cat /proc/net/nf_conntrack ipv4 2 udp 17 14 src=111.140.44.160 dst=108.61.160.X sport=26518 dport=5120 [UNREPLIED] src=108.61.160.X dst=111.140.44.160 sport=5120 dport=26518 mark=0 zone=0 use=2 刚才隧道断了，然后我换了SESSION_ID和PORT重建了一下 一开始没有包到达，然后就发现有包到达重建之前隧道的端口，而且源端口是变动过的。 等nf_conntrack记录超时后，再ping隧道，服务端依旧收到老端口的包， 然后还有一个现象是我在iptables上做SNAT是u32的SESSION_ID匹配，收到老端口报的时候iptables没有匹配记录，说明SESSION_ID不是新的。 中间源IP和源端口还多次变化，但目标端口依旧是老的，iptables也匹配不到 甚至有一次还直接到达没有被NAT过 难道ISP的设备能够识别UDP的静态l2tpv3并且做了缓存？ 还是仅仅复制了一份包样本，重发做干扰？ ISP的NAT太奇怪了。。。 |
|
16
efi 2015-05-01 01:56:56 +08:00
@KCheshireCat
不知道为什么会重发。 隧道断了之后，新包的端口被映射到老端口，session也是老的，那么内容是不是也是老的？ 如果只是用了老端口，或者用了老session，可以看其他部分是不是新的。如果其他内容是新的，可以想办法把老包过滤掉。如果全是老的，就要看用nc -u其他端口同时测试是不是ISP在重发。 |
Select Language