맞는 VPN 클라이언트 주소 풀을 계획하는 방법
서버 필드에서 풀을 고르고, 클라이언트가 실제로 받는 주소를 읽고, 응답이 돌아오는 경로를 따라가며 범위, 모드, 경로, DNS 범위를 기록합니다.
VPN 서버의 풀 필드에서 시작하며, 스프레드시트가 아닙니다. 거기에 입력하는 값은 이후 접속하는 모든 클라이언트의 내부 주소 공간이 되며, 그 클라이언트들이 도달하는 LAN, 그 뒤의 라우팅된 사이트, 그리고 클라이언트가 집에서 이미 보유한 주소와 공존해야 합니다. 풀을 저장하자마자 클라이언트 하나를 연결해, 그 첫 연결이 값이 실제로 작동하는지 알려 주게 하세요. 거기서부터 안내는 클라이언트가 받은 주소, 응답이 지나는 경로, 그리고 남기는 기록으로 바깥을 향해 나아갑니다.
어떤 클라이언트도 접속하기 전에 풀 필드에서 시작합니다
제품마다 이를 다르게 노출하므로 주소를 실제로 할당하는 객체를 찾으세요. OpenVPN에는 다음 빈 주소를 내주는 서버 측 풀 지시문이 있고, IKEv2 게이트웨이에는 피어 구성에 묶인 풀 섹션이 있으며, WireGuard에는 둘 다 없습니다(각 피어가 자신의 구성 파일에 자신의 주소를 담기 때문입니다). 풀 지시문과 피어별 주소는 서로 바꿀 수 없고, 잘못된 쪽을 편집하면 나머지 안내가 낭비됩니다.
필드를 확보했으면 사무실 LAN, 라우팅된 각 사이트, 클라우드 VPC, 그리고 아직 운영 중인 다른 풀이라는 이미 존재하는 범위를 나열합니다. 중복은 호스트 번호가 익숙해 보이는지가 아니라 프리픽스 산술로 판정되므로, 집계를 각 범위와 비교하세요. 둘 다 10.x처럼 보이는 두 범위는 집계가 교차하지 않으면 무해하고, 교차하면 지원 사건입니다.
다음으로 주소가 누가 접속하는지의 함수인지 언제 접속하는지의 함수인지 결정합니다. 동적 할당은 비어 있는 것을 나눠 주고, ID별 할당은 고정 주소를 자격 증명에 묶습니다. 나중에 재접속이 어떤 모습이어야 하는지를 바꾸므로 선택을 기록하세요.
클라이언트가 실제로 받은 주소를 읽습니다
클라이언트 하나를 연결하고 풀이 약속한 것이 아니라 터널이 보고하는 것을 읽습니다. 클라이언트는 연결 상태에 내부 주소를 표시하고, Linux에서는 인터페이스가 그것을 직접 갖습니다.
그 주소를 저장한 범위와 비교합니다. 범위 밖이라면 편집한 것과 다른 할당 경로를 보고 있는 것입니다. 프리픽스 길이도 확인하세요(/32을 가진 클라이언트는 온링크 피어가 없어 모든 목적지를 기본 경로로 보냅니다).
ip -4 addr show tun0
ip route get 192.168.50.20
같은 범위를 쓰는 가정용 라우터에서 접속한 클라이언트는 연결되지만 거의 아무것도 도달하지 못합니다. 클라이언트가 그 프리픽스의 로컬 경로를 유지하므로 터널 주소가 뒤의 네트워크와 충돌하고 트래픽이 잘못된 인터페이스로 나갑니다. 이 경우는 서버에서 고칠 수 없으며, 문서화된 해결책은 가정 네트워크를 다시 번호 매기거나 충돌이 드물게 남을 만큼 먼 풀 범위를 고르는 것입니다. 실패와 해결책을 모두 기록하세요(헬프 데스크가 다시 만나게 됩니다).
같은 클라이언트를 다시 연결하고 주소를 관찰합니다. 동적 풀은 같은 값을 돌려줄 수도 다른 값을 돌려줄 수도 있고 둘 다 맞지만, 주소를 바꾸는 ID별 풀은 결속을 지키지 않습니다. 그 확인은 몇 초면 끝나고 첫 절에서 기록한 모드가 유효한 모드인지 판정합니다.
서비스에서 응답이 돌아오는 경로를 따라갑니다
풀은 응답이 그곳으로 돌아갈 수 있을 때만 작동합니다. LAN의 서비스는 내부 주소에 응답하므로 그 게이트웨이에는 풀을 위한 경로나 서비스 앞의 변환이 필요합니다. 요청이 터널로 들어오고 응답이 다른 경로로 나가면 상태 저장 방화벽이나 역경로 검사가 이를 떨어뜨리고, 클라이언트는 연결된 뒤 멈추는 서비스를 봅니다. 호스트별 경로를 추가하는 대신 풀을 라우팅 설계에 하나의 요약 가능한 블록으로 넣으세요.
변환은 시스템의 나머지가 보는 것을 바꿉니다. 소스가 다시 쓰이면 호스트 방화벽과 애플리케이션 로그의 주소는 변환된 것이므로, 풀 주소에 맞춰 쓴 규칙은 아무것도 일치하지 않고 로그 줄은 클라이언트까지 추적할 수 없습니다. strongSwan의 전달 문서는 IKEv2 게이트웨이에 대해 그 경로의 서버 측 절반을 다룹니다. DNS도 같은 제약을 지니는데, 클라이언트가 도달할 수 없는 주소로 해석되는 이름은 나중에 다른 곳에서 실패합니다.
클라이언트 둘, 그다음 폐기 하나
동시에 클라이언트 둘을 연결하고 두 주소를 읽습니다. 서로 다르고 사용 가능하며 풀 안에 있어야 하고, 각각이 의도된 서비스에 도달해야 합니다. 중복 주소를 내주는 풀은 보통 첫 단일 클라이언트 테스트가 아니라 여기서 드러납니다.
다른 클라이언트가 연결된 상태로 자격 증명 하나를 폐기한 뒤, 살아남은 클라이언트에서 서비스를 시도합니다. 다른 세션을 방해하는 폐기는 공유 상태를 가리키며, 대개 하나의 자격 증명이나 기기 간에 재사용되는 하나의 주소입니다. 폐기된 클라이언트를 다시 연결해 해제된 주소를 받는 것이 아니라 거부되는지 확인합니다.
거부되어야 할 목적지로 마무리합니다. 모든 것에 도달하는 클라이언트는 연결된 것이지 시험된 것이 아닙니다.
네 값을 다음 변경이 찾을 수 있는 곳에 씁니다
기록은 짧습니다: 풀 범위와 프리픽스, 할당 모드, 사용 중인 반환 경로나 변환, 그리고 그 목적지에 응답하는 DNS 범위입니다. 티켓이 아니라 서버 구성 옆에 두고 날짜를 적으세요. 나중에 넷 중 하나를 바꾸는 사람은 나머지 셋을 눈앞에 두어야 하며, 풀 크기 변경은 경로를 깨고 경로 변경은 DNS 응답을 깨기 때문입니다.
소유권 메모도 함께 두어, 터널 범위는 VPN 서버에 속하며 LAN의 DHCP 범위에서 만든 예약은 터널 안의 클라이언트를 위해 아무것도 예약하지 않는다는 점을 적습니다. 그 한 줄이, 누군가 예약을 추가하고 터널 주소가 그것을 따르리라 기대하는 가장 흔한 재작업을 막습니다.