所谓的vpn网关静态路由, 说白了就是给已经存在的隧道去添加一条固定的路径, 这样做的目的是为了使得指定的网段流量能够走向那个指定的网关, 而不需要通过动态的路由协议来进行什么协商工作。
在实际的运维工作当中, 这个活儿本身并不复杂, 但是实际踩到坑的情况还真的不是少数, 我曾经掉进去的坑, 如果都写出来的话, 完全可以凑够一整页纸的内容。
vpn网关静态路由怎么加
进入网关设备的路由配置模式, 然后编写一条指向对端tunnel接口的静态路由记录。在填写子网掩码时, 需要按照对端实际的网段信息进行设置。
此时, 下一跳地址应当填写对端隧道接口的IP, 这一点非常重要, 一定要避免填写物理接口的地址。举个例子来说, 如果对端的网段是192.168.2.0/24, 那么下一跳就应当写对端tunnel的IP。
我亲眼见过许多人, 直接把下一个跳跃点写成对面设备的物理接口IP地址。导致的结果就是Ping测试显示畅通无阻。可是真正的业务功能却无法正常运行。流量根本没有按照隧道的方式进行转发。
数据包被网关通过默认路由规则, 直接丢弃到了公网上面去。这种故障情况, 如果不使用抓包工具来分析问题细节。你就算是花费很长时间去排查。也很难查到具体到底是哪一部分出现了中断。
vpn网关静态路由生效吗
大家先把showiproute这个操作做完, 然后用眼睛仔细看清那条静态路由到底有没有出现在路由表里面去。很多设备明明配好了参数但是实际上没有生效, 这多半是因为tunnel接口的状态还是没有up起来哦, 或者是那些ACL规则把匹配的数据包给拦住了不让通过。
还有一种可能存在的异常情况是优先级的数值设置得不对劲, 导致它直接被OSPF那个动态路由系统的优先级给覆盖过去了无法显现。
另外还有一个容易让人踩的坑是, 静态路由本身就是单向的设置, 所以在对端的网关位置上, 也必须要把回程用的相关路由给加上才行。要是只在一边做了配置,那数据流量虽然在出发的时候能顺利送出去, 但是在回来的时候却找不到路回不来, 这就导致最终的业务还是没法正常运行。
在完成配置之后, 不要仅仅去单独测试某一方向上的通信链路, 而是要让两端设备同时运行满负荷的业务流量进行观察, 在这个过程中需要仔细地去查看是否出现了数据包丢包以及延迟增加的现象, 因为双向对称性这个因素才是真正容易导致整个网络出现故障并出现意外情况的地方。