DHCP 임대 갱신 후 인터넷 없음


10

오늘날 우리는 많은 컴퓨터가 인터넷 액세스를 중단했습니다. 많은 문제 해결 후 일반적인 스레드는 오늘 모두 dhcp 임대가 갱신되었다는 것입니다 (여기서는 8 일 임대입니다).

임대 갱신 후에는 모든 것이 유효합니다. 유효한 IP 주소, DNS 서버 및 게이트웨이가 있습니다. 내부 리소스 (파일 공유, 인트라넷, 프린터 등)에 액세스 할 수 있습니다. 조금 더 문제를 해결하면 게이트웨이에 핑이나 추적을 할 수 없지만 게이트웨이 바로 앞의 핵심 계층 3 스위치에 도달 할 수 있습니다. 머신에 고정 IP를 할당하면 임시 솔루션으로 작동합니다.

마지막 주름은 지금까지 보고서가 게이트웨이와 동일한 VLAN에있는 클라이언트에 대해서만 제공되었다는 것입니다. 우리의 관리 직원과 교직원은 서버 및 프린터와 동일한 vlan에 있지만 전화, 열쇠 고리 / 카메라, 학생 / wifi 및 랩은 각각 자체 vlan을 가지고 있으며 다른 vlan에서 아무것도 보지 않는 한 아직 문제가있었습니다.

게이트웨이 벤더와 별도의 티켓을 가지고 있지만, 그들이 쉽게 나가서 문제가 네트워크의 다른 곳에 있다고 말해 줄 것이므로 여기에서도 묻습니다. 게이트웨이와 코어 스위치에서 arp 캐시를 지 웠습니다. 어떤 아이디어라도 환영합니다.

업데이트 :
게이트웨이에서 영향을받는 호스트로 핑을 시도했지만 전혀 다른 IP 주소에서 응답을 받았다는 것이 이상합니다. 나는 무작위로 몇 가지를 더 시도하고 결국 이것을 얻었습니다.

금 9 2 월 2011 13:08:51 GMT-0500 (중부 일광 절약 시간)
PING 10.1.1.97 (10.1.1.97) 56 (84) 바이트의 데이터.
10.1.1.105에서 64 바이트 : icmp_seq = 1 ttl = 255 시간 = 1.35ms
10.1.1.97에서 64 바이트 : icmp_seq = 1 ttl = 255 time = 39.9ms (DUP!)

10.1.1.97은 실제 핑의 목표입니다. 10.1.1.105는 다른 건물의 프린터 여야합니다. 나는 한 결코 전에 핑 응답에서 DUP를 볼 수 없습니다.

현재 가장 좋은 추측은 나쁜 게이트웨이가있는 10.1.1.0/24 서브넷의 기숙사 방 중 하나에있는 불량 Wi-Fi 라우터입니다.

...계속되는. 이제 문제가있는 프린터의 전원을 끄고 게이트웨이에서 영향을받는 호스트에 대한 핑이 완전히 실패합니다.

업데이트 2 :
영향을받는 컴퓨터, 게이트웨이 및 그 사이의 모든 스위치에서 arp 테이블을 확인합니다. 각 시점에서 해당 장치의 항목이 모두 정확했습니다. 표의 모든 항목을 확인하지는 않았지만 호스트와 게이트웨이 간의 트래픽에 영향을 줄 수있는 모든 항목은 괜찮습니다. ARP는 문제가되지 않습니다.

업데이트 3 : 현재
상황이 작동하고 있지만 문제를 해결하기 위해 수행 한 작업을 볼 수 없으므로 이것이 일시적인 문제 일지 모릅니다. 어쨌든 지금 진단하거나 문제를 해결하기 위해 할 수있는 일은 많지 않지만 다시 중단되면 더 업데이트 할 것입니다.


그들의 게이트웨이에 핑 작업? 구성된 DNS 서버가 동일한 서브넷 또는 다른 곳에 있습니까? DNS 확인이 작동합니까?
Shane Madden

@Shane, 모든 것이 작동하며 본문에 답변되어 있습니다
Joel Coel

"게이트웨이에 대해 ping 또는 추적을 할 수 없습니다"라고 말 했음-장치의 첫 번째 홉 게이트웨이 또는 다른 첫 번째 홉 장치에 의해 라우팅 된 후 트래픽이 라우팅되는 인터넷 라우터입니까?
Shane Madden

2
클라이언트 중 하나에서 패킷 캡처를 실행 한 다음 게이트웨이에 대한 ping 및 추적 경로를 사용합니다. 어떤 IP 주소를 캡처 할 때 어떤 MAC 주소가 표시되는지 확인하고 ICMP 리디렉션을 찾습니다. 또한 클라이언트 중 하나, 스위치 및 게이트웨이에서 ARP 테이블을 자세히 살펴보고 올바르게 표시되는지 확인합니다.
joeqwerty

1
명확하게 : 게이트웨이에 영향을받는 호스트에 대한 유효한 ARP가 있고 호스트에 게이트웨이에 대한 유효한 ARP가 있지만 호스트를 핑하려고 할 때 게이트웨이가 응답을 얻지 못한다고 말하고 있습니까? 핑 패킷이 장치로 전달되고 있습니까, 아니면 올바르게 전환되지 않습니까?
Shane Madden

답변:


3

"현재 최선의 추측은 잘못된 게이트웨이가있는 10.1.1.0/24 서브넷의 기숙사 방 중 하나에있는 불량 Wi-Fi 라우터입니다."

이것은 내 사무실에서 일어났다. 문제가되는 기기는 악성 안드로이드 기기로 밝혀졌습니다.

http://code.google.com/p/android/issues/detail?id=11236

안드로이드 장치가 DHCP를 통해 다른 네트워크에서 게이트웨이의 IP를 얻는다면, 그것은 네트워크에 가입하여 게이트웨이 IP에 대한 MAC의 ARP 요청에 응답하기 시작할 수 있습니다. 공통 10.1.1.0/24 네트워크를 사용하면이 불량 시나리오의 가능성이 높아집니다.

네트워크의 영향을받는 워크 스테이션에서 ARP 캐시를 확인할 수있었습니다. 거기에서 워크 스테이션이 올바른 MAC과 일부 불량 장치의 MAC 주소간에 플립 플롭되는 ARP 플럭스 문제를 관찰했습니다. 워크 스테이션이 게이트웨이 용으로 가지고있는 의심스러운 MAC을 찾아 보면 Samsung 접두사가 다시 나타납니다. 문제가있는 워크 스테이션을 가진 기민한 사용자는 누가 우리 네트워크에 삼성 장치가 있는지 알고 있다고 대답했습니다. CEO로 밝혀졌습니다.


2

주석 섹션에서 이미 논의했듯이 패킷 캡처를 얻는 것이 정말 중요합니다. 그러나 arpwatch라는 훌륭한 도구도 있습니다.

http://ee.lbl.gov/

(또는 Windows의 경우 http://sid.rstack.org/arp-sk/ )

이 도구는 이메일을 보내거나 네트워크에 표시되는 모든 새로운 MAC 주소와 주어진 서브넷 (플립 플롭)의 IP에 대한 MAC 주소 변경 사항을 기록합니다. 이 문제의 경우 MAC을 변경하는 IP에 대해 플립 플롭이 발생했음을보고하여 현재 이론을 모두 감지했거나 호스트와 처음 통신을 시작할 때 불량 DHCP 라우터에 대한 새로운 MAC을 보게됩니다. 이 도구의 단점은 호스트가 모니터링하는 모든 네트워크에 연결되어 있어야하지만 이러한 종류의 문제를 진단하는 데 도움이되는 훌륭한 정보는 적은 가격입니다.


1

일반적인 불량 DHCP 서버를 감지하는 빠른 방법은 게이트웨이가 핑 (ping) 한 후 해당 ARP 테이블에서 해당 MAC을 검사하는 것입니다. 스위칭 인프라가 관리 형 인프라 인 경우 MAC을 호스트하는 포트로 MAC을 추적하고 포트를 종료하거나 문제를 해결하기 위해 문제가있는 장치의 위치로 다시 추적 할 수 있습니다.

스위치를 지원하는 스위치에서 DHCP 스누핑을 사용하면 불량 DHCP 서버로부터 네트워크를 보호하는 효과적인 옵션이 될 수도 있습니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.