VPN 게이트웨이 재시작 후에도 IPv4 포워딩이 유지되게 하십시오

게이트웨이에 ping은 되지만 그 뒤의 무엇에도 닿지 않는다면, 이는 터널 문제가 아니라 포워딩 문제의 형태입니다. 게이트웨이로의 로컬 전달은 터널이 올라왔고 주소 할당이 동작했음을 증명하지만, 커널이 패킷을 한 인터페이스에서 다른 인터페이스로 넘겨줄지에 대해서는 아무것도 말하지 않습니다. 어떤 sysctl도 건드리기 전에 이 머신이 이 트래픽을 라우팅하도록 되어 있는지 확인하고 클라이언트 쪽 인터페이스를 가진 네트워크 컨텍스트를 찾으십시오. 그런 다음 마지막으로 읽은 안내서가 우연히 보았던 곳이 아니라 그곳에서 값을 읽으십시오.

게이트웨이에 닿는 것과 포워딩은 다릅니다

커널 안에서는 두 가지 별개의 결정이 일어납니다. 로컬 주소로의 전달은 패킷의 여정을 끝내고, 포워딩은 패킷을 다른 인터페이스로 다시 내보내며, 이 두 번째 결정은 네트워크 네임스페이스별로 관리됩니다. 게이트웨이에 완전히 닿을 수 있어도 포워딩이 꺼져 있을 수 있으며, ping 프롬프트에서는 두 고장이 똑같아 보입니다.

클라이언트 패킷이 어느 인터페이스로 들어오고 다음 경로가 어느 인터페이스로 나가는지 적어 두십시오. 둘 다 하나의 네임스페이스에 속하며, 중요한 설정은 그 네임스페이스에 있습니다.

패킷이 실제로 있는 곳에서 값을 읽으십시오

호스트 네임스페이스에서 라우팅하는 게이트웨이라면 명령 하나가 질문에 답합니다: sysctl net.ipv4.ip_forward. 들어오는 경로와 다음 경로가 이름이 있는 네임스페이스에 있다면 그 네임스페이스에 물으십시오: ip netns exec vpn-gw sysctl net.ipv4.ip_forward. 호스트의 값은 네임스페이스 값의 대리가 아니며, 호스트에서 켜져 있다고 해서 아무것도 증명하지 않습니다.

모든 라우팅 컨텍스트에 ip netns에 넘길 수 있는 레이블이 있는 것은 아닙니다. 컨테이너 런타임과 서비스는 친숙한 이름으로 등록되지 않는 네임스페이스를 만들며, 그런 경우 런타임의 검사 도구를 사용합니다. vpn-gw 대신 실제 이름이나 같은 컨텍스트에 닿는 런타임 메커니즘을 넣고, 호스트 수준에서 추측하는 것을 그만두십시오.

설정에 단일 소유자를 부여하십시오

일반적인 systemd 호스트 게이트웨이에서 지속되는 형태는 관리자가 고른 이름의 drop-in 파일이며, 예를 들어 /etc/sysctl.d/60-vpn-forwarding.conf에 net.ipv4.ip_forward = 1를 담습니다. 파일을 쓴 다음 그 특정 파일을 로드해 실행 중 상태도 바꾸십시오: sudo sysctl -p /etc/sysctl.d/60-vpn-forwarding.conf, 이어서 다시 읽어 확인합니다. 파일 이름은 예시일 뿐 예약된 VPN 경로가 아니며, 앞의 숫자가 중요한 이유는 나중에 정렬되는 파일이 이기기 때문입니다.

지속성이 조용히 깨지는 곳은 우선순위입니다. 배포판 로더와 자신의 drop-in을 모두 확인하십시오 — procps의 sysctl --system도 마지막에 /etc/sysctl.conf를 읽는 반면, systemd의 sysctl.d 순서는 완전히 다른 순서이기 때문입니다. 나중의 할당이 같은 키를 곧바로 되돌려 놓으면 파일은 올바르지만 실효 값은 틀린 상태가 됩니다. 그 논쟁에서 이기려고 기존 관리자 파일을 덮어쓰지 말고, 소유자를 찾아 그곳에서 바꾸십시오.

부팅 후에 만들어진 네임스페이스는 호스트 drop-in의 지배를 전혀 받지 않습니다. 그 설정은 컨테이너 런타임이든 네임스페이스 프로비저닝 단위든, 그것을 만드는 쪽에 속합니다. 질문을 피하려고 컨테이너에 넓은 호스트 권한을 주는 것은 올바른 소유자를 찾는 데 십 분을 쓰는 것보다 나쁜 거래입니다.

스위치를 뒤집기 전에 그 비용을 아십시오

ip_forward는 무해한 불리언이 아닙니다. 커널 문서는 이를 바꾸면 다른 여러 IPv4 매개변수가 호스트나 라우터 기본값으로 재설정된다고 지적하기에, 진단용으로 뒤집으면 다른 곳에서 한 튜닝을 버리면서 그 사실을 언급조차 하지 않을 수 있습니다. 가볍게 실행할 수 있는 점검이 아니라 부작용이 있는 구성 변경으로 다루십시오.

그래서 클라이언트가 호스트에 닿지 못할 때마다 껐다 켜는 것도 배제됩니다. 값이 이미 켜져 있다면 고장은 경로의 다른 곳에 있으며, 같은 키를 세 번째로 다시 써도 움직이지 않습니다.

지속성을 증명한 다음 경로의 나머지를 시험하십시오

네 시점에서 값을 다시 읽으십시오: 변경 직후, VPN 인터페이스가 나타난 후, 다시 연결한 후, 계획된 재시작 후입니다. 이 가운데 어느 지점에서든 되돌아가는 값에는 두 번째 소유자가 있으며, 한 번 더 일회성으로 쓰는 것은 다음 재부팅까지 숨길 뿐입니다.

포워딩을 켜 두어도 확인할 것이 세 가지 남습니다. 클라이언트에는 목적지로 가는 경로가 필요하고, 게이트웨이에는 다음 경로와 그것을 쓸 권한이 필요하며, 목적지에는 클라이언트 터널 주소로 돌아오는 경로가 필요합니다. 사설 라우팅된 LAN이 자동으로 NAT를 필요로 하지는 않으므로, 세 가지 중 무엇이 빠졌는지 알기 전에 masquerading을 추가하지 말고, 게이트웨이 자체가 아니라 의도한 클라이언트에서 시험하십시오 — 게이트웨이에서 시작된 요청은 방금 켠 포워딩 경로를 결코 지나지 않기 때문입니다. IPv6는 자체 포워딩과 라우팅 정책을 가지므로, 동작하는 IPv4 시험이 그것에 대해 말해 주는 것은 없습니다.

drop-in 경로, 네임스페이스 소유자, 다시 읽기 명령을 runbook에 함께 두십시오. 다음에 이것을 맡는 사람은 값을 읽고, 누가 소유하는지 보고, 문제가 지속성인지 경로의 나머지인지 일 분 안에 판단할 수 있어야 합니다.