현재 우리는 게스트 VLAN(eth1.251) 서브넷의 모든 패킷을 와이어 가드 터널을 통해 인터넷으로 라우팅하려고 합니다. 이를 달성하기 위해 트래픽이 게스트 서브넷에서 들어올 때 라우팅 테이블 10을 사용하는 규칙과 함께 정책 기반 라우팅을 사용하고 있습니다.
32765: from 10.251.0.0/16 lookup 10
라우팅 테이블 10에서는 터널 인터페이스를 향한 기본 경로를 생성합니다.
default dev wg1 scope link
게스트 네트워크의 모든 클라이언트는 예상되는 Wireguard 터널을 통해 인터넷에 연결할 수 있지만 클라이언트는 게스트 네트워크의 게이트웨이에 연결할 수 없습니다 (10.251.0.1). TCPDump는 ICMP 에코 응답이 인터페이스를 통해 wg1터널 끝점으로 다시 라우팅된다는 것을 보여줍니다. 이는 분명히 의도되지 않은 것입니다. 이에 대한 빠른 해결 방법은 게스트 VLAN 인터페이스에 대한 범위 링크 경로를 eth1.251라우팅에 추가하는 것입니다 table 10.
default dev wg1 scope link
10.251.0.0/16 dev eth1.251 proto kernel scope link
이제 클라이언트는 라우터 인터페이스에 접근하여 서비스를 제공할 수 있습니다.
이 라우터에는 서브넷이 있는 또 다른 인터페이스 eth1이 있습니다 192.168.0.1/16. 이제 새로 추가된 10.251.0.0/16경로를 삭제하면 더 이상 table 10라우터 인터페이스에 접근할 수 없습니다 .10.251.0.1아직은 닿을 수 있어192.168.0.1서브넷 에 있는 클라이언트의 인터페이스 10.251.0.0/16. 서브넷 192.168.0.2의 라우터 뒤에 있는 클라이언트(예: ) 192.168.0.0/16는 에서 다시 연결할 수 없습니다 10.251.0.0/16.
주요 질문192.168.0.1: 명시적인 라우팅 테이블 항목 없이 라우터의 인터페이스 IP에 연결할 수 있지만 10.251.0.1게스트 서브넷에 있는 클라이언트의 인터페이스 IP에는 연결할 수 없는 이유는 무엇입니까 10.251.0.0/16?
다음은 네트워크 구조에 대한 개요입니다. 이것이 우리의 설정을 이해하는 데 도움이 된다고 생각합니다.
답변1
일반적인 설명은 없으며 단지 라우팅 설정에서 일어나는 일을 따르는 문제일 뿐입니다.
10.251.0.1은 로컬 라우터 주소이자 10.251.0.0/16의 일부입니다.
패킷을 수신할 때현지의주소, 라우터가 일치현지의ip rule테이블 10에 대한 규칙 이전에 선호도가 가장 낮은 첫 번째 항목인 0을 사용하는 테이블 과 일치합니다. 라우팅 테이블이 다음과 일치한다는 점을 기억하세요.목적지, 일반적으로 맞춤 규칙은 다음과 일치하도록 구성됩니다.출처.
라우터가 응답하면 이번에는 로컬 테이블이 일치하지 않습니다. 10.251.0.2는 로컬이 아닙니다.목적지. 다음 규칙을 확인하고 일치하며 from 10.251.0.0/16테이블 10을 조회하고 패킷이 통과합니다.wg1.
192.168.0.1의 경우 패킷 수신은 이전과 똑같습니다.현지의테이블. 이제 답변은 추가 규칙과 일치하지 않으며 기본 라우팅 테이블이 적용됩니다. 이는 평소와 같이 작동합니다. Linux 시스템은 모든 IP에서 응답합니다.
다시 말하지만, 192.168.0.2의 경우:현지의IP이므로 일치하지 않습니다.현지의그러나 쿼리는 추가된 규칙과 일치합니다. 패킷은 다음을 통해 손실됩니다.wg1.
따라서 부작용을 피하기 위해 기본 라우팅 테이블의 일부를 추가 테이블에 복사하는 것이 도움이 됩니다.
ip route get관련된 표시가 없는 한 이 중 많은 부분을 올바른 구문으로 테스트할 수 있습니다 .
표 10에 추가 항목이 없으면:
# ip route get from 10.251.0.2 iif eth1.251 10.251.0.1
RTNETLINK answers: Invalid cross-device link
# sysctl -w net.ipv4.conf.eth1/251.rp_filter=2 #relax reverse path filtering
# ip route get from 10.251.0.2 iif eth1.251 10.251.0.1
local 10.251.0.1 from 10.251.0.2 dev lo table local
cache <local> iif eth1.251
# ip route get from 10.251.0.2 iif eth1.251 192.168.0.1
local 192.168.0.1 from 10.251.0.2 dev lo table local
cache <local> iif eth1.251
# ip route get from 10.251.0.2 iif eth1.251 192.168.0.2
192.168.0.2 from 10.251.0.2 dev wg1 table 10
cache iif eth1.251
회신 경로:
# ip route get from 10.251.0.1 10.251.0.2
10.251.0.2 from 10.251.0.1 dev wg1 table 10 uid 0
cache
# ip route get from 192.168.0.1 10.251.0.2
10.251.0.2 from 192.168.0.1 dev eth1.251 uid 0
cache
표 10에 항목을 추가할 때:
# ip route get from 10.251.0.2 iif eth1.251 10.251.0.1 #even with strict reverse path filtering, since the reverse route is correct
local 10.251.0.1 from 10.251.0.2 dev lo table local
cache <local> iif eth1.251
# ip route get from 10.251.0.1 10.251.0.2
10.251.0.2 from 10.251.0.1 dev eth1.251 table 10 uid 0
cache