사설처럼 보이는 주소는 대부분의 사람이 말하는 의미의 사설이 아니며, IPv6의 고유 로컬 주소 지정이 가장 분명한 사례다. ULA 프리픽스는 그 뒤에 있는 자원에 대해 VPN에 안정적인 내부 계획을 준다. 그것은 아무것도 암호화하지 않고, 피어를 인증하지 않으며, 클라이언트가 어떤 서비스에 도달할 수 있는지 결정하지 않는다. 프리픽스를 보안 통제로 취급하는 것이 이 글이 없애려는 실수다.

프리픽스가 실제로 제공하는 것

RFC 4193은 fc00::/7을 로컬 용도로 예약하며, L 비트는 로컬에서 할당한 공간을 예약된 형식과 구분한다. 실제로 생성하는 것은 fd00::/8이다. 명세는 또한 독립적인 사이트가 실수로 같은 프리픽스를 고르지 않도록 40비트 전역 ID를 도출하는 방법을 정의한다. 그 공간은 공용 인터넷 밖에 머물도록 설계되었으며, 이는 라우팅 속성이지 보호가 아니다.

사이트 내부의 일반적인 배치는 서브넷으로 나뉜 /48 전역 ID다. 터널 클라이언트용으로 하나, 서버 쪽으로 하나, 원격 LAN마다 하나씩이다. 그 구조가 이점의 전부이며, 그것은 주소 지정의 이점이다. 모든 패킷은 여전히 경로가 필요하고 여전히 이를 허용하는 정책이 필요하다.

프리픽스를 터널과 혼동하면 설계가 fd00 주소를 문서화하고 그 사이의 트래픽이 보호된다고 가정하게 된다. 다른 무엇인가 보호하지 않는 한 그렇지 않다.

예제 프리픽스를 복사하면 왜 곤란해지는가

모든 자습서가 기억하기 쉬운 프리픽스를 쓰고, 그것을 복사하는 모든 독자가 같은 충돌 위험을 물려받는다. 나중에 동일한 범위로 사이트 간 터널을 통해 연결되는 두 사이트는 겹치는 사설 IPv4 공간에서 알려진 바로 그 모호함을 만들어 낸다. 어느 쪽도 그 자체로 틀리지 않으며, 결합된 네트워크는 어느 목적지를 뜻하는지 알 방법이 없다.

문서화된 절차로 전역 ID를 생성하는 데는 잠깐이면 되고 그 질문은 사라진다. 주소 계획 옆에 프리픽스, 생성 입력, 날짜를 기록하라.

인수 후 네트워크를 합치거나 VPN으로 두 연구소를 연결하는 사람에게 이 위험은 이론적이지 않다. 단일 사이트에는 급하지도 않아서, 합병이 이미 예정된 뒤에야 미뤄 둔 것이 풀린다.

범위와 접근은 별개의 질문이다

ULA는 전 세계적으로 라우팅되는 일반 인터넷 주소 지정을 위한 것이 아니다. 그렇다고 해서 이를 쓰는 모든 호스트가 신뢰할 수 있는 것도 아니고, 다른 연결된 사설 네트워크에서 그 호스트에 도달할 수 없게 되는 것도 아니다. 방화벽과 응용 프로그램 권한이 여전히 피어가 무엇을 쓸 수 있는지 결정하며, 터널은 여전히 설정된 인증을 제공한다.

인터넷 출구에는 자체적인 IPv6 출구 설계가 필요하다. 클라이언트에 ULA 주소를 할당해도 임의의 전역 목적지에 대한 접근이 생기지 않으며, 그런 주소를 받은 클라이언트가 그것으로 공용 인터넷을 탐색할 것이라고 기대해서는 안 된다.

서로 다른 프리픽스를 가진 두 사이트는 여전히 상대 범위에 대한 반환 경로가 필요하고, 두 방화벽 모두 일치하는 규칙이 필요하다. 그중 어느 것도 주소 체계에서 나오지 않는다. 나오는 것은 문서화 작업이다. 프리픽스 표와 각각에서 응답이 허용된 시스템의 목록이다.

양쪽 끝에서 계획을 확인하라

프리픽스가 생각하는 곳에 나타나는지 확인하고, 그다음 어떤 목적지가 실제로 그것을 통해 도달 가능한지 확인하라.

ip -6 address show
ip -6 route show
ping -6 -c 3 fd12:3456:789a:1::1

주소 목록은 어느 인터페이스가 어느 서브넷을 가지는지 보여 주며, 잘못된 것을 받은 클라이언트는 보통 여기에서 그것을 드러낸다. 경로 목록은 원격 프리픽스가 버려지는 대신 터널을 통한 길을 가지는지 보여 준다. 시험은 중요한 유일한 질문, 즉 패킷이 왕복하는지에 답한다.

다시 연결한 뒤 확인을 반복하라. 주소를 유지하지만 경로를 잃은 클라이언트는 올라온 것처럼 보이면서 아무것도 전달하지 않는 연결을 만든다. 주소는 쉬운 부분이고, 사라지는 것은 경로다. 다음 비교가 증거에서 시작하도록 두 출력을 연결 프로필 이름 옆에 저장하라.

관련 글