VPN 구성에서 IPv6 엔드포인트를 작성하는 방법

IPv6 주소는 콜론으로 가득 차 있고, 포트까지 담는 엔드포인트 필드에는 주소가 어디서 끝나는지 표시할 방법이 필요합니다. 여기를 틀리면 클라이언트가 프로필 파싱을 거부하거나 조용히 엉뚱한 대상에 연결합니다. 올바른 형식은 보편적이지 않으며, 필드가 주소와 포트를 담는지, 주소만 담는지, 호스트 이름인지에 따라 달라집니다. 클라이언트 출력을 읽기 시작하면 구문 수정과 도달 가능성 수정이 전혀 다르게 보이므로, 안내서를 순서대로 따라가십시오.

주소를 입력하기 전에 필드 유형을 확인하십시오

예를 들어 WireGuard Endpoint 필드에서는 포트가 있는 IPv6 리터럴이 주소를 대괄호로 감싸며, [2001:db8::10]:51820 처럼 씁니다. 그 예의 문서용 접두사는 공용 서버가 아니며, 대괄호는 구문의 일부이고 주소의 일부가 아닙니다.

다른 형식에는 자체 규칙이 있습니다. URI는 IPv6 리터럴을 대괄호에 담아 가질 수 있지만, VPN 구성이 반드시 URI인 것은 아닙니다. 주소와 포트 칸이 따로 있는 클라이언트는 한 칸에 리터럴만, 다른 칸에 숫자를 기대할 수 있으며, 거기에 대괄호를 더하는 것은 통합 필드에서 빼는 것만큼 잘못입니다.

포트가 같은 필드를 공유하면 리터럴을 대괄호로 감싸십시오

기억할 규칙은 단순합니다. 같은 문자열에서 포트가 뒤따르면 대괄호가 나타나고, 포트가 없는 필드에 주소가 홀로 있으면 나타나지 않습니다.

한 프로토콜의 엔드포인트 문자열 전체를 모든 클라이언트에 복사하는 것이 이 오류의 흔한 원인입니다. OpenVPN, IPsec 프로필, 애플리케이션 인터페이스는 각자 자기 구문을 문서화하며, 한쪽에 맞는 문자열이 다른 쪽에서 거부되거나 잘못 해석될 수 있습니다. 편집하는 필드에 대해서는 클라이언트 자체 문서를 읽고, 문서용 접두사나 예시 주소는 주석에 남겨 아무도 실제 호스트로 내보내지 않게 하십시오. 설명서가 두 가지 형식을 제시하면 앞에 있는 필드 유형에 맞는 쪽을 쓰십시오.

주소 칸과 포트 칸을 분리하십시오

클라이언트가 칸을 두 개 주면 주소를 한 칸에, 포트를 다른 칸에 넣으십시오. 주소 칸에 붙여 넣은 통합 형식은 파싱 오류를 내거나, 더 나쁘게는 의도하지 않은 대상으로 해석되는 주소를 만듭니다.

값이 맞아 보일 때는 끝의 공백과 보이지 않는 문자를 확인하십시오. 복사한 주소에는 줄바꿈 없는 공백이나 폭이 없는 문자가 붙어 있어 클라이언트가 파싱하지 못하고 화면에도 보이지 않는 경우가 많습니다. 오류가 이해되지 않으면 붙여 넣지 말고 값을 다시 입력하십시오.

영역 식별자를 조심해서 다루십시오

링크 로컬 리터럴에는 인터페이스에 묶인 영역 식별자가 필요할 수 있으며, 퍼센트 기호와 인터페이스 이름으로 씁니다. 그 형식은 인터페이스를 소유한 호스트에서 유효하며, 일반적으로 도달 가능한 원격 엔드포인트를 대신하지 못합니다.

파싱이 성공한 뒤에도 범위와 라우팅은 중요합니다. 클라이언트가 받아들이는 영역 한정 주소에 그 머신에서 나가는 경로가 없을 수 있고, 인터넷을 거쳐 도달하는 원격 엔드포인트는 로컬 영역에 전혀 의존해서는 안 됩니다. 핸드셰이크가 실패한 뒤가 아니라 영역을 쓰기 전에, 패킷이 어느 인터페이스로 나가야 하는지 정하십시오.

파싱을 확인하고, 다음으로 도달 가능성을 확인하십시오

두 실패를 분명히 나누십시오. 망가진 주소는 파싱 오류나 즉시 거부를 낳지만, 제대로 만들어진 엔드포인트가 인증을 거부하거나 응답하지 않는다면 다른 해법이 필요한 다른 문제입니다.

지원되는 수정 뒤에 터널이 협상되고 의도한 애플리케이션이 동작하는지 확인하십시오. 핸드셰이크만으로는 경로를 증명하지 못하며, 엔드포인트로 보내는 ping도 터널을 증명하지 못합니다. 운영자가 호스트 이름을 제공하면 지원되는 이름과 그 신원 확인을 유지하고, 다른 곳에서 찾은 숫자 주소로 바꾸지 마십시오.

변경 노트에 정확한 필드, 사용한 값, 클라이언트의 응답을 기록하십시오. 그러지 않으면 프로필을 편집하는 다음 사람이 대괄호 실험을 되풀이할 것이고, 답은 이미 티켓에 있습니다.