OpenVPN 랩에 사설 IPv6 추가하기, 한 번에 체크포인트 하나씩

이미 IPv4로 접속해 서버 뒤의 사설 IPv4 워크로드에 도달하는 클라이언트가 있습니다. 목표는 바깥 전송을 건드리지 않고 같은 터널로 사설 IPv6 워크로드에 도달하는 것입니다. 이 순서가 중요합니다. 바깥 경로는 IPv4로 남고 안쪽 주소 계획, 클라이언트 경로, 서버에서 LAN으로 돌아오는 경로만 바뀝니다. 체크포인트 다섯 개, 각각 넘어가기 전에 확인할 구체적인 것이 있습니다.

체크포인트 하나: 이미 동작하는 연결

무엇을 더하기 전에 클라이언트를 접속시키고 IPv4 경로를 확인합니다. 동작하는 터널은 새 IPv6 실수를 오래된 연결 문제와 분리하는 기준선이 됩니다. 또한 지금 실제로 편집하는 서버 인스턴스가 무엇인지도 알려 줍니다.

이미 의존하는 풀, 토폴로지, 푸시되는 경로를 적어 둡니다. IPv6 작업은 그 구성을 확장할 뿐 대체하지 않습니다.

체크포인트 둘: 안쪽 프리픽스 고르기

사이트에 ULA /48 하나를 고르고 거기서 /64 두 개를 잘라 냅니다. 하나는 터널 클라이언트용, 하나는 IPv6 워크로드가 있는 LAN 세그먼트용입니다. 예시 프리픽스를 복사하지 말고 40비트 전역 ID를 생성하십시오, 그리고 두 서브넷을 사이트가 이미 라우팅하는 모든 네트워크와 대조하십시오:

Outer transport: IPv4 OpenVPN UDP
IPv4 pool:       10.90.0.0/24
IPv6 VPN pool:   fd73:93bc:b6e9:77::/64
IPv6 LAN:        fd73:93bc:b6e9:60::/64
Server LAN IPv6: fd73:93bc:b6e9:60::1

독립적인 /64 두 개는 클라이언트 풀이 LAN 세그먼트에서 잘려 나가지 않게 합니다. 나중에 되돌아오는 경로를 쓸 때 중요합니다. 위 값은 한 번 계산한 예시이며 다시 쓸 프리픽스가 아닙니다.

체크포인트 셋: 도우미와 경로 푸시 더하기

무엇을 덧붙이기 전에 현재 서버 구성을 읽습니다. 기존 지시문의 두 번째 사본은 첫 번째와 합쳐지지 않고, 나오는 오류는 IPv6가 아니라 지시문 이름을 댑니다. 기존 IPv4 도우미가 있으면 두 줄이 그것을 확장합니다. 각각 다른 질문에 답합니다:

server-ipv6 fd73:93bc:b6e9:77::/64
push "route-ipv6 fd73:93bc:b6e9:60::/64"

첫 줄은 인터페이스와 클라이언트 풀을 설정하는 편의 도우미입니다. 둘째 줄은 클라이언트가 도달해야 할 LAN 목적지를 지정합니다. 클라이언트에 IPv6 주소를 줘도 서버 뒤에 어떤 네트워크가 있는지는 알려 주지 않으므로 두 줄이 모두 필요합니다.

이 도우미는 정적 IPv6 풀이나 nopool와 함께 존재하지 않습니다. 배포가 의도적으로 주소를 정적으로 할당한다면 그 정책을 유지하고, 예시에 맞추려고 정책을 지우는 대신 IPv6 대응물을 명시적으로 설계하십시오.

체크포인트 넷: 포워딩과 응답 경로

서버의 IPv6 포워딩은 잊어버릴 일회성 런타임 기록이 아니라 시스템 자체의 구성 관리자를 통해 켭니다. 런타임 형태는 빠른 시험에 유용합니다. 영구 구성은 배포판의 네트워크 관리자가 읽는 drop-in 파일에 들어갑니다:

sysctl -w net.ipv6.conf.all.forwarding=1

포워딩은 패킷 라우팅을 넘어 호스트의 IPv6 동작을 바꿉니다. 클라이언트로서 라우터 광고를 받아들이던 호스트는 포워딩을 시작하는 순간 같은 방식으로 받지 않습니다. 따라서 IPv6 업링크가 RA에 의존하는 기계는 그 업링크에 대한 명시적 계획이 필요합니다.

그다음 LAN에 터널 풀로 돌아가는 경로를 줍니다. 워크로드의 IPv6 게이트웨이는 VPN 서버가 아니라 LAN 라우터이므로 경로는 그 라우터에 있고 서버의 LAN 주소를 가리킵니다:

ip -6 route add fd73:93bc:b6e9:77::/64 via fd73:93bc:b6e9:60::1

링크에 필요한 ICMPv6 유형을 경로 MTU 피드백까지 포함해 유지하십시오. IPv4 방화벽 규칙이 IPv6 규칙을 뜻하지는 않으며, IPv6를 전면 차단하면 이웃 탐색이 깨져 라우팅 결함처럼 보입니다.

체크포인트 다섯: 클라이언트를 읽고, 그다음 시험

클라이언트를 다시 연결하고 서버의 도우미 주소에서 추론하지 말고 실제로 받은 주소를 읽습니다. 인터페이스 목록은 같은 장치에 두 체계를 모두 보여 줍니다:

ip -6 addr show tun0
ip -6 route get fd73:93bc:b6e9:60::20

터널을 고르는 경로는 클라이언트가 패킷을 어디로 보낼지 안다는 것을 증명합니다. 서버가 그것을 포워딩하는지, LAN 라우터에 되돌아오는 경로가 있는지, 애플리케이션이 응답해도 되는지는 증명하지 않습니다.

애플리케이션 자체를 각 체계에서 번갈아 시험하고, 다시 연결한 뒤와 호스트 재시작 뒤에 반복하십시오. 재부팅까지만 사는 경로나 sysctl은 시험이지 설계가 아닙니다.

AAAA 레코드는 IPv6 경로가 끝에서 끝까지 응답한 뒤에만 게시하십시오. IPv4로 질의한 DNS도 여전히 IPv6 주소를 돌려줄 수 있으므로 이름이 해석된다고 해서 무언가 듣고 있다는 증거는 아닙니다. RFC 4193 ULA 지침 은 이 프리픽스를 복사본이 아니라 여러분의 것으로 만드는 전역 ID 생성를 다룹니다.