源/目的检查开启导致虚拟IP背后的LVS无法正常访问

情况描述

近期发现48网段主机无法访问8.83这个VIP(虚拟IP),环境是 8.83 绑定了两个LVS实例,然后LVS实例转发到后端的nginx 静态资源;整个流程是,客户端发起对VIP的请求,LVS将请求转发到后端实例,后端实例直接返回给客户端。

处理步骤

1、同网段端口不通,考虑是否有主机层面防火墙,检查是没有的

2、nmap扫描VIP的端口,发现22、111正常,80/443拦截,考虑是否安全组限制,检查发现并没有限制

复制代码
Starting Nmap 6.40 ( http://nmap.org ) at 2024-04-26 10:09 CST
Nmap scan report for 1.1.8.83
Host is up (0.00018s latency).
Not shown: 996 closed ports
PORT    STATE    SERVICE
22/tcp  open     ssh
80/tcp  filtered http
111/tcp open     rpcbind
443/tcp filtered https
MAC Address: XX:XX:XX:XX:XX:XX (Unknown)

3、考虑后端端口是否正常,尝试客户端直接访问后端端口,发现正常可访问

此时,直接访问VIP端口,也能访问了,这个就暂时无法理解(过了一阵子又发生了这个情况)

4、抓包(对比没有访问过后端实例的请求与被拦截的请求),因为已经可以访问了,看不出来

5、突然想起来,云网卡上有个源目的检测,发现后端服务器云网卡有开启这个开关,关闭后不再拦截

总结

这个情况属实是没想到,默认开启的开关一时半会也没关联到这方面,凑巧解决的,应该是过了LVS,后端云网卡认为源端应该是LVS而不是客户机,然后发送报文被拦截了,也可能是其他原因

看来问题不光出现在视野范围内啊;

补充说明

以下内容是摘抄云网卡上对源目的检测的说明:

为安全起见,默认情况下"源/目的检查"的状态为"ON",系统会检查弹性云服务器发送的报文中源IP地址是否正确,如果不正确,则不允许发送该报文。通过该功能,有助于防止伪装报文攻击,提升安全性。

以下两种场景,您需要通过设置"源/目的检查"状态为"OFF",禁用该功能,以保证报文正常转发:

  1. 在SNAT场景下,配置SNAT的弹性云服务器起转发作用,这种保护机制会导致报文的发送者无法接收到返回的报文。

  2. 在虚拟IP场景下,绑定虚拟IP的弹性云服务器,绑定的网卡需要发送源IP为虚拟IP的报文。

相关推荐
L0208243 分钟前
Kubernetes Ingress|CNI 网络模型|Calico 网络策略|Pod 调度器完整实战教程
运维·网络·云原生·容器·kubernetes
启博网络10 分钟前
下一代防火墙是什么意思?下一代防火墙可以抵御哪些网络攻击?
网络·防火墙
FPGA信号处理1 小时前
【人工神经网络】第一讲:竞争网络与自组织特征映射:从胜者为王到保序映射
网络
吴声子夜歌2 小时前
Kubernetes权威指南——Kubernetes安装配置指南(网络配置)
网络·容器·kubernetes
硅基造物主2 小时前
STM32 从 0 到 1 做智能家居(十二):USART2 分时复用 —— ESP-12F + MQTT
网络·stm32·mqtt·智能家居·esp-12f
我不会起名字3222 小时前
TCP 三次握手为什么是三次:丢包、重传与初始序列号
网络·tcp·原理·握手
Yang96112 小时前
鼎讯信通DXA-3S光纤熔接机:光缆教学中的技术精粹解析
网络
xbzb3 小时前
IP、掩码、网关、DNS 到底谁管什么?网络基础与七种设备一次讲清
网络·网关·mac·ip·dns·掩码
前进吧-程序员4 小时前
C++20 协程入门实战:从 co_await 到一个 100 行的异步任务调度器
网络·c++·c++20
前进吧-程序员4 小时前
实战:C++20 协程 + io_uring 写一个 400 行的 echo server
网络·c++·c++20