VPN 예약에는 어떤 식별자가 필요할까요?

예약이 어떤 식별자를 써야 하는지는 주소를 배포하는 시스템, 그 시스템이 2계층 프레임을 보는지, 클라이언트 키로 무엇을 쓰는지의 세 조건이 결정합니다. DHCP를 쓰는 가정용 공유기, 브리지 VPN, 라우팅 터널은 이 질문에 서로 다르게 답합니다. 식별자를 고르는 편이 어댑터가 보고하는 모든 MAC 주소를 고정하려는 시도보다 오래갑니다(할당자가 실제로 읽는 것이 식별자이기 때문입니다).

할당자에서 시작해 거꾸로 작업하면 클라이언트 쪽 식별자는 그 시스템이 받아들이는 무엇이든입니다.

먼저 할당자에게 물으세요

DHCP 서버는 풀에서 할당하고 자기가 인식하는 식별자와 예약을 대조합니다(프로토콜 버전에 따라 하드웨어 주소, 클라이언트 식별자 문자열, DUID일 수 있습니다). VPN 서버는 자체 풀에서 할당하고 구성 모델이 드러내는 것, 흔히 인증된 Common Name과 대조합니다. 브리지 네트워크는 같은 문제를 이미 LAN을 서비스하는 DHCP 서버에 넘길 수 있습니다. 각각은 다른 조회이고, 한쪽에서 유효한 예약은 다른 쪽에서 보이지 않습니다.

무엇이든 구성하기 전에 서버가 실제로 무엇을 보는지 확인하세요. 잘못된 식별자를 지정한 예약은 조용히 실패하고, 클라이언트는 그저 풀 주소를 받으며, 그 실수는 클라이언트 문제처럼 보입니다.

MAC 주소가 여전히 의미 있는 곳

물리적 Ethernet 또는 Wi-Fi 링크에서 하드웨어 주소는 그 세그먼트의 인터페이스를 식별합니다. 개인정보 기능은 이를 회전시키고, 가상 어댑터는 새로 만들며, 노트북은 Wi-Fi와 도크에서 다른 값을 보일 수 있습니다. 라우팅 TUN 터널은 IP 패킷을 나르고 원래 무선 신원을 원격 DHCP 서버로 전달하지 않으므로, 그 경로에서 MAC 기반 예약은 대조할 것이 없습니다. TAP은 다릅니다 — Ethernet 프레임을 나르고 2계층 식별자가 여전히 중요한 브리지 도메인에 참여할 수 있습니다.

거기서도 관련 주소는 그 도메인에서 쓰는 주소이며, 자동으로 물리 업링크의 주소는 아닙니다.

터널 주소와 피어 키는 각자의 공간을 가집니다

라우팅 OpenVPN 배포는 자체 모델로 주소를 할당합니다(인증된 이름으로 키가 지정된 클라이언트별 구성이나 명시적 풀입니다). LAN 라우터의 DHCP 예약을 바꿔도 그 할당은 생기지 않고, 터널 예약을 추가해도 LAN에는 영향이 없습니다. WireGuard는 더 나아가, 피어가 공개 키와 허용된 주소로 식별되며 어떤 하드웨어 식별자로도 식별되지 않습니다. 거기서 일반 Ethernet 예약이 피어 구성을 대신하지는 못합니다.

장치 자격 증명, 가상 어댑터, 할당자의 식별자, 할당된 주소라는 네 객체를 분리해 목록으로 유지하세요. 물리 머신 하나가 여러 어댑터와 주소, 세션을 가질 수 있습니다.

안정된 주소는 신원이 아닙니다

예측 가능한 주소는 운영상 편리하고 인증 자격 증명은 아닙니다. 주소에 의존하는 접근 규칙은 주소가 재할당되거나 공유되거나 위조되는 순간 신원 확인이 아니게 됩니다. 규칙이 주소에 의존한다면 재할당과 폐기를 신원 소유자와 조정하고, 실제 인증 결정은 다른 곳에 두세요. 그래야 편의가 어느 장치가 연결됐는지에 대한 유일한 증거가 되지 않습니다.

할당자, 식별자, 할당된 주소를 함께 기록하세요. 하나가 바뀌면 나머지 둘이 확인할 대상입니다.

두 시스템이 같은 서브넷에 할당한다고 주장한다면, 어느 쪽에든 예약을 추가하기 전에 어느 쪽이 그것을 소유하는지 정하세요.