net.ipv4.conf.default.forwarding이 tun0을 건드리지 않는 이유

설정한 값은 net.ipv4.conf.default.forwarding=1 입니다. VPN을 다시 시작해도 터널은 게이트웨이가 라우팅해야 할 패킷을 여전히 버립니다. 파일 속 설정은 맞아 보이고, 인터페이스는 여전히 포워딩이 꺼져 있다고 보고합니다. 고장이 아닙니다. 바꾼 것은 앞으로 생길 인터페이스가 물려받는 값이고, 살아 있는 터널이 쓰는 값이 아닙니다.

터널을 소유한 호스트에서, 터널이 실제로 존재하는 네트워크 namespace 안에서 확인하세요. 컨테이너나 네트워크 namespace가 인터페이스를 들고 있고 호스트는 다른 숫자를 보여 줄 수 있습니다.

세 값을 함께 읽기

먼저 게이트웨이 전체 스위치, 새 인터페이스용 템플릿, 그리고 신경 쓰는 인터페이스를 비교하세요. tun0 을 실제 입력 인터페이스로 바꾸고, 반환 인터페이스도 읽으세요. 포워딩은 패킷이 도착하는 지점에서 판정되기 때문입니다.

sysctl net.ipv4.ip_forward
sysctl net.ipv4.conf.default.forwarding
sysctl net.ipv4.conf.tun0.forwarding

흔한 결과는 ip_forward = 0, default.forwarding = 1 그리고 tun0.forwarding = 0 입니다. 앞의 두 값은 호스트의 역할에 대해 서로 어긋나고, 세 번째는 인터페이스가 실제로 무엇을 하는지 보여 줍니다. 이 조합은 라우터로 설정된 적 없이 템플릿 값만 받은 호스트와 일치합니다. 세 숫자는 서로 모순되지 않습니다. 서로 다른 세 가지 질문에 답하고 있을 뿐입니다. 템플릿 값을 쓴다고 해서 호스트의 역할이 정해지는 것도 아닙니다.

움직이는 것이 전역 스위치인 이유

net.ipv4.ip_forward 은 게이트웨이 전체를 제어합니다. 이 값을 바꾸면 같은 작업의 일부로 인터페이스별 포워딩 설정이 갱신되므로, 한 번의 쓰기로 기존 터널이 포워딩을 시작할 수 있습니다. default.forwarding 은 그 뒤에 초기화되는 인터페이스에만 적용되므로, 이미 존재하던 터널은 태어날 때의 값을 그대로 유지합니다.

커널 문서는 ip_forward 을 관련된 이유로 특별하다고 표시합니다. 이 값을 바꾸면 다른 IPv4 매개변수 묶음이 호스트 또는 라우터 기본값으로 되돌아갑니다. 그래서 이것은 거친 도구입니다. 게이트웨이 역할을 세우는 과정에서 한 번 설정하는 것은 괜찮지만, 디버깅 요령으로 반복해서 토글하면 공들여 맞춘 설정을 조용히 다시 써 버릴 수 있습니다.

인터페이스별 값에도 이유가 있습니다. 의도적으로 관리되는 게이트웨이는 절대 라우팅해서는 안 되는 인터페이스에서 포워딩을 꺼 둘 수 있습니다. 호스트가 다른 곳에서 포워딩하더라도 마찬가지입니다. 그래서 살아 있는 인터페이스를 읽는 것이 중요하고, 그래서 전역 값만으로는 답이 되지 않습니다. 그런 예외는 의도된 결정으로 읽고, 그 인터페이스가 왜 다른지 적어 두세요. 그렇지 않으면 다음 엔지니어가 친절하게 "고쳐" 버립니다.

설정을 올바른 곳에서 영구화하기

성공한 일회성 sysctl -w 은 커널이 그 값을 받아들인다는 증거일 뿐입니다. 재부팅 후에는 남지 않고, 다시 연결할 때 인터페이스 설정에 대한 자기 생각을 다시 적용하는 네트워크 관리자 뒤에서도 남지 않습니다. 게이트웨이 역할을 sysctl 설정 파일이나 그 호스트를 관리하는 네트워크 관리자에 두세요, 그다음 그것을 적용하는 서비스를 다시 시작하세요.

터널에서는 순서가 중요합니다. 관리자가 부팅 시 인터페이스를 만들고 포워딩을 나중에 적용하면, 인터페이스는 옛 기본값을 물려받을 수 있습니다. 터널을 다시 만드는 서비스 재시작도 생성 이벤트이며, 유닛이 건강해 보이면 놓치기 쉽습니다. 최종 파일 내용만이 아니라 순서를 확인하세요.

VPN이 다시 연결된 뒤와 재부팅 뒤에 같은 세 값을 다시 읽으세요. 새로 만들어진 터널은 새 인터페이스이고, 새 인터페이스는 생성 시점에 유효한 기본값을 가져갑니다. 이 사건들 사이에 숫자가 바뀐다면, 아직 확인하지 못한 무언가가 설정을 적용하고 있는 것입니다.

잘못된 도구로 고치지 마세요

포워딩이 고장 나 보이면 방화벽을 비우거나 masquerading을 추가하고 싶어집니다. 둘 다 포워딩 스위치를 다루지 않습니다. 포워딩 상태, 포워딩 권한, 목적지로 가는 경로, 돌아오는 경로는 서로 다른 네 가지 요구 사항이고, 첫 번째만 sysctl입니다.

올바른 흐름으로도 시험하세요. 게이트웨이 자체에서 보낸 요청은 포워딩을 전혀 쓰지 않습니다. 로컬에서 만들어진 트래픽입니다. 문제는 VPN 클라이언트나 LAN 호스트에서 온 패킷이 받아들여져 앞으로 라우팅되는지이므로, 시험은 게이트웨이 뒤에서 시작해야 합니다.

IPv6 사례는 따로 두기

여기서는 모두 IPv4입니다. IPv6 포워딩, 라우터 광고, accept_ra 동작에는 각자의 제어가 있고, ipv4 경로를 ipv6 설정으로 복사하면 그럴듯해 보이지만 쓸모없는 파일이 만들어집니다. 이중 스택 게이트웨이는 두 세트를 모두 의도적으로 설정해야 합니다.

마지막 확인입니다. 값이 일치하면 터널의 경로가 목적지에 대해 선택되는지, 응답 경로가 존재하는지 확인하세요. 경로가 없는 인터페이스에서 포워딩을 켜도 여전히 블랙홀이고, 그 실패는 클라이언트 쪽에서 똑같이 보입니다.