/64를 분할해도 IPv6가 VPN 클라이언트로 라우팅되지 않습니다

클라이언트는 전역 IPv6 주소를 표시하고 핸드셰이크도 완료되었지만 인터넷에서 아무것도 돌아오지 않습니다. 풀 설정은 올바르기 때문에 올바르게 보이며, 주소는 유효하고 터널이 그것을 운반합니다. 실패하는 것은 전달이며, 전달은 VPN 서버 위에서 내려진 결정에 달려 있고 클라이언트 측 구성은 그것에 영향을 줄 수 없습니다.

오해: /64의 일부는 이미 도달 가능하다

이야기는 매력적입니다: 서버에 공인 /64가 있으니 그것을 반으로 나누고 나머지 절반을 VPN 풀에 주면 그 클라이언트들이 이제 인터넷에 있다는 것입니다. 프리픽스를 분할하면 충돌 없이 주소를 할당하는 것은 사실입니다. 하지만 그 주소 중 하나로 가는 패킷이 어디로 가야 하는지를 업스트림 네트워크가 결정하는 방식은 바뀌지 않습니다.

IPv6에는 기댈 기본 변환 계층이 없으므로 반환 경로가 라우팅으로 또는 링크 계층 전달로 존재해야 합니다. 클라이언트의 터널 주소로 향한 패킷은 업스트림 라우터에 도착하고, 그 라우터는 자신의 테이블에서 전달 결정을 내립니다. 테이블이 물리 링크를 가리키면 VPN 서버가 무엇을 믿든 패킷은 그리로 갑니다.

이것이 실패의 전부입니다: 나가는 방향은 서버가 보내기 때문에 작동하고, 돌아오는 방향은 업스트림이 클라이언트의 존재를 전혀 알지 못했기 때문에 한 홉 떨어진 곳에서 죽습니다.

링크에서의 전달이 실제로 요구하는 것

업스트림이 /64 전체를 물리 링크에 있는 것으로 간주하면 각 목적지 주소를 이웃 탐색으로 해석합니다. 그 링크로 요청을 보내고 주소 소유자가 응답하기를 기대합니다. 터널 뒤에 있는 VPN 클라이언트는 그 링크에 없고 응답할 수 없으므로 요청은 응답 없이 남고 패킷은 버려집니다.

/65를 잘라내도 그 기대는 바뀌지 않습니다. 업스트림은 여전히 그 범위를 링크에 있는 것으로 취급하는데, 생각을 바꿀 유일한 것이 클라이언트를 대신해 응답하는 라우트나 프록시이기 때문입니다. VPN 구성을 편집했다고 해서 둘 중 어느 것도 나타나지 않습니다. 이 간극이 바로 풀이 자체 클라이언트 사이에서는 완벽하게 작동하면서 다른 어디에서도 도달할 수 없는 이유입니다.

프록시 이웃 탐색은 두 세계를 연결할 수 있는 메커니즘입니다. 게이트웨이는 자신이 소유한 특정 클라이언트 주소에 대한 요청에 응답하고 트래픽을 터널로 전달합니다. 작동하며, 더 이상 서비스하지 않는 주소를 대신해 응답하면 다른 사람의 트래픽을 블랙홀로 만들기 때문에 풀을 따르는 수명 주기와 함께 정확히 그 주소로 범위를 제한해야 합니다. 일부 업스트림은 예상하지 못한 프록시 응답을 받아들이지 않으므로 이 설계에는 공급자의 동의도 필요합니다.

라우팅된 전달이 요구하는 것

더 깔끔한 설계는 업스트림이 실제로 게이트웨이로 라우팅하는 할당입니다. 그것은 위임된 프리픽스이거나 더 작은 블록에 대한 정적 라우트일 수 있으며, 요구 사항은 두 경우 모두 같습니다. 업스트림 테이블이 클라이언트 범위에 대해 서버를 가리켜야 하며, 그러면 반환 트래픽이 게이트웨이에 도착하고 게이트웨이가 그것을 터널로 전달합니다.

라우팅된 전달은 이웃 탐색 문제를 완전히 제거하므로 무언가 영리한 것을 만들기 전에 공급자에게 요청할 가치가 있습니다. 라우트를 서면으로 요청하고, 다음 홉이 업스트림이 실제로 도달할 수 있는 주소인지 확인하세요.

두 설계 모두 여전히 게이트웨이에서 IPv6 전달이 활성화되어 있어야 하고 전달된 흐름을 양방향으로 허용하는 방화벽 규칙이 필요합니다. 전달은 나머지 경로에 대한 전제 조건이지 대체물이 아닙니다. 전달이 꺼진 상태에서 작동하는 라우트는 라우트가 없는 것과 정확히 같은 침묵을 만들어 내므로 무엇이든 다시 설계하기 전에 둘 다 확인하세요.

제대로 맞춰야 할 두 개의 독립적인 라우트

풀 프리픽스와 클라이언트 자체의 기본 라우트는 별개의 설정이며, 이를 혼동하면 터널이 깨진 것처럼 보이는 부분 연결이 생깁니다. 풀은 서버에 어떤 주소를 배포할지 알려 줍니다. 클라이언트의 라우트는 클라이언트가 어떤 목적지로 트래픽을 터널에 보낼지를 결정합니다.

server-ipv6 2001:db8:42:100::/64
push "redirect-gateway ipv6 !ipv4"

위의 프리픽스는 문서화용 공간이며, 리디렉션은 IPv6에만 적용됩니다. 이는 IPv6 전달이 아직 수정되는 동안 듀얼 스택 배포가 흔히 원하는 바로 그 것이며, IPv4 리디렉션은 IPv6 커버리지를 확립하지 않고 어느 설정도 다른 설정을 함의하지 않습니다.

적용하는 정책에 관계없이 IPv6가 의존하는 제어 트래픽을 계속 작동시키세요. Packet Too Big 메시지는 TCP와 UDP만 허용하는 방화벽의 전형적인 희생자이며, 이를 버리면 연결은 설정되지만 더 큰 전송에서 멈추게 됩니다.

라우터 광고는 세 번째 가동 부품입니다. 게이트웨이가 업링크에서 광고를 시작하면 클라이언트와 이웃이 링크상 프리픽스에 대해 믿는 내용이 바뀔 수 있고, 이는 방금 문서화한 설계를 조용히 무효화할 수 있습니다.

재구축이 그것을 재현할 수 있도록 설계를 기록하세요

클라이언트 할당, 클라이언트의 목적지 라우트, 그리고 할당에 대한 업스트림의 전달 방식이라는 세 가지 객체를 따로 적으세요. 세 가지를 모두 가진 독자는 배포를 재구축할 수 있고, 풀 설정만 가진 독자는 원래 버그를 재현합니다.

그다음 외부에서 돌아와야 하는 패킷으로 반환 방향을 명시적으로 테스트하세요. openvpn(8) 매뉴얼은 server-ipv6와 redirect 옵션을 다루며, 공급자의 라우팅 확인은 매뉴얼이 다룰 수 없는 절반을 다룹니다.