为多IP主机上的出站连接指定IP地址


15

我的一台服务器(Debian 5.0.6)在同一接口上有两个公用ip地址。过去几个月一直可以正常工作,但是突然之间,它使用“错误的” ip地址进行传出连接。这是一个问题,因为反向查找将不匹配,因此电子邮件将获得垃圾邮件点。

eth0      Link encap:Ethernet  Hardware Adresse 00:1b:21:14:8e:9c  
          inet Adresse:81.169.180.51  Bcast:81.169.180.51  Maske:255.255.255.255
          inet6-Adresse: fe80::21b:21ff:fe14:8e9c/64 Gültigkeitsbereich:Verbindung

eth0:0    Link encap:Ethernet  Hardware Adresse 00:1b:21:14:8e:9c  
          inet Adresse:85.214.157.120  Bcast:85.214.157.120  Maske:255.255.255.255


Kernel-IP-Routentabelle
Destination     Router          Genmask         Flags Metric Ref    Use Iface
81.169.180.1    0.0.0.0         255.255.255.255 UH    0      0        0 eth0
0.0.0.0         81.169.180.1    0.0.0.0         UG    0      0        0 eth0

当前,它使用85.214.157.120进行出站连接。如何使用81.169.180.51?

编辑:255.255.255.255的网络掩码与托管公司的文档和DHCP响应均一致。多次调用/etc/init.d/networking重新启动将最终以正确的IP地址结束输出连接。但这显然不是一个稳定的解决方案。/编辑

编辑2:为确保主机路由与我的问题无关,我设置了本地测试网络:

eth0      inet Adresse:192.168.0.2  Bcast:192.168.0.255  Maske:255.255.255.0
eth0:0    inet Adresse:192.168.0.3  Bcast:192.168.0.255  Maske:255.255.255.0

192.168.0.0    0.0.0.0         255.255.255.0   U     0      0        0 eth0
0.0.0.0        192.168.0.1     0.0.0.0         UG    0      0        0 eth0

如果有人对如何确保在出站tcp连接上使用源IP地址192.168.0.2表示感谢,我将不胜感激。 /编辑2

Answers:


24

更新默认值:

ip route change default via 81.169.180.1 src 81.169.180.51

检查配置:

ip route list

1
重新启动后如何使其永久化?
德智

3

bindbn的答案很好,但是我发现了一些麻烦。

1)您应该按照bindbn的说明检查“ ip route list”。列表中的其他规则可能会优先于默认路由。您可能需要删除该规则,或创建稍有不同的规则。

2)通过ip命令完成的所有更改仅在下次重启之前有效。永久添加源策略路由规则的答案说明了如何使其持久化。

总之,您可以将需要作为“ up”或“ post-up”行运行的ip route命令添加到/ etc / network / interfaces。您可以添加相应的“向下”行以删除路线。


1

尝试改变

 allow-hotplug eth0

 auto eth0

那应该迫使您的物理接口首先出现。您可能也可能不需要更改eth0:0的allow-hotplug条目。


1

出于好奇,为什么您的IP地址的网络掩码为255.255.255.255?这实际上是不可行的,因为这将意味着整个地址就是网络。主机没有空间。您的广播地址与主机IP相同的事实也令人担忧,但这很可能是由于网络掩码问题造成的。看起来您的网络掩码应该是255.255.255.0。

这样做是为了在同一子网中为您提供两个主机吗?最好只进行更改,以使每个接口都位于不同的子网中。255.255.255.128会将eth0和您的网关(81.169.180.1)放在同一子网中,而eth0:0放在单独的子网中。但是,这意味着eth0只能与81.169.180.1-81.169.180.127通信。eth0:0从129-254开始。话虽这么说,我真的看不出为什么您当前的设置可以工作。

现在,这是否会引起您在上面看到的问题?我看不到直接链接,但是有可能。
我肯定会调整它。如果那没有帮助,也许您可​​以解释为什么以这种方式进行设置。


编辑:这在此主机上工作正常,还是在其他计算机/操作系统上?知道可能会发生什么变化吗?我问的原因是因为Linux确实不喜欢在同一子网中有两个接口。令我发疯的是试图在我自己的网络上运行它。听起来很可能您已经在正确的IP上工作了,直到重新启动/重新启动网络服务为止。然后它使用了错误的接口。参考:http : //anders.com/cms/258

您也可以尝试ifdowneth0:0,然后添加路由,然后将ifup其返回。这样可以保证使用正确的IP。

手动添加dev eth0 可能会有所帮助,但似乎路由已正确完成。


进一步的编辑: 您可以尝试在Debian中使用最新的IP管理工具iproute 2。(辅助链接)看起来像是在
弹出界面一样: ip link set eth0 up

ip addr add 192.168.0.2/24 dev ethe0
ip addr add 192.168.0.3/24 dev eth0

然后使用
ip route add 10.0.0.0/16 via 192.168.0.2


--Christopher Karel 设置路由表


255.255.255.255的网络掩码与托管公司的文档和DHCP响应均一致。根据Google的说法,点对点网络上通常有255.255.255.255。据我所知,考虑到在同一第2层广播域中拥有不受信任的主机的安全风险,托管公司使用无点对点网络将是相当愚蠢的。
亨德里克·布鲁默曼

就像沃尔夫冈斯(Wolfgangsz)在上面说的那样,/ 32不是点对点链接的标准。我知道/ 31可以完成,但显然会破坏广播和网络标识符。您看到的“主机路由”是指它在路由表中的使用。例如:这是到特定主机而不是网络的路由。因此,它出现在您在OSPF(路由协议)上链接的RFC中。话虽这么说,如果您确定ISP指示您使用OS进行操作,那么最好也保持它。
Christopher Karel 2010年

好,进行了一些编辑,可能会对您的原始问题有所帮助。
Christopher Karel 2010年

-1

您当前的设置实际上根本不起作用。由于两个接口的网络掩码均为255.255.255.255,因此网关没有空间。但是,为了传递任何有意义的流量,您的服务器需要一个网关。提供两个公共IP地址的ISP还应该为您提供两个IP地址的网络掩码和网关设置。

示例(这是我的专用服务器,并且IP地址是真实的):

内核IP路由表
目标网关Genmask标志度量标准引用使用Iface
217.10.144.208 0.0.0.0 255.255.255.248 U 0 0 0 eth0
0.0.0.0 217.10.144.209 0.0.0.0 UG 0 0 0 eth0

服务器本身位于217.10.144.210上,该地址与网关位于同一子网中(必须访问该子网,否则无法路由任何流量)。大概ISP也为其他一些客户提供了相同的子网。

如果您在该服务器上并且对网关执行ping操作,则应该收到“没有通往主机的路由”消息。

与ISP交谈并获得正确的设置,然后更新您的接口配置,重新启动网络并再次检查。


2
255.255.255.255的网络掩码与托管公司的文档和DHCP响应均一致。根据Google的说法,点对点网络上通常有255.255.255.255。据我所知,考虑到在同一第2层广播域中拥有不受信任的主机的安全风险,托管公司使用无点对点网络将是相当愚蠢的。
亨德里克·布鲁默曼

如果您具有点对点网络,则您的网络掩码将为255.255.255.252。这将允许组成两个端点的两个主机,即网络地址和广播地址。对于这种连接,这是正常情况。在您的情况下,另一台主机将成为您通往世界其他地方的门户。我真的不在乎您在Google上挖掘了什么,但这就是TCP / IP网络的工作方式。很显然,它对您不起作用。我把结论留给你。
wolfgangsz

谢谢,但是这部分对我来说很好。顺便说一句,它在官方Internet标准中被称为“主机路由”:rfc-editor.org/rfc/rfc2328.txt
Hendrik Brummermann 2010年

我的问题也可以在本地网络上重现:ifconfig eth0 192.168.0.2掩码255.255.255.0 / ifconfig eth0:1 192.168.0.3掩码255.255.255.0 /路由添加默认gw 192.168.0.1
Hendrik Brummermann 2010年
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.