VPN을 통한 IPv6: 위임된 프리픽스는 주소 풀이 아닙니다

같은 날, 터널을 통한 IPv6가 필요한 노트북과 자체 라우터 뒤의 장치에 IPv6를 원하는 작은 사이트로부터 두 건의 요청이 들어옵니다. 둘 다 주소로 답을 받지만, 두 번째는 그 뒤 일주일을 실패로 보냅니다. 역할이 다르고, 메커니즘과 구성, 작동을 증명하는 점검도 다릅니다. 이 안내서는 둘을 분리해 둡니다.

첫 번째 단계: 어떤 역할을 맡고 있는지 결정하십시오

단일 호스트에는 터널 인터페이스의 주소 하나와 원격 측으로 가는 경로가 필요하며, 아래쪽에 번호를 부여할 것은 없습니다. 터널 뒤의 라우터에는 분배할 수 있는 전체 네트워크와, 원격 측에서 그 주소를 자신에게 되돌려 보내는 경로가 필요합니다. 터널 뒤에 무엇이 있는지가 이후의 모든 결정을 좌우합니다.

어떤 구성이든 열기 전에 그 질문에 답하십시오. 이 단계 이후의 모든 것은 어떤 답을 했는지에 달려 있습니다.

두 번째 단계: 단일 호스트의 주소 할당

터널 주소를 할당하고, 제품이 기대하는 프리픽스 길이를 확인하며, 클라이언트가 원격 범위에 대한 경로를 설치하는지 아니면 로컬 기본 게이트웨이로 보내는지 점검하십시오. 터널 인터페이스의 /128은 지점 간 링크에서 정상이지만, 그곳의 /64는 아무도 위임하지 않은 네트워크를 주장하는 셈입니다. 질문을 정리하는 출력은 두 가지, 양쪽 끝에서 읽는 주소 테이블과 라우팅 테이블입니다. 잘못된 인터페이스를 가리키는 경로가 이 단계에서 가장 흔한 실수이므로, 두 표를 함께 읽으십시오.

양쪽 끝의 주소 및 라우팅 테이블로 확인한 뒤 요청을 하나 보내십시오. 요청이 올바르게 나가고 아무것도 돌아오지 않으면, 결함은 클라이언트 주소가 아니라 원격 측 경로에 있습니다.

세 번째 단계: 터널 뒤 라우터를 위한 위임

프리픽스 위임은 주소 할당과는 별개의 메커니즘으로, 자체 요청과 자체 임대가 있습니다. 위임하는 측은 하위 네트워크에 충분히 큰 프리픽스를 내주도록 구성되어야 하고, 요청하는 라우터는 그 프리픽스로 내부 인터페이스에 번호를 부여해야 합니다.

모바일 클라이언트를 처리하는 풀이 위임할 수 있다고 가정하지 마십시오. 많은 VPN 제품은 단일 주소만 할당하고 위임 역할이 전혀 없으며, 경계에 도착한 공급자 프리픽스가 피어로 자동 전달되지도 않습니다. 둘은 서로 다른 곳에서 구성되므로, 각 풀이 어떤 역할을 맡는지 기록하십시오.

네 번째 단계: 반환 경로를 명시하십시오

양쪽 끝은 어느 피어가 어느 프리픽스를 나르는지 합의해야 합니다. 원격 측에서 위임된 네트워크의 경로를 터널 쪽으로 추가하고, 겹치는 범위가 이미 그것을 주장하지 않는지 확인하십시오.

반환 경로가 없는 유효한 프리픽스는 깔끔한 주소 계획과 연결 불가라는 결과를 낳습니다. 접근 규칙이 없는 경로는 의도한 것보다 사이트를 더 많이 노출하므로, 두 변경을 같은 작업 창에서 묶고 절반만 적용된 상태를 사용자에게서 멀리 두십시오.

다섯 번째 단계: 라우터 뒤에서 확인하십시오

점검은 클라이언트의 터널 인터페이스 주소, 내부 인터페이스의 위임된 프리픽스, 그 프리픽스를 향한 원격 측 경로, 마지막으로 라우터 뒤 장치에서의 요청 순서로 수행하십시오. 통제하는 목적지를 사용해 조용한 차단과 누락된 경로를 구분하십시오. 어느 단계에서 놀라더라도, 다음으로 넘어가기 전에 고칠 것은 바로 그 지점입니다.

마지막 점검은 라우터 자체에서 한 번, 그 뒤의 장치에서 한 번, 두 번 하십시오. 목적지에 도달하지만 클라이언트는 도달하지 못하는 라우터는 위임이나 전달의 문제이지, 상위의 문제가 아닙니다.

되돌리기

변경 전에 이전 주소 구성을 보관하고, 두 메커니즘 중 어느 것을 바꿨는지 적어 두십시오. 경로를 남긴 채 위임된 프리픽스를 제거하면 검은 구멍이 남고, 프리픽스를 남긴 채 경로를 제거하면 아무것도 닿을 수 없는 주소가 남습니다. 하나를 되돌리고 다른 하나를 남기면 사이트가 한 방향으로만 도달 불가능해지므로, 두 변경을 따로 적으십시오.

제품이 필요한 역할을 지원하지 않는 것으로 드러나면, 결코 의도되지 않은 범위를 담기 위해 클라이언트 필드를 늘리는 대신 멈추고 설계를 바꾸십시오. 잘못된 메커니즘으로 답한 지원 사례는 설계 변경보다 더 큰 비용을 치르게 합니다.