☰

사용자 지정 라우팅 테이블의 VPN 게이트웨이가 실패함

tag-icon • tag-icon iptables vpn routing linux-networking iproute2
사용자 지정 라우팅 테이블의 VPN 게이트웨이가 실패함

내 목표는 컨테이너가 여러 VPN 연결을 통해 로드 밸런싱을 수행하는 라우터로 작동하도록 구성하는 것입니다.

이를 위해 다음을 사용하여 시작 패킷을 확률적으로 표시합니다.

iptables -I PREROUTING -t mangle -j CONNMARK --restore-mark
iptables -A PREROUTING -t mangle -m statistic --mode random --probability .50 -j MARK --set-mark 200 -m mark --mark 0
iptables -A PREROUTING -t mangle -j MARK --set-mark 201 -m mark --mark 0
iptables -A POSTROUTING -t mangle -j CONNMARK --save-mark

두 개의 라우팅 테이블 중 하나를 선택합니다.

echo "200     tun0" >> /etc/iproute2/rt_tables
echo "201     tun1" >> /etc/iproute2/rt_tables 
ip rule add fwmark 200 table tun0
ip rule add fwmark 201 table tun1

라우팅 테이블이 올바르게 선택되었다고 생각합니다. VPN 게이트웨이 트래픽을 사용하도록 테이블 tun0/1 중 하나를 구성할 때 반환되지 않는 것 같기 때문입니다. A는 tcpdump트래픽 종료를 표시하지만 모든 명령이 실패합니다.

ip route add default 10.7.7.1 dev tun0 table tun0
ip route add default 10.7.7.1 dev tun1 table tun1

테이블 tun0/1이 사용하는 경우 VPN이 아닌 게이트웨이 10.10.10.1트래픽이 예상대로 작동합니다. 기본 테이블에서 기본 경로를 설정하여 VPN 게이트웨이 중에서 선택할 수도 있습니다.

ip route add default 10.7.7.1 dev tun0/1

따라서 문제는 기본 테이블이 아닌 사용자 정의 테이블 중 하나를 통해 VPN 게이트웨이를 선택할 때 발생하는 것으로 보입니다. 어떤 단서/진단/조언이라도 환영합니다!

주의: 필수 옵션을 구성했습니다.

echo 0 > /proc/sys/net/ipv4/conf/**/rp_filter
echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter
sysctl -w net.ipv4.fwmark_reflect=1
sysctl -w net.ipv4.ip_forward=1

iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE
iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE
iptables -t nat -A POSTROUTING -o tun1 -j MASQUERADE

답변:

@AB의 답변이 솔루션을 제공합니다. tun0/1 테이블에 로컬 네트워크로 돌아가는 트래픽에 대한 경로를 추가해야 합니다.

ip r a 10.10.10.0/24 via 10.10.10.1 table tun0
ip r a 10.10.10.0/24 via 10.10.10.1 table tun1

@AB가 말했듯이, 표시된 패킷이 없으면 수신된 패킷이 다시 전송됩니다.

답변1

무슨 일이 일어나는지 따라가 보자.

  • 패킷(새 흐름의 첫 번째)이 터널이 아닌 인터페이스에서 도착합니다.
  • 콘트랙새 흐름을 시작하는 이 패킷에 대한 새 항목을 만듭니다.
  • 패킷은 라우팅 결정 이전에 (임의로 이번에는 ) 마크 200을 수신합니다.
  • 패킷은 테이블 200을 사용하여 라우팅됩니다.
  • 테이블 200에는 단일 가능성이 있습니다. 패킷이 다음을 통해 전송됩니다.tun0
  • 패킷의 표시는 전체 흐름에 대해 저장됩니다.콘트랙항목(예:콘마크).

지금까지는 괜찮았습니다. 패킷(및 해당 흐름)은 다음을 통해 로드 밸런싱되었습니다.tun0.

이제 다음과 같은 경우에는 어떻게 되나요?회신하다이 흐름의 패킷이 다시 돌아오나요?

  • 응답 패킷은 다음에서 도착합니다.tun0

  • 응답 패킷은 다음으로 식별됩니다.콘트랙기존 흐름의 일부로

  • 패킷은 해당 패킷에서 마크 200을 상속받습니다.콘마크라우팅 결정 이전의 기존 흐름과 연결됨

  • 패킷은 테이블 200을 사용하여 라우팅됩니다.

  • 테이블 200에는 단일 가능성이 있습니다. 패킷이 다음을 통해 전송됩니다.tun0

    Oups: 응답 패킷은 흐름의 초기 패킷이 시작된 곳이 아닌 터널 인터페이스에서 다시 라우팅됩니다.

  • 엄격한 역방향 경로 전달( )을 비활성화했는지 여부에 따라 다음 홉 라우터(터널 원격 끝점)에 따라 rp_filter=0패킷이 삭제되거나 감소하는 TTL이 0에 도달할 때까지 루프를 생성하여 다시 라우팅됩니다.

따라서 문제는 기본 테이블이 아닌 사용자 정의 테이블 중 하나를 통해 VPN 게이트웨이를 선택할 때 발생하는 것으로 보입니다.

실제로,기본라우팅 테이블에는 기본 경로가 두 개 이상 있습니다. 일반적으로 하나 이상의 LAN 경로가 포함됩니다. 따라서 마크가 포함되지 않은 경우 응답은 다음 평가에 따라 올바르게 라우팅됩니다.모두기본 경로를 따르는 것이 아니라 기본 라우팅 테이블 항목을 삭제합니다.

추가 LAN 경로는 다음과 같습니다.eth0그리고eth1또는 둘 다는 아니더라도 적어도 클라이언트 요청과 관련된 하나는 추가 라우팅 테이블(200 및 201)에도 복사되어야 합니다.

추가 설명(OP의 경우에는 적용되지 않음): 반대 방향으로 작동하는 설정에서 동일한(개인) IP 소스 주소를 사용하는 별도의 노드에서 동일한 서비스를 향한 원본 흐름이 있을 수 있습니다. 터널 인터페이스를 제외하면 동일합니다(동일한 5-uple 프로토콜,saddr,sport,daddr,dport). 기본적으로콘트랙하나의 흐름을 보게 될 것입니다. 이를 방지하기 위해 다음을 사용할 수 있습니다.conntrack 구역, (인터페이스를 나타내기 위해 선택된 값 포함)콘트랙별도로 처리하십시오.

관련 정보