듀얼 스택 VPN 풀: strongSwan에서 두 주소 체계를 모두 다루기

내부 IPv4와 IPv6 풀, 보호되는 프리픽스, 외부 터널의 주소 체계는 세 가지 별개의 결정입니다. 듀얼 스택이라고 부르기 전에 각각을 계획하십시오.

게이트웨이는 외부 터널이 여전히 IPv4 위로 지나가더라도 이동 사용자에게 IPv4와 IPv6 가상 주소를 모두 줄 수 있습니다. 이들은 독립적인 결정이며, 이를 하나로 취급하는 것이 듀얼 스택 계획이 보통 무너지는 지점입니다. 클라이언트의 내부 주소 체계, 도달할 수 있는 보호 프리픽스, 캡슐화를 운반하는 전송은 세 가지 별개의 선택입니다.

혼란의 대부분은 듀얼 스택이라는 말을 한 곳에서만 듀얼 스택인 설계에 적용할 때 생깁니다. 서비스는 내부적으로 듀얼 스택이고 외부 주소에서는 단일 스택이면서도 클라이언트에게 완벽하게 동작할 수 있습니다. 할 수 없는 것은 우연히 동작하는 것입니다.

안쪽에 두 체계, 바깥쪽에 한 경로

외부 연결은 UDP 위의 IKE이며, 클라이언트가 어디에 있든 그곳에서 도달 가능한 주소 체계 하나가 필요합니다. 내부 IPv6 주소는 IPv6를 지원하는 ISP를 요구하지 않습니다. 내부 패킷은 외부 패킷 안의 페이로드이기 때문입니다. 많은 운영 배포가 IPv6 프리픽스를 IPv4 전용 업링크로 운반합니다.

외부 경로가 실제로 제약하는 것은 도달 가능성과 NAT 통과입니다. 게이트웨이가 IPv4 주소만 광고하면, IPv6 전용 네트워크의 클라이언트는 어떤 풀을 구성했든 전혀 연결할 수 없습니다. 외부 주소 체계는 내부 주소 계획이 아니라 클라이언트 구성으로 결정하십시오.

각 체계에서 클라이언트에 주소를 주십시오

두 체계를 모두 요청하는 것은 클라이언트 쪽에서 한 줄이면 됩니다. 게이트웨이에 나눠 줄 것이 있다는 전제 아래에서요. 이름 있는 풀은 소스를 서비스 네트워크와 분리하며, 바로 이 성질이 여섯 달 후에도 방화벽 규칙을 읽을 수 있게 합니다.

pools {
  pool4 { addrs = 10.90.0.0/24 }
  pool6 { addrs = fd42:90::/64 }
}
connections {
  private-access {
    version = 2
    pools = pool4, pool6
    local  { auth = pubkey  certs = gateway.pem  id = vpn.example.com }
    remote { auth = pubkey  cacerts = ca.pem  vips = 0.0.0.0, :: }
    children {
      private { local_ts = 10.60.0.0/16, fd42:60::/48  remote_ts = dynamic }
    }
  }
}

이vips값은 각 체계에서 주소를 하나씩 요청하고, 풀 목록이 그 주소들이 어디서 오는지를 결정합니다.가상 IP에 관한 strongSwan 문서는 여러 요청과 풀 할당을 다루며, 특정 주소를 요청하는 클라이언트는 응답자가 무시할 수 있는 선호를 표현할 뿐이라는 점도 포함합니다. 클라이언트가 항상 같은 값을 받는다고 가정하는 접근 규칙을 만들지 마십시오.

예제를 복사하지 말고 고유한 로컬 프리픽스를 직접 생성하십시오. 둘 다fd42::/16도입한 두 조직은 처음 상호 연결할 때 충돌을 발견하게 되며, 그것을 진단하는 일은 유쾌하지 않습니다.

선택자는 목적지를 설명하고 소스를 설명하지 않습니다

자식 SA의 로컬 트래픽 선택자는 게이트웨이 뒤에 어떤 보호 네트워크가 있는지 말하고, 원격 선택자는 클라이언트가 소스로 무엇을 쓸 수 있는지 설명합니다. 가상 풀 주소는 그 정책의 소스 쪽에 속합니다. 그것을 목적지 목록에 넣는 것은 구성의 흔한 오독입니다.

두 체계 모두 게이트웨이에서 반환 경로와 허용된 포워딩이 필요합니다. 풀로 돌아가는 경로 없이 선택자에 프리픽스를 추가하면, 설정은 되지만 한 방향 트래픽만 통과시키고 응답을 조용히 버리는 터널이 됩니다. 선택자는 정책이지 라우팅이 아닙니다.

풀과 서비스 프리픽스를 주소 계획의 별도 블록에 두십시오. 둘이 겹치면 보호 호스트에 도달해야 할 경로가 풀 주소와 일치해 터널 안으로 사라질 수 있습니다.

DNS와 응답 경로가 완성된 느낌인지를 결정합니다

리졸버 응답은 리졸버에 도달하는 데 쓰는 전송과 무관합니다. 이름은 A 레코드, AAAA 레코드 또는 둘 다를 반환할 수 있고, 클라이언트는자신의 선호 규칙에 따라 선택합니다. 내부 서비스가 AAAA 레코드를 게시하지만 아무것도 그 프리픽스를 라우팅하지 않으면, 듀얼 스택 네트워크의 클라이언트는 먼저 IPv6 경로를 시도하고 실패할 때까지 거기 머뭅니다. 그동안 터널 구성에서 잘못되어 보이는 것은 없습니다.

그러므로 이름마다 어떤 체계를 사용할 수 있어야 하는지 결정하고, 해당 프리픽스가 선택자에 있고 반환 경로가 있는지 확인하십시오. 서비스별 결정입니다. 두 레코드 유형을 일괄 게시하는 것이 바로 IPv4 전용으로 잘 동작하던 서비스가 사용자의 절반에게 시간 초과를 내기 시작하는 방식입니다.

완료라고 부르기 전에 두 체계를 검증하십시오

로드되는 구성은 동작하는 구성이 아닙니다. 데몬이 보고하는 상태를 읽고, 풀 할당을 확인한 다음, 클라이언트가 실제로 설치한 경로를 보십시오.

swanctl --list-sas
swanctl --list-pools
ip -6 addr show scope global
ip -6 route get fd42:60::10

처음 두 명령은 설정된 자식 SA와 아직 주소가 남은 풀을 보여 주므로, 첫 클라이언트에서는 동작하고 열 번째에서 실패하는 계획이 드러납니다. 마지막 두 명령은 클라이언트가 풀에서 전역 IPv6 주소를 받았는지, 보호 프리픽스로 가는 트래픽이 실제로 어디로 가는지를 보여 줍니다. 할당된 주소를 기대했던 주소가 아니라 구성한 풀과 비교하십시오. 응답자가 정책에 따라 다른 값을 골랐다면, 경로와 방화벽 규칙은 여전히 그 선택과 맞아야 합니다.

그다음 체계마다 보호 호스트를 하나씩 시험하고, 둘 다로 해석되는 이름을 시험하십시오. 단일 체계 시험은 연습하지 않은 계획의 절반에 대해 아무것도 알려 주지 않으며, 빠진 경로는 보통 그 절반에 있습니다.

관련 글