VPN 유출을 고치려고 IPv6를 끌까? 차라리 정책을 정하세요

IPv6 대역의 주소가 테스트 페이지에 나타나고, 터널은 분명히 그것을 전달하지 않으며, 인터넷에서 가장 인기 있는 조언은 IPv6를 어디서나 끄라는 것입니다. 그 명령은 실제로 패널을 조용하게 만듭니다. 하지만 접속 네트워크가 의존할 수 있는 프로토콜도 없애고, 그 주소가 진짜 유출이었는지, 링크 로컬 인터페이스 주소였는지, 아니면 제 일을 하는 리졸버였는지 알 수 없게 만듭니다. 올바른 제어를 결정하는 것은 세 가지 조건이며, 차단으로 이어지는 것은 그중 하나뿐입니다.

도구가 실제로 무엇을 측정했는지 확인하세요

가장 흔한 오탐은 링크 로컬 주소로, fe80: 으로 시작하며 IPv6를 지원하는 모든 인터페이스에 존재합니다. 머신이 IPv6로 인터넷에 도달할 수 있는지와 무관합니다. 인터페이스 목록과 일부 애플리케이션 진단에 나타나지만 트래픽 경로에 대해서는 아무것도 말하지 않습니다.

두 번째 오탐은 fc00::/7 안의 고유 로컬 주소로, 네트워크 내부에서 쓰는 사설 대역입니다. 호스트가 가진 모든 주소를 출력하는 도구는 그것을 공인 주소 옆에 기꺼이 나열합니다. 급히 읽는 사람은 그것을 유출이라고 부르고, 존재하지 않는 문제에 한 시간을 씁니다.

세 번째는 전혀 오탐이 아닙니다. 터널 밖에서 인터넷에 도달하는 전역 주소가 진짜 유출이며, 무엇이든 결정하기 전에 측정할 가치가 있습니다.

ip -6 addr show scope global
ip -6 route show default
curl -6 -sS --max-time 6 https://ifconfig.co

첫 명령이 전역 주소를 출력하고 세 번째가 터널의 것이 아닌 공인 IPv6 주소를 반환하면, 터널 밖에 실제 경로가 있습니다. 첫 명령이 링크 로컬 항목 외에 아무것도 출력하지 않으면 고칠 유출은 애초에 없었습니다.

제어를 결정하는 세 가지 조건

결정은 "IPv6가 좋다"거나 "IPv6가 나쁘다"가 아닙니다. 세 가지 상황 중 어디에 있는지이며, 각각 정답이 다르고 틀렸을 때의 비용도 다릅니다.

첫 번째 행은 사람들이 보통 의미하는 것이고 정당합니다. 출구가 IPv6를 지원하지 않는 클라이언트는 호스트 고유의 IPv6 트래픽을 조용히 내보내서는 안 됩니다. 그것이 문서화된 이중 스택 유출이기 때문입니다. 요점은 그것을 선언된 정책으로 차단하는 것이지 커널에서 프로토콜을 끄는 것이 아닙니다. 보이는 결과는 같고 나중에 검토할 수 있는 것은 둘 중 하나뿐입니다.

세 번째 행은 일반적인 조언이 실제로 해로워지는 지점입니다. 이동통신사와 일부 가정 연결은 IPv4 목적지에 대한 변환을 갖춘 IPv6 전용 망을 운영합니다. 거기서 IPv6를 없애면 그 망이 제공하는 유일한 전송 수단을 없애는 것이며, 디버깅하던 장애보다 훨씬 나쁜 중단을 만듭니다.

출구에 IPv6가 없다면 의도적으로 차단하세요

클라이언트 자체의 메커니즘을 우선하세요. 터널이 올라와 있는 동안에만 정확히 적용되고, 터널이 내려가면 되돌아갑니다.OpenVPN에는 이를 위한 옵션이 있고, 다른 클라이언트에는 iptables의 동등한 규칙이 있습니다.

block-ipv6
ip6tables -A OUTPUT -o eth0 -j REJECT --reject-with ipv6-port-unreachable

지시문은 프로필에 속하고, 규칙은 검토하고 제거할 수 있는 방화벽에 속합니다. 둘 다 닫힌 상태로 실패하며 그것이 원하는 동작이고, 둘 다 구성 차이에 나타납니다. 시작 스크립트에 묻힌 커널 sysctl은 그렇지 않습니다.

왜 있는지 기록하세요. 주석 없는 차단 규칙은 IPv6를 다른 일에 필요로 하는 다음 사람이 지우고, 그러면 유출이 조용히 돌아옵니다.

출구가 IPv6를 전달한다면 경로를 잡고 두 체계를 모두 시험하세요

서버가 지원한다면 IPv6를 전달하는 것이 더 나은 답이고 그리 어렵지도 않습니다. 요구 사항은 터널 인터페이스가 그 체계의 주소를 갖고, 그 기본 경로가 물리 인터페이스 밖이 아니라 터널 안을 가리키는 것입니다.

ip -6 route get 2606:4700:4700::1111
ip -6 route show default
curl -6 -sS --max-time 6 https://ifconfig.co
curl -4 -sS --max-time 6 https://ifconfig.co

경로 조회가 결정적 시험입니다. 터널 인터페이스를 지목하면 IPv6 트래픽이 전달되고 있는 것입니다. 이어서 두 curl 호출이 각 체계가 보는 것을 확인하며, 둘을 비교하는 것이 두 경로가 이제 같은 출구로 나간다는 증명 방법입니다.

연결에 성공했다고 멈추지 마세요.터널을 다시 연결하고 다시 확인하세요. 서버가 초기 구성에서만 보낸다면 밀어 넣은 IPv6 경로가 재설정 때 사라질 수 있기 때문입니다. 다음으로 제외된 목적지 하나를 확인하세요. 분할 터널 규칙이 두 체계가 가장 자주 어긋나는 지점입니다.

접속 네트워크가 IPv6 전용이라면 그대로 두세요

일부 네트워크는 IPv6만 제공하고 기기가 통신사 측 변환 메커니즘을 통해 IPv4 서비스에 도달하기를 기대합니다. 그런 기기에서 IPv6를 끄는 것은 보안 개선이 아니라 무엇으로 가는 유일한 경로를 없애는 일입니다. 아무도 필요로 하지 않은 시험 결과를 위해 스스로 만든 장애입니다.

여기서 틀렸을 때의 증상은 뚜렷하고 불쾌합니다. 터널은 맺어진 것처럼 보이고 이름 해석은 되지만 아무것도 로드되지 않습니다. IPv6 변경 후에 이것을 보면 즉시 설정을 되돌리고 진단은 다른 곳에서 계속하세요.

무엇을 고르든 결정을 프로필이나 방화벽에 명시하고, 출구가 실제로 지원하는 것에 연결하고, 마지막으로RFC 7359의 이중 스택 논의가 설명하는 이중 스택 동작을 적어 두세요. 선언된 차단은 정책입니다. 꺼 버린 프로토콜은 아무도 감사할 수 없는 우회이며, 테스트 페이지에서는 둘이 똑같아 보입니다.