IPv4 VPN 서버를 거치는 IPv6에도 여전히 실제 IPv6 출구가 필요하다

터널은 올라오고, 클라이언트는 풀에서 IPv6 주소를 받지만, 그래도 모든 IPv6 목적지는 시간 초과가 납니다. 터널 안에서 고장 난 것은 없고, IPv6는 IPv4 전송 안에서 아주 잘 달리며, 그것은 결코 어려운 부분이 아니었습니다. 당신이 나눠준 주소는 출구에 그것을 보낼 IPv6 업스트림이 없기 때문에 서버가 지킬 수 없는 약속입니다. 고칠 곳은 출구이지 클라이언트 프로필이 아닙니다.

증상: 주소는 있는데 경로가 없다

클라이언트 쪽 확인은 터널 장치에 전 세계적으로 보이는 IPv6 주소와 그리로 향하는 경로를 보여 주므로, 이것이 클라이언트 버그로 잘못 읽힙니다. 트래픽은 터널로 들어가고, 서버가 캡슐화를 풀고, 그다음 패킷은 라우팅 테이블에 실제 장소로 가는 IPv6 기본 경로가 없는 호스트에 도착합니다. 스택에 따라 즉시 도달 불가가 되거나 조용히 버려지며, 어느 경우든 클라이언트는 방화벽과 똑같이 보이는 시간 초과를 봅니다.

경로에서 빠진 절반이 바로 거기에 있으므로, 클라이언트를 건드리기 전에 서버 자체의 라우팅 테이블을 읽으십시오. IPv4 기본 경로가 하나뿐인 서버는 이미 답을 준 것입니다.

캡슐화를 푼 뒤 패킷을 따라가라

터널 안에서 패킷은 평범한 IPv6이고 그 출발지는 클라이언트 주소입니다. 서버는 전송 캡슐화를 벗겨 내고, 그다음 IPv6 넥스트 홉으로 전달해야 하는 네이티브 IPv6 패킷을 들고 있습니다. IPv4 기본 경로는 그것을 나를 수 없고, 그것을 IPv4로 변환하는 것은 아무도 배치하지 않은 다른 기능입니다. 이것이 실패의 전부이며, VPN 리스너가 IPv4로 응답했는지와는 아무 관계가 없습니다.

IPv6 over IPv4 캡슐화의 원리는 RFC 4213에 설명되어 있고, 그곳의 중요한 세부 사항은 양 끝점에 터널 반대편의 실제 IPv6 연결이 여전히 필요하다는 것입니다. 헤더를 감싼다고 업스트림이 생기지 않습니다.

터널 계층 둘, 독립된 확인 둘

동작하는 바깥 터널은 고장 난 안쪽 터널을 가리므로, 각 계층을 따로 검증하십시오. 바깥 경로는 클라이언트에서 서버로 IPv4 핑으로 확인하고 사용하는 포트를 확정한 뒤, 서버에서 안쪽 경로를 확인하십시오. 그곳에서 ip -6 route 실제 업스트림에서 배운 기본 경로나 특정 경로를 보여 주어야 하고, ip -6 addr 업스트림이 받아들이는 소스 프리픽스를 보여 주어야 합니다. 그보다 못한 것은 인터페이스 위의 장식일 뿐입니다.

유일-로컬 주소나, 아무것도 되돌아 라우팅하지 않는 전 세계적으로 보이는 프리픽스는 기꺼이 인터페이스에 나타나서 아무 데도 가지 않습니다. 공인 도달성은 업스트림이 주는 것이지 주소의 모양이 주는 것이 아닙니다.

클라이언트에도 같은 말이 적용됩니다: ip -6 route get 2001:4860:4860::8888 터널 장치를 가리켜야 하고, 물리 장치를 가리킨다면 클라이언트는 IPv6에 VPN을 전혀 쓰지 않는 것입니다.

소스 프리픽스, 크기, ICMPv6

업스트림에 전달을 위해 어떤 소스 프리픽스를 받아들일지 물어보고, 그중 하나를 클라이언트 풀에 쓰십시오. 서버 자체의 인터페이스에 /64를 주는 제공자가 두 번째 /64나 더 큰 블록을 당신에게 라우팅한다고 보장할 수 없고, 그 차이는 지원 티켓이 질문 하나로 정리하는 반나절의 디버깅입니다. 서면으로 물어보고 답변을 설정과 함께 보관하십시오.

스택이 실제로 쓰는 추가 캡슐화를 예산에 넣고, Packet Too Big을 포함해 ICMPv6를 계속 동작시키십시오. 두 번째 헤더는 쓸 수 있는 페이로드를 줄이므로 작은 핑에 응답하는 경로도 파일 전송에서는 실패할 수 있고, 모든 ICMPv6를 버리는 방화벽은 고칠 수 있는 크기 문제를 블랙홀로 만듭니다. 서비스를 알리기 전에 큰 전송 하나를 시험하십시오.

완전히 다른 문제란

IPv4만 쓰는 애플리케이션에 IPv6만 쓰는 클라이언트에서 도달하는 것은 터널링이 아니라 변환이며, 의도적으로 배치한 NAT64 같은 것이 필요합니다. 목적지는 당신이 터널 헤더를 하나 더 넣었다고 해서 그것을 이해하지 않습니다. 역사적인 전환 서비스도 같은 주의를 받을 자격이 있으며, RFC 7526은 6to4 anycast 릴레이 모델을 폐기했으므로, 그것을 전제로 쓴 안내서는 더 이상 유지 관리되는 공개 릴레이가 없는 것을 설명합니다.

서버에 쓸 만한 IPv6 업스트림이 없다면 선택지는 지원되는 업스트림, 다른 출구, 또는 IPv6를 터널 밖에 두기로 한 문서화된 결정입니다. 받아들일 수 없는 것은 IPv6 서비스가 있다고 클라이언트에게 말하면서 그들의 평범한 IPv6 연결이 조용히 VPN을 우회하게 두는 것입니다.