DS-Lite는 인바운드 IPv4 호스팅을 막고, 아웃바운드 VPN은 막지 않는다

변환 상태는 연결을 시작하는 쪽을 따릅니다. B4와 AFTR을 거치는 아웃바운드 요청을 따라가고, 호스팅이 왜 실패하는지 확인하십시오.

DS-Lite는 IPv6만 전달하는 액세스 망을 통해 고객에게 IPv4 연결성을 제공하는 방법입니다. 가정용 공유기에는 자체 전용 공인 IPv4 주소가 없고, 그 한 가지 사실만으로 사람들은 그 연결에서 IPv4 VPN이 동작할 수 없다고 믿습니다. 아웃바운드 방향에서는 보통 잘 동작합니다. 통신 사업자가 연결을 변환하고, 원격 쪽은 평범한 IPv4 클라이언트를 봅니다. 깨지는 것은 반대 방향입니다. 요청되지 않은 인바운드 IPv4를 기대하는 무언가를 호스팅하는 경우입니다. 차이는 어느 쪽이 대화를 시작하느냐에 있습니다.

어느 쪽이 연결을 시작하는가

연결을 시작하는 클라이언트는 진행하면서 변환 상태를 만듭니다. 사업자의 변환기는 첫 패킷을 보고 매핑을 할당해 전달합니다. 반환 트래픽은 이미 매핑이 존재하기 때문에 그 매핑과 일치합니다.

연결을 기다리는 서버에는 만들 그런 상태가 없습니다. 외부의 누군가가 사업자가 매핑에 동의하지 않은 주소와 포트에 도달해야 하며, 이는 전혀 다른 요청입니다.

아웃바운드 요청을 따라가기

아키텍처는 RFC 6333 에서 양쪽 끝을 명명합니다. 고객 쪽 요소는 B4로, IPv4를 IPv6 안에 캡슐화합니다. 사업자 쪽 요소는 AFTR로, 주소 변환을 수행하고 패킷을 IPv4로 전달합니다.

Client's IPv4 VPN packet
  → Customer B4
  → IPv4 carried over the provider's IPv6 network
  → AFTR address translation
  → IPv4 VPN server

VPN 서버는 사업자의 변환된 주소에서 정상적인 IPv4 연결을 받습니다. DS-Lite 모드도, 특별한 포트도, 고객의 액세스 망이 IPv6뿐이라는 사실을 알 필요도 없습니다. 사람들이 놓치는 부분이 바로 이것입니다. 원격 쪽은 알 수 없습니다.

클라이언트 자체의 구성도 똑같이 평범합니다. B4와 AFTR이 제공하는, 서버까지 이어지는 동작하는 IPv4 경로가 필요하고, 서버의 호스트 이름이 IPv4 주소로 해석되어야 합니다.

인바운드 호스팅이 실패하는 경우인 이유

집에서 IPv4 VPN 서버를 운영하는 것은 사업자의 공유 주소 지정과 충돌하는 설계입니다. 사업자의 변환기가 공인 주소와 매핑 테이블을 소유하며, 가입자 한 명을 위해 영구적인 인바운드 매핑을 만들 이유가 없습니다.

가정용 공유기의 포트 포워딩 규칙은 AFTR을 구성할 수 없습니다. 그 규칙은 로컬 장치에서는 실제로 올바르지만 업스트림에서는 아무것도 바꾸지 않습니다. 그래서 증상이 사라지지 않는 방화벽 문제처럼 보입니다.

여기서 통신 사업자 수준의 변환이 단일 공인 주소와 달라집니다. 올바른 로컬 포워딩조차 여러 가입자가 공유하는 주소에 떨어질 수 있습니다.

액세스 요금제를 바꾸기 전에 진단하십시오

먼저 프로비저닝된 모드를 확인하십시오. 네이티브 듀얼 스택, DS-Lite, 다른 변환 메커니즘을 쓰는 IPv6 전용 망은 서로 다른 세 가지 구성이며, 사업자의 마케팅 이름이 기술적 이름과 항상 일치하지는 않습니다.

다음으로 아웃바운드 장애에 대한 네 가지 관찰을 세우십시오. 클라이언트가 VPN 호스트 이름을 IPv4 목적지로 해석하는가? 브라우저 요청이 아니라 순수 IPv4 연결이 동작하는가? 그 요청은 조용히 IPv6를 썼을 수 있습니다. 클라이언트가 어떤 전송과 포트를 시도하며, 엔드포인트 로그에 그 시도가 보이는가? 장애가 초기 교환 중에, 유휴 기간 후에, 아니면 큰 전송에서만 일어나는가?

이 네 가지 답은 필터링, 변환 상태 만료, 잘못된 엔드포인트, 패킷 크기 처리를 가리킵니다. 계정 페이지에서 DS-Lite를 보는 것으로는 어느 것도 확정되지 않습니다.

사업자의 변경 사항을 주의 깊게 읽으십시오

계정 변경은 여러 속성을 한꺼번에 바꾸면서 동작하는 연결과 겹칠 수 있습니다. 어떤 속성이 바뀌었는지 기록하십시오. 새 요금제 이름은 기술적 설명이 아닙니다.

듀얼 스택을 활성화하라는 지시는 사업자가 실제로 무엇을 프로비저닝하는지 누군가 확인하기 전까지 모호합니다. 이를 IPv4 VPN 클라이언트 전반의 요구 사항으로 취급하면 추측이 정책이 됩니다.

실제 요구가 인바운드 IPv4 호스팅이라면 사업자와 지원되는 인바운드 구성, 네이티브 주소 지정 또는 다른 액세스 설계를 논의하십시오. 요구가 원격 서버에 도달하는 노트북이라면 대신 그 정확한 아웃바운드 흐름을 물으십시오. 작업 순서는 방향을 명명하고, 프로비저닝된 모드를 확인하고, 순수 IPv4와 하나의 전송을 시험한 뒤, 방향이 정말로 요구할 때만 액세스 요금제를 바꾸는 것입니다.

관련 글