내 Linux 서버에는 다음과 같은 라우팅 테이블이 있습니다.
$ ip ro
default via 172.28.127.254 dev wlp0s20f3 proto dhcp metric 600
10.8.3.0/24 dev tun0 proto kernel scope link src 10.8.3.2
169.254.0.0/16 dev docker0 scope link metric 1000 linkdown
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
172.28.96.0/19 dev wlp0s20f3 proto kernel scope link src 172.28.107.175 metric 600
이를 바탕으로 IP 8.8.8.8에 액세스하려고 하면 Linux는 172.28.127.254
인터페이스 뒤의 기본 게이트웨이를 통해 이를 수행 할 것이라고 추측합니다 wlp0s20f3
. 그러나 다음은 그렇지 않습니다.
$ ip ro get 8.8.8.8
8.8.8.8 dev tun0 table 205 src 10.8.3.2 uid 1000
cache
설명해주세요. 기본 게이트웨이를 사용하지 않는 이유는 무엇입니까?
답변1
당신은정책 기반 라우팅table 205
라우팅 결정에 암시된 대로 .
최소한 다음 출력을 확인하면 더 많은 정보를 얻을 수 있습니다.
ip rule
이 규칙에는 기본 세 가지 규칙(기본 설정은 0, 32766 및 32767) 외에 하나 이상의 규칙이 있습니다. 추가 규칙은 하나 이상의 추가 라우팅 테이블을 참조합니다
table 205
. 일반적으로 추가 규칙은 대상 이외의 항목에 따라 달라지지만(이미 단순 라우팅 사용으로 이미 다루어졌으므로 규칙에서는 거의 사용되지 않음) 어떤 항목에도 종속될 수도 있습니다(읽기 전용from all lookup 205
: 단순 재정의 역할을 함). 일치하는 경우 여기에서 다른 라우팅 테이블을 선택하세요table 205
.추가 라우팅 테이블은 다음 명령을 사용하여 확인할 수 있습니다.
ip route show table 205
이 경로 테이블은 평가되며 경로가 발견되면 추가 처리가 발생하지 않습니다. 기본 테이블은 평가되지 않으며 기본 테이블의 내용과 일치하지 않는 결정이 내려집니다. 다음과 유사한 내용이 표시될 가능성이 높습니다.
default dev tun0 proto static
그러나 이는 터널 및 라우팅에 관한 것이므로
tun0
터널 항목은 여전히 터널 봉투가 외부에서 정상적으로 라우팅되도록 허용해야 하므로 다음을 사용할 수 있도록 어딘가(규칙 또는 이 라우팅 테이블)에 예외가 있어야 합니다. 터널 끝점: 일반적인 방법(예: 사용dev wlp0s20f3
).터널에 따라 이 예외가 항상 필요한 것은 아니며(예: 터널 엔벨로프와 다른 네트워크 네임스페이스에서 WireGuard를 사용하지만 일반적으로 인터페이스가 호출됨
wg0
) 메서드마다 다른 형식을 취할 수 있습니다.