127.0.0.1로의 DNAT에 각별한 주의가 필요한 이유

어떤 서비스가 127.0.0.1:1080에서 수신 대기 중입니다. DNAT 규칙이 들어오는 트래픽을 그 주소로 보내지만 연결은 실패합니다. 서비스가 정상이고 NAT 규칙도 일치할 수 있습니다. IPv4 루프백 주소는 라우팅에서 특별한 처리를 받기 때문입니다.

리눅스의 route_localnet는 라우팅 시 127/8 주소를 화성 주소로 취급할지 결정합니다. 기본값은 통상적인 루프백 경계를 유지합니다. 특정 인터페이스에 대한 예외는 의도적인 로컬 리디렉션 설계에서 의미가 있을 수 있습니다.

이 때문에 다른 머신에서 동작하던 규칙이 복사하지 않은 sysctl에 의존할 수 있습니다. 그러나 그 옵션을 어디서나 켜야 한다는 근거는 되지 않습니다.

보안 가정은 경로에 따라 달라진다

루프백 바인딩은 보조 구성 요소에 독립적인 클라이언트 인증이 없기 때문에 자주 쓰입니다. 다른 인터페이스에서 오는 트래픽이 그곳으로 라우팅될 수 있다면, 바인딩 주소만으로는 도달 가능한 대상을 더 이상 설명하지 못합니다. 실제 규칙 집합에서 유입 소스, 목적지, 포트를 제한하고, 해당되는 경우 루프백 출발지나 목적지 주소를 주장하는 트래픽도 포함해 고려하세요.

서비스를 담고 있는 네트워크 네임스페이스를 검토하세요. 컨테이너의 루프백은 호스트의 루프백이 아니며, 호스트 인터페이스 설정을 바꾼다고 컨테이너 안에 수신기가 자동으로 생기지 않습니다.

rp_filter는 출발지 경로 검증에 관한 다른 질문에 답합니다. 이를 전역으로 끄는 것은 루프백 라우팅을 이해하는 일반적인 대체 수단이 아닙니다. 마찬가지로 ip_nonlocal_bind는 소켓을 비로컬 주소에 바인딩하는 문제이지, 이 DNAT 경로를 올바르게 만드는 문제가 아닙니다.

마지막으로 리디렉션된 프로토콜이 수신기와 맞아야 합니다. 원시 HTTP나 TLS 트래픽을 SOCKS 포트로 보내려면 여전히 변환기가 필요하며, 라우팅 예외는 빠진 협상을 제공할 수 없습니다.