☰

LAN으로 들어오는 것과 동일한 인터페이스의 응답 패킷

tag-icon • tag-icon linux networking linux-networking iproute2 policy-routing
LAN으로 들어오는 것과 동일한 인터페이스의 응답 패킷

현재 저는 다음 시나리오로 어려움을 겪고 있습니다.

  • 2개의 별도 LAN 서브넷에 2개의 인터페이스가 있는 서버가 있습니다. IF1, IF2
  • 첫 번째 서브넷의 IP 주소를 가진 노트북이 있습니다.
  • 이 특정 노트북에서 서버의 두 번째 IP 주소로 연결하려고 하면 전혀 응답을 받지 못합니다.

예를 들어, IP 172.31.190.129를 사용하는 노트북에서 172.31.196.185로 ping을 시도하면 ens224 인터페이스의 tcpdump에서 들어오는 요청을 볼 수 있지만 그 이후의 다른 인터페이스에서는 응답 요청이 없습니다.

내 네트워크 다이어그램은 다음과 같습니다.

       +-------------------------+
       |                         |
       |  Laptop 172.31.190.129  +---------+
       |                         |         |
       +-------------------------+         |
                                           |                 +-------------------------+
                                           |                 |                         |
                               +-----------+---------+       |       Linux Server      |
                          +----+                     |       |                         |
                          |    | LAN 172.31.190.0/23 +-------+ IF1  -  default gw      |
                   +------+--+ |                     |       | 172.31.190.63           |
    +----------+   |         | +---------------------+       |                         |
    | Internet +---+ Gateway |                               |                         |
    +----------+   |         | +---------------------+       |                         |
                   +------+--+ |                     |       |                         |
                          |    | LAN 172.31.196.0/23 +-------+ IF2                     |
                          +----+                     |       | 172.31.196.185          |
                               +---------------------+       |                         |
                                                             |                         |
                                                             |                         |
                                                             +-------------------------+

또한 다음 스크립트가 있습니다.

IF1=ens160
IF2=ens224

P1_NET=172.31.190.0/23
P2_NET=172.31.196.0/23

IP1=172.31.190.63
IP2=172.31.196.185

P1=172.31.190.1
P2=172.31.196.1

ip route add $P1_NET dev $IF1 src $IP1 table T1
ip route add default via $P1 table T1
ip route add $P2_NET dev $IF2 src $IP2 table T2
ip route add default via $P2 table T2

ip route add $P1_NET dev $IF1 src $IP1
ip route add $P2_NET dev $IF2 src $IP2

ip rule add from $P1_NET dev $IF1 table T1
ip rule add from $P2_NET dev $IF2 table T2

이 링크에 따라 작성되었습니다.https://lartc.org/howto/lartc.rpdb.multiple-links.html

제 경우에는 정책 기반 라우팅을 만들기 위해 여러 가지 방법을 시도했지만 아무도 성공하지 못했습니다...

답변1

TL;DR

필요하지 않다iptables, 표시, 긴장을 풀지 않음역방향 경로 전달/필터. ip rule나가는 패킷과 일치하지 않는 사용한 s 대신 에 설명된 대로 명령을 사용하십시오.LARTC 문서귀하가 제공한 링크:

ip rule add from $IP1 table T1
ip rule add from $IP2 table T2

그러면 모든 것이 잘 작동할 것입니다.

긴 버전

긴장을 풀어 일이 잘 되도록 하는 것이 항상 가능하더라도역방향 경로 전달/필터예를 들어sysctl -w net.ipv4.conf.all.rp_filter=2등으로 인해 비대칭 라우팅이 허용되므로 비대칭 라우팅은 항상 피해야 합니다. 특히 다음과 같은 점을 고려하면게이트웨이(엄격한 상태 저장 방화벽 역할을 하는 경우) 또는랩탑비슷한 이유로 허용하지 않을 수도 있습니다. 사용iptables잘못된 동작을 수정하기 위한 표시는 이미 복잡한 라우팅 설정이 어떻게 동작할지 이해하는 데 확실히 도움이 되지 않습니다.

링크된 문서에서는 서버의 IP를 소스로 사용하지만($IF2/의 경우)엔스224: 172.31.196.185)인터페이스 없이IP 규칙의 경우 규칙에서 수신 인터페이스를 지정합니다( 여기서는 dev의미 iif). 이것이 문제입니다. 이는 예상되는 효과가 없습니다. iif에 대한 설명을 참조하세요.ip rule:

만약이름

일치하는 수신 장치를 선택하십시오.인터페이스가 루프백인 경우 규칙은 이 호스트에서 발생하는 패킷만 일치합니다.. 이는 전달된 패킷과 로컬 패킷에 대해 별도의 라우팅 테이블을 생성하여 완전히 분리할 수 있음을 의미합니다.

명확하게 작성되지는 않았지만 그 반대도 사실입니다: 패킷원산지iif ens160이 호스트에서는 루프백 인터페이스에만 일치합니다. nor 와 일치하지 않지만 ( 예 iif ens224는iif loiif들어오는인터페이스 및 iif lo일치 항목이 로컬에서 생성됨나가는패킷의 경우 이를 "로컬 시스템에서 [라우팅 규칙이 알려주는 곳으로] 들어오는" 것으로 해석하는 것으로 간주하십시오. 이것은 중요합니다.

그러면 어떻게 되나요?

  1. 랩탑$IP2에 도달하려고 시도합니다(동일한 LAN에 있는 서버의 $IF1 및 $IP1을 통해 $IP2에 도달할 수 있다는 사실을 알 수도 없고 알 수도 없습니다).게이트웨이,

  2. 게이트웨이$P2_NET에 속한 서버의 $IP2, $IF2 인터페이스로 패킷을 라우팅합니다.

  3. 섬기는 사람$IF2 인터페이스에서 $P1_NET(172.31.190.129에서)에 속하는 패킷을 수신합니다.

  4. 섬기는 사람의 엄격한 역방향 경로rp_filter=1역방향 경로를 확인하고,

  5. 위에서 본 것처럼 역방향 경로일치하지 않습니다iif다음과 다름 : iif lo두 개의 새로운 규칙이 일치하지 않으므로 나머지 일치 규칙은 $IF1을 통한 기본 라우팅 테이블에 대한 규칙입니다.

     # ip route get 172.31.190.129 from 172.31.196.185
 172.31.190.129 from 172.31.196.185 dev ens160 uid 0 
     cache

  6. 역방향 경로는 패킷이 도착한 인터페이스를 사용하지 않습니다. 패킷이 삭제됩니다.

같은 이유로 현재 설정에서는 인터넷에 대한 올바른 액세스를 허용하지 않습니다.섬기는 사람$IP2:를 사용하면 다시 새 규칙과 일치하지 않으므로 이에 대해 $IF1을 사용하려고 합니다.

# ip route get 8.8.8.8 from 172.31.196.185
8.8.8.8 from 172.31.196.185 via 172.31.190.1 dev ens160 uid 0 
    cache

따라서 LARTC에 설명된 대로 두 규칙이 제거되고 변경되면 다음과 같습니다.

ip rule add from $IP1 table T1
ip rule add from $IP2 table T2

그건:

# ip rule add from 172.31.190.63 table T1
# ip rule add from 172.31.196.185 table T2

경로 조회를 통해 알 수 있듯이 상황이 올바르게 작동합니다(현재 를 사용함 table T2).

# ip route get 172.31.190.129 from 172.31.196.185
172.31.190.129 from 172.31.196.185 via 172.31.196.1 dev ens224 table T2 uid 0 
    cache 

# ip route get 8.8.8.8 from 172.31.196.185
8.8.8.8 from 172.31.196.185 via 172.31.196.1 dev ens224 table T2 uid 0 
    cache

이 3가지 변형도 작동했을 수 있습니다(단순화를 위해 테이블 ​​T2에 규칙을 넣음).

ip rule add from 172.31.196.0/23 table T2
ip rule add from 172.31.196.185 iif lo table T2
ip rule add from 172.31.196.0/23 iif lo table T2

매뉴얼 페이지에 설명된 대로 다음과 같은 iif lo경우 동작이 변경됩니다.섬기는 사람또한 그 뒤에 다른 시스템을 라우팅합니다(다시 말하지만 규칙은 해당 시스템에 대해 일치하지 않습니다). 필요하지 않으면 사용하지 않는 것이 좋습니다.

필요하지 않다iptables그리고 이것에 대한 표시. 표시를 사용하여 인터페이스를 변경하면 라우팅, ARP 요청 및 역방향 경로 필터링에 추가 문제가 발생할 수 있습니다(표시를 사용하려면 일반적으로 휴식이 필요함).rp_필터), 피할 수 있다면 사용하지 않는 것이 좋습니다.

관련 정보