Linux VPN 응답이 사라지나요? rp_filter와 경로를 확인하세요

요청은 머신을 떠나고 VPN 피어가 응답하지만, 그 응답은 소켓에 도달하지 않습니다. 터널은 올라와 있고, 피어 로그는 패킷이 전송되었음을 보여 주며, 애플리케이션 안에는 이 침묵을 설명하는 것이 없습니다. Linux에서 흔한 용의자 중 하나는 역경로 필터링입니다. 소스 검증이 커널이 그 소스에 기대하는 경로와 맞지 않으면 들어오는 IPv4 패킷이 거부될 수 있습니다. 순서대로 따라가면 그것이 원인인지 우연인지 알 수 있습니다. 또한 빠진 경로를 고치려고 보안 제어를 끄는 일도 막아 줍니다.

소스 검증이 결정하는 것

커널은 패킷의 소스 주소가 도착한 인터페이스에 대해 그럴듯한지 확인하며, 그 소스로 돌아가는 경로를 라우팅 테이블에서 조회합니다. 역경로가 다른 곳을 가리키면 방화벽 규칙이나 애플리케이션 소켓이 보기도 전에 패킷이 버려질 수 있습니다. 이 검사는 특정 스푸핑 패턴을 어렵게 만들기 위해 존재하며, 비대칭 및 정책 라우팅 설계가 여기에 걸리는 반면 같은 네트워크의 평범한 클라이언트는 잘 동작하는 이유도 그것입니다. 평범한 클라이언트는 대칭 라우팅을 가지며, 검사가 전제하는 것이 바로 그것입니다.

중요한 단어는 그럴듯함입니다. 패킷은 완전히 정당해도 검사에서 실패할 수 있습니다. 검사하는 것이 정당성이 아니기 때문입니다.

실제 모드를 읽으세요, 한 필드가 아니라

모드는 비활성, 엄격, 느슨의 세 가지입니다. 엄격은 느슨과 다른 경로 기대를 강제하며, 전역 설정은 인터페이스별 설정과 상호 작용하므로 파일 하나를 읽으면 실제로 시행 중인 것을 잘못 설명할 수 있습니다. 둘 다 읽고, 기본 경로의 인터페이스가 아니라 응답을 받는 인터페이스에서 읽으세요.

sysctl net.ipv4.conf.all.rp_filter
sysctl net.ipv4.conf.<iface>.rp_filter
ip route get <source-of-the-reply>

그 세 번째 줄의 경로 조회가 사람들이 건너뛰는 부분입니다. 커널이 소스에 대해 무엇을 믿는지 알려 주며, 그것이 바로 검사의 입력입니다.

검사를 바꾸기 전에 불일치를 찾으세요

응답이 왜 그 인터페이스로 오는지, 그리고 그 역경로가 달라야 하는지 알아내세요. 요청은 한 경로로 내보내고 응답은 다른 경로로 돌아오게 하는 정책 규칙은 정당한 설계입니다. 엄격한 검증이 거부하는 것이 바로 그 설계이며, 정책 라우팅에서 쓰는 마크도 역조회가 돌려주는 것을 바꾸기 때문에 여기서 중요할 수 있습니다.

역경로가 그냥 빠져 있다면, 검사를 끄는 대신 그것을 추가하는 것이 원인을 고칩니다. 빠진 경로, 방화벽의 거부, 잘못된 트래픽 셀렉터는 모두 같은 눈에 보이는 증상을 만들며, 그중 소스 검증에 관한 것은 하나뿐입니다.

첫 반응으로 소스 검사를 전역에서 끄지 마세요. 그것은 구체적인 진단을 나중에 기억해야 할 넓은 동작 변경과 맞바꾸는 일입니다.

변호할 수 있는 선택적 조정

좁은 조정이 정말 필요하다면, 그것이 필요한 인터페이스로 범위를 좁히고, 이유를 적고, 재부팅 후에도 남도록 그 인터페이스를 소유한 설정에 넣으세요. 그다음 실패한 바로 그 흐름을 같은 소스에서 같은 목적지로 다시 시험하세요. 편한 무언가로 ping하는 것이 아니라.

여전히 거부되어야 할 사례를 포함하세요. 그 사례가 이제 통과한다면, 조정은 고치려던 한 경로보다 더 많이 약화시킨 것입니다.

IPv4와 IPv6를 분리하세요

익숙해 보이는 sysctl이 모든 주소 패밀리에 대한 정책은 아닙니다. IPv6는 고유한 동작과 고유한 설정을 가지며, 특정 목적지가 실패할 때까지 아무도 알아채지 못한 채 한 패밀리에서는 엄격하고 다른 패밀리에서는 관대할 수 있습니다. 워크로드가 둘 다 쓴다면 둘 다 확인하세요.

모드, 인터페이스, 경로 조회 출력, 변경 이유를 한곳에 기록하세요. 다음 사람은 설정만 찾고 설명은 찾지 못하며, 그것을 제거하거나 있어서는 안 될 곳에 복사할 것입니다.