☰

가상 인터페이스에서 ISP의 DHCP 서버를 사용할 때 dhclient가 실패하는 이유는 무엇입니까?

tag-icon • tag-icon debian virtual-machine dhcp
가상 인터페이스에서 ISP의 DHCP 서버를 사용할 때 dhclient가 실패하는 이유는 무엇입니까?

최근 T1에서 가정용 케이블 서비스(Comcast)로 전환했습니다. 내 홈 네트워크의 기본 게이트웨이 역할을 하는 Debian 6.0.6을 실행하는 가상 컴퓨터(XenServer 5.6)가 있는데 어떤 이유로 업스트림 DHCP 서버가 내 DHCPDISCOVER요청을 완전히 무시하는 것 같습니다.

2월 1일 20:58:34 myhost dhclient: 인터넷 시스템 연합 DHCP 클라이언트 4.1.1-P1
2월 1일 20:58:34 myhost dhclient: 저작권 2004-2010 Internet Systems Alliance.
2월 1일 20:58:34 myhost dhclient: 모든 권리 보유.
2월 1일 20:58:34 myhost dhclient: 자세한 내용은 https://www.isc.org/software/dhcp/를 참조하세요.
2월 1일 20:58:34 myhost dhclient:
2월 1일, 20:58:34 myhost dhclient: LPF/eth1/26:ac:40:50:5b:c7 듣기
2월 1일 20:58:34 myhost dhclient: LPF/eth1/26:ac:40:50:5b:c7에서 전송됨
2월 1일 20:58:34 myhost dhclient: 소켓/대체로 전송됨
2월 1일 20:58:38 myhost dhclient: eth1에서 255.255.255.255 포트 67 간격 4의 DHCPDISCOVER
2월 1일 20:58:42 myhost dhclient: eth1에서 255.255.255.255 포트 67 간격 5까지의 DHCPDISCOVER
2월 1일 20:58:47 myhost dhclient: eth1에서 255.255.255.255 포트 67 간격 9까지의 DHCPDISCOVER
2월 1일 20:58:56 myhost dhclient: eth1에서 255.255.255.255 포트 67 간격 14의 DHCPDISCOVER
2월 1일 20:59:10 myhost dhclient: eth1에서 255.255.255.255 포트 67 간격 8까지의 DHCPDISCOVER
2월 1일 20:59:18 myhost dhclient: eth1에서 255.255.255.255 포트 67 간격 8까지의 DHCPDISCOVER
2월 1일 20:59:26 myhost dhclient: eth1에서 255.255.255.255 포트 67 간격 9까지의 DHCPDISCOVER
2월 1일 20:59:35 myhost dhclient: eth1에서 255.255.255.255 포트 67 간격 4까지의 DHCPDISCOVER
2월 1일 20:59:39 myhost dhclient: DHCPOFFERS를 받지 못했습니다.
2월 1일 20:59:39 myhost dhclient: 영구 데이터베이스에 작업 임대가 없습니다. 최대 절전 모드입니다.
  • 모든 것이 올바르게 연결되어 있고 트래픽이 VM의 올바른 인터페이스로 브리징되고 있습니다. Listen All Traffic 을 사용하면 tcpdump많은 ARP 트래픽과 ISP의 DHCP 서버가 IP 주소를 요청하는 다른 고객에 응답하는 것을 볼 수 있습니다. 내 DHCP 패킷이 브로드캐스트되고 있지만 응답이 반환되지 않습니다.
  • dhclient모뎀이 완전히 초기화되기 전에 시작 하면 서비스를 제공할 준비가 되었을 때 공용 IP 주소를 선택할 수 192.168.100.0/24있도록 낮은 새로 고침 간격으로 네트워크 전체의 개인 IP 주소를 제공합니다 . 브리지 네트워크가 준비될 때까지 개인 네트워크에 대한 응답을 dhclient계속 보내며 , 이 시점에서 DHCP 서버로부터의 응답 수신이 다시 중단됩니다.DHCPACK
2월 1일, 21:16:02 myhost dhclient: LPF/eth1/26:ac:40:50:5b:c7 듣기
2월 1일 21:16:02 myhost dhclient: LPF/eth1/26:ac:40:50:5b:c7에서 전송됨
2월 1일 21:16:02 myhost dhclient: 소켓/대체로 전송됨
2월 1일 21:16:04 myhost dhclient: eth1에서 255.255.255.255 포트 67 간격 8까지의 DHCPDISCOVER
2월 1일 21:16:04 myhost dhclient: 192.168.100.1에서 DHCPOFFER
2월 1일 21:16:04 myhost dhclient: eth1에서 255.255.255.255 포트 67로의 DHCPREQUEST
2월 1일 21:16:05 myhost dhclient: 192.168.100.1의 DHCPACK
2월 1일 21:16:05 myhost dhclient: 192.168.100.10에 바인딩 - 14초 만에 업데이트되었습니다.
2월 1일 21:16:19 myhost dhclient: eth1에서 192.168.100.1 포트 67로의 DHCPREQUEST
2월 1일 21:16:20 myhost dhclient: 192.168.100.1의 DHCPACK
2월 1일 21:16:20 myhost dhclient: 192.168.100.10에 바인딩 - 13초 만에 업데이트되었습니다.
2월 1일 21:16:33 myhost dhclient: eth1에서 192.168.100.1 포트 67로의 DHCPREQUEST
2월 1일 21:16:36 myhost dhclient: eth1에서 192.168.100.1 포트 67로의 DHCPREQUEST
2월 1일 21:16:43 myhost dhclient: eth1에서 192.168.100.1 포트 67로의 DHCPREQUEST
2월 1일 21:16:50 myhost dhclient: eth1에서 255.255.255.255 포트 67로의 DHCPREQUEST
2월 1일 21:16:51 myhost dhclient: eth1에서 255.255.255.255 포트 67 간격 7까지의 DHCPDISCOVER
2월 1일 21:16:58 myhost dhclient: eth1에서 255.255.255.255 포트 67 간격 15의 DHCPDISCOVER
2월 1일 21:17:13 myhost dhclient: eth1에서 255.255.255.255 포트 67 간격 7까지의 DHCPDISCOVER
2월 1일 21:17:20 myhost dhclient: eth1의 DHCPDISCOVER에서 255.255.255.255 포트 67 간격 10
2월 1일 21:17:30 myhost dhclient: eth1에서 255.255.255.255 포트 67 간격 10까지의 DHCPDISCOVER
2월 1일 21:17:40 myhost dhclient: eth1에서 255.255.255.255 포트 67 간격 12의 DHCPDISCOVER
2월 1일 21:17:52 myhost dhclient: DHCPOFFERS를 받지 못했습니다.
2월 1일 21:17:52 myhost dhclient: 영구 데이터베이스에 작업 임대가 없습니다. 최대 절전 모드입니다.
  • 내 특별한 경우에는 집에 전화 서비스도 제공하는 EMTA 모뎀입니다. 내 전화 서비스는 괜찮지만 IP 주소를 얻을 수 없습니다.
  • ISP에 전화를 걸어 전화 메뉴를 사용하여 모뎀에 재설정 신호를 보내고 재설정 버튼을 눌러 공장 재설정을 실행하고 펌웨어를 다시 다운로드해 보았습니다. 이 중 어느 것도 문제를 해결하지 못했습니다.
  • 나는 여분의 DOCSIS 3.0 케이블 모뎀을 가지고 있습니다. 기술자와 협력하여 일시적으로 MAC 주소를 화이트리스트에 추가했지만 DHCP 응답이 표시되지 않는 동일한 문제가 발생했습니다.

Comcast에 전화하여 내 MAC 주소가 블랙리스트에 포함되었는지 물어봤지만 그들은 내 계정에 프리미엄 기술 지원 서비스를 추가하지 않고 내 휴대폰을 업그레이드하는 것을 거부했습니다. (문제가 해결되자마자 구독을 취소할 수 없도록 일회성 가입비가 포함되어 있습니다.)

내 가상 머신이 DHCP 응답을 받을 수 없는 이유는 무엇입니까?

답변1

ISP에서 자동으로 생성한 가상 MAC 주소를 사용하지 마세요.

완전히 임의의 MAC 주소를 사용하든, 공급업체가 아닌 접두사를 사용하든 관계없이 ISP 인프라의 MAC 주소 난독화 위험이 있습니다.

해결책은 기존 네트워크 카드의 MAC 주소를 스푸핑하는 것입니다. 다시는 사용하지 않을 오래된 기본 10 카드를 사용하는 것이 좋지만 다음 기준을 충족하는 MAC 주소라면 가능합니다.

  • 실제로 소유하고 있는 물리적 네트워크 포트에 할당
  • 인프라의 다른 VM에 의해 보유되지 않음(가상화 플랫폼을 혼동할 수 있음)
  • 그렇지 않으면 할당한 VM에서 볼 수 없습니다.
  • 해당 세그먼트의 다른 컴퓨터에서는 볼 수 없습니다.

해당 MAC 주소를 스푸핑하도록 가상 NIC를 재구성하고, 운영 체제에 변경 사항이 표시되는지 확인합니다.케이블 모뎀을 다시 시작하세요.. 저는 특정 시나리오에서 케이블 모뎀 재시작 단계가 필요하다는 것을 여러 번 입증할 수 있었습니다.

답변2

또 다른 대답은 VM MAC이라고 하는데 이는 거의 정확합니다. 먼저 모뎀이 업스트림 서버에 DHCP 요청을 한다는 점에서 혼란을 해소하겠습니다. 예를 들어 Comcast에서 사용하는 라우팅할 수 없는 주소를 가져옵니다 10.x.x.x. 모뎀 자체에 DHCP 요청을 하면 ISP가 모뎀에 할당한 공용 WAN IP를 제공합니다.

어쨌든, 귀하의 질문으로 돌아갑니다. 모뎀은 처음 보는 MAC에 "바인딩"됩니다. 따라서 호스트 OS가 시도하면아무것모뎀은 가상 머신이 시작되어 통신을 시도할 때까지 해당 포트에 있는 가상 머신의 모든 패킷을 무시합니다. RHEL이 (전용) NIC를 부팅할 수 있도록 허용했지만 이와 연결된 IP 없이(BootP/DHCP는 꺼짐) RHEL에서 VMWare를 사용하여 과거에 수행하려고 했던 작업을 수행할 수 있었습니다. 그런 다음 가상 머신이 부팅되어 연결을 시도할 때 모뎀이 회선에서 보는 첫 번째 패킷입니다. 따라서 이를 수행하려면 호스트 운영 체제에 최소한 두 개의 네트워크 카드가 있어야 합니다.할 수 없다다른 용도로 이 포트를 사용하면 모뎀에 직접 연결할 수 있습니다.

관련 정보