PPP peer 주소와 VPN 엔드포인트: via에 들어갈 것은 어느 쪽인가

PPP 인터페이스의 한 줄, 즉 안쪽 주소와 그 옆에 찍힌 peer가 VPN 상자의 라우팅 논쟁 대부분을 정리합니다. 이 쌍을 작은 서브넷으로 읽으면 존재하지 않는 게이트웨이를 찾게 됩니다. 하나의 링크 양 끝으로 읽으면 다음 홉이 분명해집니다. 여기서 비교는 그 두 읽기 사이이며, 이후에 만드는 모든 테이블은 선택한 읽기를 물려받습니다. 외부 VPN 엔드포인트에 대해서는 둘 다 아무것도 정하지 않습니다.

하나의 인터페이스 줄에 대한 두 읽기

인터페이스가 inet 10.64.3.9 peer 10.64.3.1/32을 보고하는 세션을 봅니다. 서브넷 읽기는 10.64.3.9를 /32 섬 위의 외로운 호스트로 보고 그 너머로 가기 위한 라우터를 찾습니다. 링크의 다른 주소가 peer뿐이므로 그 읽기는 결국 10.64.3.9 자신을 게이트웨이로 제안하며, 이는 순환적입니다.

엔드포인트 읽기가 문서화된 쪽입니다. 점대점 인터페이스에서 peer은 그 하나의 링크의 먼 끝을 가리키므로 10.64.3.1이 쓸 수 있는 다음 홉이고 10.64.3.9는 항상 출발지 주소일 뿐입니다.

그 차이가 via에 무엇이 들어갈 수 있는지를 좌우합니다. 거기에 로컬 주소를 쓰면 커널이 이웃으로 해석할 수 없는 경로가 되어, 항목이 검증에서 떨어지거나 목록에서는 완전히 건강해 보이면서 트래픽을 삼킵니다. peer는 링크 위의 실제 목적지라서 동작합니다. 두 읽기는 완전히 별개의 정체성인 외부 VPN 엔드포인트에 대해서도 일치하며, 그곳에는 언더레이를 통해 도달하고 그것이 종료하는 터널을 통하지 않습니다.

세션이 이미 설치한 것

자기 테이블을 쓰기 전에 링크와 함께 온 것을 출력합니다. 지원되는 PPP 통합은 보통 세션 설정 중에 장치 경로와 peer 경로를 설치하며, 그 두 항목이 이미 올바른 읽기를 인코딩합니다.

ip -4 addr show dev ppp0
ip route show dev ppp0
ip route show table main | head -n 5

10.64.3.1 dev ppp0 proto kernel scope link src 10.64.3.9 같은 장치 경로는 인터페이스 자체가 경로이므로 게이트웨이를 갖지 않습니다. peer를 via로 지정하는 경로는 수명이 다른 별개 객체이며 세션이 끊기면 사라집니다. 두 형태 중 하나를 재설치 방식을 확인하지 않고 영구 테이블로 복사하는 것이, 잘 동작하던 터널이 재연결 후 경로를 잃는 흔한 이유입니다.

기억을 믿는 대신 두 목록을 비교합니다. peer 경로가 main에 있는데 추가 테이블이 비어 있다면, 주소 줄이 결코 알려 주지 않은 것을 배운 셈입니다.

규칙과 테이블은 별개의 결정

테이블을 고르는 것과 채우는 것은 독립적인 단계이며, 디버깅 중에 이 둘이 자주 혼동되므로 비교가 중요합니다. 표시된 트래픽을 테이블 100으로 보내는 규칙은 테이블 100에 맞는 경로가 없으면 아무 일도 하지 않고, 잘 채워진 테이블도 그것을 가리키는 규칙이 없으면 도달할 수 없습니다.

기본 경로의 절반은 기본 경로가 아닙니다. 0.0.0.0/1 하나는 IPv4 공간의 아래쪽 절반만 덮으므로, 모든 것을 잡으려는 정책에는 맞는 128.0.0.0/1나 진짜 default도 필요합니다. 동작하는 설정을 읽고 두 절반 중 하나만 복사하는 것이, 특정 목적지에서만 깨지는 라우팅 루프에 빠지는 길입니다.

LAN에 남아야 하는 주소에는 의도적인 예외를 남기고, 선택한 테이블에서 아무것도 찾지 못할 때 무슨 일이 일어날지 정합니다. 명시적인 대체 경로는, 도달 불가를 돌려주며 애플리케이션을 잘못 라우팅된 것이 아니라 고장 난 것처럼 보이게 하는 빈 테이블보다 생각하기 쉽습니다.

애플리케이션이 던지는 질문을 조회에 던진다

경로를 해석하는 ip route get과 저장된 항목을 나열하는 ip route show은 둘 다 틀리지 않으면서 어긋날 수 있습니다. 출발지 기반 규칙은 조회가 출발지를 실을 때만 일치하므로 출발지 문맥을 포함합니다.

ip route get 198.51.100.23 from 10.64.3.9
ip route get 198.51.100.23 from 10.64.3.9 iif ppp0
ip -4 rule show

첫 명령은 호스트 쪽에서 질문합니다. 두 번째는 들어오는 인터페이스를 더하며, 전달되는 트래픽이 겪는 것에 더 가깝고, 답은 흔히 다른 테이블을 가리킵니다. 어느 목적지도 실제 테스트 서비스가 아니며, 198.51.100.23은 문서용 주소이므로 조사가 허용된 호스트로 바꿉니다.

올바른 조회도 경로가 선택되었다는 것만 증명합니다. 상대편이 트래픽을 받아들이는지, 응답이 같은 추론으로 돌아올 수 있는지는 말하지 않습니다.

비교가 뒤집히는 곳

호스트 트래픽과 전달되는 트래픽은 다른 조회를 할 뿐 아니라 돌아오는 길에서 다른 필터를 만납니다. Linux는 모든 인터페이스와 수신 인터페이스 설정 중 더 엄격한 값으로 역경로 검증을 적용하므로, 한 인터페이스의 값을 바꿔도 눈에 보이는 효과가 없을 수 있습니다. 표시 기반 라우팅은 src_valid_mark 관계를 더하며, 출발지가 유효하다고 인정되려면 표시가 일치해야 합니다.

나가는 라우팅이 맞아 보이는데 응답이 사라진다면, 건드리기 전에 실효값을 읽고, 명시한 정책 이유가 있을 때만 바꿉니다.

sysctl net.ipv4.conf.all.rp_filter
sysctl net.ipv4.conf.ppp0.rp_filter
sysctl net.ipv4.conf.all.src_valid_mark

증거에 기반해 고른다면, 애플리케이션이 PPP 주소에 묶일 때는 출발지 규칙과 peer 경로를 담은 테이블이면 충분합니다. 상자가 뒤쪽 LAN을 위해 전달한다면 들어오는 문맥과 돌아오는 길도 일치해야 합니다. 일치하지 않으면 머신 전체의 검증을 느슨하게 하는 대신 경로의 소유권을 고칩니다.