숫자가 깔끔해 보여서 고른 클라이언트 풀은 설치를 기다리는 경로입니다. VPN이 동작하는 데 프리픽스가 사설일 필요는 없고, 다른 사람의 블록을 쓰는 것도 사용자를 자동으로 인터넷에 노출하지 않습니다. 그것이 하는 일은 터널이 올라와 있는 동안 그 주소들이 다른 의미를 갖게 하고, 터널이 끊기면 다시 또 다른 의미를 갖게 하는 것입니다. 아래 다섯 가지 점검을 순서대로 진행하고 답이 «다른 곳에 할당됨»인 지점에서 멈추십시오.

할당은 공지가 아니다

터널 인터페이스에 주소를 올린다고 해서 인터넷에 공지되는 것은 아닙니다. 공용 도달성에는 경로, 승인된 경로, 그리고 그것을 운반할 의사가 있는 사업자가 필요하며, 클라이언트가 풀에서 주소를 받았다고 해서 그중 어느 것도 생기지 않습니다. 방화벽 정책과 호스트 승인은 다시 별개의 결정입니다.

그래서 위험은 대부분이 짐작하는 것과 다릅니다. 빌려온 프리픽스는 클라이언트를 도달 가능하게 만들지 않고, 다른 사람의 목적지를 클라이언트에서 도달 불가능하게 만듭니다. 이는 소유자가 다른 또 다른 고장입니다. 공격을 받지도 않고 어떤 공지도 새지 않습니다. 사용자는 어제까지 되던 사이트를 그냥 열 수 없고, 헬프데스크가 VPN 풀을 의심할 이유는 없습니다.

풀을 고를 때 이 구분이 중요합니다. 유일한 걱정이 인터넷 노출이라면 아무것도 공지하지 않는 공용 블록이 안전해 보일 것입니다. 걱정거리는 클라이언트가 그 프리픽스에 대해 설치하는 로컬 경로이고, 그 경로는 다른 사람이 보든 보지 않든 설치됩니다.

클라이언트 경로가 실제로 붙잡는 것

터널이 올라오면 클라이언트는 풀의 프리픽스에 대한 경로를 받고, 그 경로는 그 안의 모든 목적지에 대해 기본 경로를 이깁니다. 그 블록에 있는 정당한 호스트로 가는 요청은 이제 인터넷이 아니라 VPN으로 갑니다. 그것이 실패하는지, 멈추는지, 잘못된 서버에 닿는지는 여러분 쪽이 그것을 어떻게 다루는지에 달려 있습니다.

ip route get 198.51.100.20
ip -br addr show tun0
traceroute -n 198.51.100.20

터널을 올린 상태로 조회를 실행하고, 내린 상태로 다시 실행하십시오. 주소는 첫 경우에 한 가지를, 둘째 경우에 전혀 다른 것을 뜻하며, 그 전환을 가로질러 연결이나 이름 해석을 캐시한 애플리케이션은 일관성 없이 동작합니다. 그 불일치는 깨끗한 실패보다 지원하기 어렵습니다. 시점에 의존하기 때문입니다. 잘못된 순간에 다시 연결하는 사용자는 그렇지 않은 사용자와 다른 경험을 합니다.

익숙한 IP 주소가 신원 증명이 아닌 것도 같은 이유입니다. 실제 목적지에 대해서는 인증서와 서버 이름 검증을 유지하십시오. 오 분 전에 도달한 숫자 주소가 이제 다른 대화의 것일 수 있습니다.

풀을 아는 모든 네트워크와 비교하십시오

RFC 1918은 사설 사용을 위해 세 개의 블록을 남겨 둡니다: 192.168.0.0/16, 172.16.0.0/12, 10.0.0.0/8입니다. 수백만 개의 별개 조직이 이를 재사용하므로 사설은 할당에 관한 진술이며 아무도 같은 숫자를 고르지 않았다는 약속이 결코 아닙니다.

후보 풀을 사무실 LAN, 클라우드 VPC, 다른 VPN 풀, 파트너 링크, 재택 근무자가 집에서 가질 법한 범위와 비교하십시오. 집의 사정은 이상한 프리픽스를 발명할 이유가 아니라 풀을 작고 문서화된 상태로 유지할 이유입니다.

할당은 라우팅을 소유한 사람과 조정하고, 반환 경로는 같은 곳에 기록하십시오. 아무도 되돌려 라우팅할 수 없는 풀은 장애 때 다시 발견될 풀입니다. 풀은 사이트 범위와 같은 문서에 두고, 한 사람만 편집한 클라이언트 설정에 두지 마십시오. 다음 충돌을 피할 수 있게 하는 것은 문서입니다.

공용 주소 지정이 옳은 답일 때

적절히 할당된 글로벌 공간을 가진 조직은 공용 주소 VPN 풀을 얼마든지 만들 수 있고, 일부는 변환을 피하려고 의도적으로 그렇게 합니다. 그 설계에도 라우팅, 출발지 검증, 접근 규칙, 클라이언트 인증이 필요하며, 할당은 그것들 중 어느 것도 제공하지 않습니다.

그것이 제공하는 것은 고유성이며, 빌려온 프리픽스에 없는 속성입니다. 블록을 보유하고 있다면 클라이언트가 설치하는 경로는 정말로 여러분의 것인 주소를 가리키고, 터널이 끊겨도 의미가 바뀌지 않습니다.

풀 선택을 보상하려고 NAT를 자동으로 추가하지 마십시오. 명시적 반환 경로가 있는 라우팅된 사설 설계는 주소 지정이 계획된 적이 없어서 적용하는 변환보다 깔끔하고, IPv6는 IPv4 가정의 사본이 아니라 스스로 의도한 계획이 필요합니다.

접근을 잃지 않고 나쁜 풀을 폐기하십시오

풀이 이미 배포되어 있다면 바꾸기 전에 목록을 만드십시오: 주소 예약, 설치된 경로, 그 블록으로 해석되는 DNS 레코드, 방화벽 범위, 그리고 그것들에 의존하는 애플리케이션입니다. 그다음 다른 어떤 라우팅 전환과도 같은 주의로 변경을 계획하십시오. 알아차릴 사람들에게 알리십시오. 풀이 옮겨지면 그들의 세션이 끊깁니다. 클라이언트 주소 지정의 조용한 변경은 업무와 무관해 보이는 지원 티켓을 만듭니다.

제거하는 풀에 의존하지 않는 복구 경로를 남기십시오. 그것을 회수하는 순간이 원격 접근이 함께 사라질 수 있는 순간이기 때문입니다. 그다음 양방향을 검증하십시오: 의도한 사설 목적지는 여전히 동작하고, 이전에 붙잡히던 인터넷 목적지는 이제 실제 소유자로 해석됩니다.

원하는 것은 네트워크 팀이 하나의 일관된 것으로 할당하고 라우팅하고 폐기할 수 있는 풀입니다. 주소 형식만으로는 안전도 연결성도 확립되지 않습니다.

관련 글