我希望这个问题属于这里并且您将能够帮助我（否则请将问题迁移给超级用户）。
背景和问题描述
我通过有线电视提供商连接到互联网。我的连接如下所示：Thomson 电缆调制解调器 <> Asus RT-N66U 路由器 <> 有线和无线客户端。每次我手动连接/重新连接调制解调器和路由器之间的电缆时，连接都会恢复。一段时间后（通常但并非总是 6 小时，而路由器在界面中报告的租用时间为 12 小时，而路由器在界面中报告的租用时间为 12 小时）连接状态仍为“已连接”，但路由器上的 WAN IP 为 0.0.0.0。因此，无法访问互联网，也无法从 WAN 访问我的家庭服务器。但我的 ISP 仍然声称调制解调器在 WAN 上完全可见，它可以正确获取 IP。每当我重新启动路由器（从其控制台或使用物理交换机）或断开然后重新连接调制解调器和路由器之间的连接时，一切都会恢复正常。LAN 始终运行正常。
顺便说一句，我认为这没什么大不了的，但是……不久前，我的 ISP 为我设置了双 NAT，但由于我需要一个公共 IP 来访问我的家庭服务器，所以我联系了他们，将其恢复到以前的状态。它工作得非常顺利，我的 DS 又可以从 WAN 访问了，无论是通过 IP:port 还是 DDNS:port。
以下是有关我的网络环境的一些详细信息：
调制解调器
- 它获得一个公共的、非静态的 IP（但是，它是半静态的，因此我几天、几周甚至几个月都会有一个 IP）。
- 它以桥接模式运行，所有端口完全透明。
- 我无法访问它的 Web 界面 - 它始终由 ISP 配置。
路由器
- 它是我的 LAN 中唯一的 DHCP 服务器，
- 调制解调器通过路由器的 vlan2 连接到路由器，而 vlan1 是我的 LAN，
- 我的路由器上有一个端口转发规则，允许访问 DS（Diskstation）的网络面板：两个自定义端口，即：666 和 999 被转发到 IP：192.168.1.3，一个用于 HTTP，另一个用于 HTTPS，另外，我还将 80 端口转发给了它。
- DS MAC 绑定到 IP:192.168.1.3，
- 没有 MAC 克隆 - 我的 ISP 拥有的 MAC 是路由器的原始 MAC，
- IPv6 已禁用
LAN 客户端是：
- 无线连接的计算机（MBA、Windows）、手机和平板电脑（iPhone、iPad、Windows Phone、Android Nexus 5），
- Synology Diskstation DS211j，运行其新软件 DSM v 5.0（配置为从路由器的 DHCP 自动获取 IP），
- 三星电视，
- 索尼 CMT-G2NiP 音响系统。
到目前为止我尝试过- 没有成功：
- 关闭所有设备，然后重新打开（包括断开电源线并长时间关闭的所有选项），
- 在调制解调器 IP 上设置 DMZ，
- 在 DS IP 上设置 DMZ，
- 在路由器的 WAN 上启用然后禁用 UPnP，
- 将路由器的 MTU 从 1500 调整为 1492，
- 将 DHCP 查询频率从激进改为正常，
- 禁用路由器的防火墙，
- 在 DS 上禁用 DDNS，
- 将路由器上的 DNS 更改为 Google 的 DNS（这里有一点很奇怪，当设置为自动获取时，主 DNS 地址也是 0.0.0.0，而辅助 DNS 地址正常），
- 将路由器设置恢复为出厂默认设置，
- 30-30-30 重置路由器，
- 为路由器刷入第三方修改的固件（Merlin 版本 374.40 - 当前已安装），
- 在故障转移模式下启用双 WAN - 认为路由器可能会在主 WAN 断开连接后尝试连接到第二个 WAN，但由于没有这样的 WAN，它将在主 WAN 上重新建立连接，
- 切换设备连接到调制解调器和路由器上的物理端口。
我认为一些日志条目可能在这里发挥作用：
- 4 月 6 日 17:05:47 dhcp 客户端：在 43200 秒内通过 109.173.192.1 绑定 0.0.0.0。
- 4月6日 18:47:28 kernel: eth1: 收到以自身地址作为源地址的数据包
我认为其他一些设置可能与此有共同之处：
- WAN 连接类型是自动 IP（我认为的意思是：DHCP）。
- WAN 上的 NAT 已启用，并且 UPnP 已禁用。
TCP 设置（可在 Merlin 版本中访问）：
- TCP 超时：已建立：1200
- TCP 超时：syn_sent：120
- TCP 超时：syn_recv：60
- TCP 超时：fin_wait：120
- TCP 超时：time_wait：120
- TCP 超时：关闭：10
- TCP 超时：close_wait：60
- TCP 超时：last_ack：30
- UDP 超时：保证：180
- UDP 超时：未回复：30
WAN NAT 直通规则：
- PPTP 直通：已启用
- L2TP 直通：已启用
- IPSec 直通：已启用
- RTSP 直通：已启用
- H.323 直通：已启用
- SIP 直通：已启用
- 启用 PPPoE 中继：已禁用
有人知道如何摆脱这种困境吗？
（如果需要更多信息，请在评论中指出，我会更新问题文本。）
答案1
这是你的问题：
- 4月6日 18:47:28 kernel: eth1: 收到以自身地址作为源地址的数据包
或者说，这是一份非常糟糕的报告，它比所有其他问题都重要。在这种情况下，您的连接在 6 小时后断开并不是一件不幸的事，而是一个奇迹，它甚至可以正常工作。（我怀疑它的 DHCP 服务器可能处于休眠状态，直到它从 ISP 的 DHCP 服务器接收到其 IP，这让我怀疑您的 VLAN 2 上有一个流氓服务器）
您的路由器的 DHCP 服务器似乎正在应答其自己的 DHCP 请求：在 1/2 DHCP 租约时间内，客户端将尝试续订其租约，这解释了 6 小时的中断。
我没有使用过您的特定路由器，因此我无法开出具体的补救措施，但看起来它的 DHCP 客户端与其 DHCP 服务器在同一个 VLAN 上运行，并应答它自己的请求；另一种可能性是链路级广播可能以某种方式跨越 VLAN。
上面的错误确实令人震惊。这种情况永远不应该发生。如果它不局限于 DHCP 数据包，当有问题的以太网帧被克隆并重新传输时，这种循环情况可能会使交换机瘫痪，最终使交换结构饱和。请注意，这不是 IP 级错误，而是 MAC/第 2 层错误。
我希望这有帮助...
答案2
参照“4 月 6 日 18:47:28 内核：eth1：收到以自身地址为源地址的数据包”，您附近是否有其他 WiFi 路由器/AP/中继器？是否具有相同的 SSID 和信道？
现在关于您的断线...我猜这是有线调制解调器和路由器之间的 DHCP 问题...检查 MAC 地址克隆，我的是空白的。如果那里有一个值，它可能不是路由器自己的 MAC 地址。或者，输入一些随机的东西。