Debian 9上的6in4隧道


0

我有一个分配了/ 64 IPv6地址块的VPS。我正在尝试从家里的pfSense路由器部署一个6in4隧道,并能够通过该隧道访问IPv6地址。

我成功地启动了网关,但是我无法ping通除了我的pfSense盒中的/ 64以外的任何其他IP。虽然从VPS Ping起作用。

这是我的/ etc / network / interfaces配置 -

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
    address 123.456.xxx.yyy
    netmask 24
    gateway 123.456.xxx.1
    dns-nameservers 8.8.8.8 8.8.4.4
iface eth0 inet6 static
    address aaaa:bbbb:my:ipv6::1
    netmask 48
    gateway aaaa:bbbb::1

auto tunnel0
iface tunnel0 inet6 v4tunnel
    address aaaa:bbbb:my:ipv6::9
    netmask 64
    endpoint 66.abc.def.20
    up ip -6 route add aaaa:bbbb:my:ipv6::/64 via aaaa:bbbb:my:ipv6::10
    pre-up iptables-restore < /etc/iptables/rules.v4
    pre-up ip6tables-restore < /etc/iptables/rules.v6

这是v4的iptables规则

iptables -I INPUT -p 41 -s 66.abc.def.20 -j ACCEPT

这是v6的ip6tables规则

ip6tables -I FORWARD -i tunnel0 -j ACCEPT
ip6tables -I FORWARD -o tunnel0 -j ACCEPT

我还在/etc/sysctl.conf中添加了以下行

net.ipv6.conf.all.forwarding=1
net.ipv6.conf.eth0.accept_ra=2

我的pfSense路由器上的隧道端点是aaaa:bbbb:my:ipv6 :: 10。


您的地址编辑使您无法理解您正在使用的子网划分方案。您是否尝试在两个接口上复制相同的前缀?为什么eth0配置为/ 48而不是/ 64?/ 64实际上是由提供商路由给您的,还是仅仅是一个链接范围?
grawity

@grawity - 当我部署VM时,使用netmask 48生成eth0 inet6配置,我没有打扰它。我的理解是,如果我的隧道端点与实际VM的IPv6子网在同一子网中,我将能够使用隧道从我的pfSense盒与VM的BGP邻居通信。此外,分配给VPS的/ 64是on-link我相信。
HotBreeze

不,在2或3个地方复制相同的子网绝对没有帮助路由...但是,你的主要问题是onlink分配。
grawity

我可以用任何方式使用on-link分配来建立这个隧道吗?我试图在Vultr上设置它,它提供BGP会话并且只进行链路上的分配。
HotBreeze

嗯,那些相当矛盾吗?如果您通过BGP通告自己的前缀,那么对等体将始终将其路由到您,因为这是BGP的全部要点。另一方面,如果您正在使用Vultr的地址空间,那么我不明白BGP是如何涉及的。
grawity

Answers:


0

根据我的理解,您的连接看起来像这样 - 子网1是Vultr的全局/ 48,子网3将是您自己的BGP声明的地址空间:

[Vultr router] ---subnet 1--- [Your VPS] ---subnet 2--- [pfSense] ---subnet 3--- <LAN>

首先,在所有三个子网上使用相同的/ 64前缀没有多大意义 - 当您这样做时,您只需向路由器提供相互矛盾的指令。

没有帮助的是这个前缀实际上没有路由到您的VPS; Vultr认为它只是on-link / 48的一个不可分割的部分。因此,当Vultr的路由器试图到达aaaa:bbbb:my:ipv6::10(您的pfSense)时,它不知道应该将数据包发送到您的VPS - 它认为该地址是在链路上并尝试使用ND(ARP)发现它。

有些黑客可以实现(例如ND / ARP代理),但你真的需要它吗?不,因为你有足够的自己的IP空间。

因此,而不是从你的BGP-标榜块/ 64(例如,如果你拥有2001:db8:12::/48,那么2001:db8:12:ffff::/64将是一个共同的选择),并配置作为隧道前缀。

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.