DHCP 예약이 VPN 서버의 고정 IP가 아닌 이유

예약은 머신이 아니라 클라이언트 식별자와 일치하며, 공인 IP를 절대 고정하지 않습니다. 가정용 VPN 서버의 주소를 실제로 움직이는 것은 무엇인가.

가정용 VPN 박스를 Wi-Fi에서 Ethernet으로 옮겼더니 그 “영구” 주소가 같은 날 저녁에 바뀌었습니다. 라우터에는 고장 난 것이 없었습니다. 예약은 무선 어댑터와 일치하고 있었고, 그 어댑터는 더 이상 경로에 없었습니다.

같은 오해에는 나머지 절반이 있습니다. LAN 주소를 고쳐도 친구들이 접속하는 주소에는 아무 효과가 없고, VPN이 클라이언트에게 주는 사설 풀과도 아무 관계가 없습니다. 세 개의 주소, 세 가지 별개의 고장 방식이 있고, 그중 예약의 일은 하나뿐입니다.

예약은 장치가 아니라 클라이언트와 일치합니다

DHCPv4에서는 예약이 클라이언트의 하드웨어 주소에 묶입니다. DHCPv6에서는 클라이언트가 유지해야 하는 DUID에 묶입니다. hostname 필드는 사람을 위한 라벨입니다. 라우터가 실제로 비교하는 것은 요청에 실려 오는 식별자입니다.

항목을 조건으로 읽으십시오. 이 식별자가 요청하면 이 주소를 줍니다. 일치가 유지되는 동안 갱신은 같은 임대를 유지하고, 재부팅은 그냥 다시 요청합니다. 식별자가 바뀌면 요청은 예약을 비껴가고 클라이언트는 동적 풀이 주는 것을 받습니다. 오류도 경고도 없이 그저 다른 주소가 됩니다.

OpenWrt는 그 형태를 분명히 보여 줍니다. /etc/config/dhcp 안의 config host 블록 하나가 이름, MAC, 주소를 함께 묶고, 고정 임대 문서가 그 항목이 풀과 어떻게 상호작용하는지 설명합니다. 다른 라우터들도 같은 세 필드를 다른 라벨 뒤에 숨깁니다.

일치가 조용히 끊기는 곳

하드웨어 교체가 흔한 경우입니다. NIC를 바꾸거나 머신을 Ethernet과 Wi-Fi 사이에서 옮기면 라우터가 보는 주소도 함께 바뀝니다. 예전 예약은 목록에 남아 있고 여전히 맞아 보입니다.

재설치는 두 번째 경우이고 IPv6에서 가장 세게 물어뜯습니다. 새 설치가 새 DUID를 만들 수 있는데 예전 IPv4 임대는 아직 유효해서 v4 주소는 한동안 살아남고 v6 항목은 눈에 보이는 편집 없이 적용을 멈춥니다.

세 번째는 고정된 클라이언트 식별자입니다. 여러 DHCP 클라이언트가 MAC 대신 식별자 문자열을 설정하게 해 줍니다. 업그레이드나 설정 재작성이 그 설정을 빠뜨리면 머신이 움직이지 않았는데도 일치가 사라집니다.

네 번째는 중복입니다. 같은 호스트에 대한 오래된 블록과 새 블록입니다. 서버는 일치하는 규칙으로 응답하고, 대개 피하려던 풀 주소가 됩니다. 두 번째를 추가하는 대신 오래된 항목을 삭제하십시오.

호스트 쪽 설정과 그 대가

호스트에 주소를 지정하면 일치 문제가 완전히 사라집니다. DHCP가 응답하든 하지 않든 인터페이스는 그 주소로 올라오고, 라우터 재부팅 후에도 접근 가능해야 하는 머신에 바라는 것이 바로 그것입니다.

대가는 소유권입니다. 이제 프리픽스, 게이트웨이, 리졸버를 직접 제공하고 주소를 동적 풀 밖에 직접 유지해야 합니다. netplan을 쓰는 Ubuntu에서는 /etc/netplan/01-vpn.yaml가 그것을 담습니다:

network:
  version: 2
  ethernets:
    eth0:
      dhcp4: false
      addresses: [192.168.50.10/24]
      routes:
        - to: default
          via: 192.168.50.1
      nameservers:
        addresses: [192.168.50.1]

NetworkManager 사용자는 nmcli con mod "Wired connection 1" ipv4.method manual ipv4.addresses 192.168.50.10/24 ipv4.gateway 192.168.50.1, 이어서 nmcli con up "Wired connection 1"로 같은 상태에 도달합니다. 첫 시도에서는 netplan apply 대신 netplan try로 netplan을 적용하십시오. 게이트웨이를 잘못 입력하면 박스가 네트워크에서 떨어져 콘솔을 찾게 됩니다.

그래도 일치하는 예약은 남겨 두십시오. 군더더기가 아닙니다. 항목은 라우터 쪽에 주소를 기록하고, 나중에 누군가 풀을 넓히면 DHCP 서버가 그 주소를 게스트 장치에 주지 못하게 막습니다.

안정적인 LAN 주소는 공인 엔드포인트가 아닙니다

포트 포워딩을 192.168.50.10으로 향하게 하면 그 규칙은 LAN 쪽의 모든 변화를 견딥니다. 안정적인 인터넷 주소를 주지는 않습니다. 공인 IP는 ISP의 것입니다 그리고 재접속이나 모뎀 교체로 움직일 수 있으며, 동적 DNS가 바로 그 때문입니다.

통신사 수준 NAT 뒤에는 전달할 공인 IPv4가 아예 없고, 어떤 예약도 그것을 만들지 않습니다. 무엇보다 먼저 라우터의 WAN 페이지를 확인하십시오. 주소가 공유 대역에 있으면 예약이 아무리 깔끔해도 인바운드 전달은 작동할 수 없습니다.

세 번째 주소는 터널 풀이고, 흔히 10.8.0.0/24 같은 것입니다. 그 주소들은 터널 안에만 존재하고 LAN에는 절대 나타나지 않습니다. 그것을 서버의 LAN 주소와 혼동하는 것이 포트가 연결되어 있는 동안에만 온라인인 클라이언트로 전달되는 경로입니다.

경로를 끊기는 순서대로 확인하십시오

라우터에서 시작하십시오. 임대 표의 항목을 예약의 대상과 비교하십시오. 서버가 풀 주소를 가져갔다면 식별자가 잘못된 것이고, 호스트에서 ip link show가 비교할 값을 줍니다.

다음은 호스트입니다. ip -4 addr show eth0는 예상한 주소와 프리픽스를 보고해야 합니다. 같은 인터페이스에 두 번째 주소가 있으면 보통 DHCP가 아직 고정 설정 옆에서 돌고 있다는 뜻입니다.

다음은 포워딩입니다. 목적지가 방금 확인한 주소와 여전히 같은지, 그리고 무언가 ss -lntp로 듣고 있는지 확인하십시오. 닫힌 포트로 향한 포워딩은 밖에서 보면 고장 난 포워딩과 똑같이 보입니다.

밖에서 마무리하십시오. Wi-Fi를 끈 휴대폰으로 시험합니다. 그 한 번의 시험이 “로컬 주소가 틀렸다”와 “공인 도달성이 깨졌다”를 갈라 주고, 이 설정이 계속 뒤섞는 두 문제를 구분합니다.

세 주소, LAN, 공인, 터널 풀을 적어 두고 각각을 어느 시스템이 소유하는지 표시하십시오. 다음 달에 연결이 실패하면 셋을 한꺼번에 바꾸는 대신 어느 것을 살펴야 할지 알게 됩니다.

관련 글