LAN에서 IP가 충돌할 때 발생하는 일 1

시작

회사에서 소규모 시스템을 구축하는 프로젝트를 진행한 적이 있었다.

 

그 시스템은 클라이언트 PC 5대, 서버 PC 1대, 가정용 스위칭 허브, 가정용 무선 공유기의 구성으로 LAN에 구축된 상태고 여기에 외부 단말기가 무선 공유기를 통해 LAN에 접속하여 시스템을 WOL로 켜주는 역할을 하고 있다.

 

문제의 발단

WOL로 시스템을 구동하는 것까지는 좋았는데 간헐적으로 다음 문제가 발생하기 시작했다.

 

1. 특정 클라이언트가 서버에 연결하지 못함

 

2. 모든 클라이언트가 서버에 연결하지 못함(서버의 상태는 모니터링 불가)

 

그리고 이 현상은 무조건 발생하는 것이 아니라 간헐적으로 발생하여 골치를 썩게 만들었다.

문제 해결

문제를 해결하기 위해 다음의 과정을 거쳤었다.

문제 1을 일으키는 클라이언트의 DHCP 기능을 완전히 정지

 

문제 1에 해당하는 클라이언트의 터미널에서 IP 설정을 확인해 본 결과 (중복)이 뜨면서 다른 IP가 할당됨을 확인했다.

 

해당 클라이언트의 DHCP 설정에 문제가 있는 것으로 판단, DHCP 기능이 되지 않도록 완전히 차단했다.

 

참고 링크 - https://atecbs.tistory.com/entry/%EC%9C%88%EB%8F%84%EC%9A%B010-%EA%B3%A0%EC%A0%95-IP%EA%B0%80-DHCP%EB%A1%9C-%EB%B3%80%EA%B2%BD%EB%90%98%EB%8A%94-%ED%98%84%EC%83%81-%ED%95%B4%EA%B2%B0%EB%B0%A9%EB%B2%95

 

하지만 문제를 해결하지 못했으며 제보에 의하면 문제 2가 더 심해지는 결과를 초래했다고 한다.

무선 공유기의 DHCP 설정 변경

시스템에 연결된 무선 공유기는 iptime의 제품을 사용하고 있었는데 기본 게이트웨이는 192.168.0.1이다.

 

그렇다는 것은 iptime 공유기에서 DHCP가 작동하고 있을 경우, 시스템을 구동하기 전 접속한 외부 단말이 공유기로부터 할당받을 수 있는 가장 작은 숫자의 IP인 192.168.0.2를 할당받아 충돌이 발생했다고 생각할 수 있다.

 

그러나 공유기는 추후에 설치된 것이기 때문에 어떻게 설정되어 있었는지는 알 수 없는 상황이었다.

 

현장 관리자와의 협조를 통해 공유기 설정 페이지를 살펴봤고, 역시나 DHCP가 가동되는 상황이었다.

 

관리자 페이지에서 DHCP의 할당 범위를 192.168.0.100 ~ 192.168.0.200으로 제한한 다음 각 PC에 IP를 지정해 주니 시스템이 정상적으로 구동함을 확인할 수 있었다.

네트워크가 마비되는 이유?

공유기 설정으로 문제를 해결했다지면 명확하게 해결한 것은 "IP가 중복되어 생기는 충돌" 뿐이다.

 

전체 네트워크가 죽었던 이유에 대해서는 명확한 답을 내리기 어려웠다.

 

자료를 찾아보던 중 흥미로운 글을 몇 개 확인할 수 있었다.

 

자료 1 - https://coolenjoy.net/bbs/45/78598

 

위의 글에서는 어떤 장치에 IP 할당이 실패한 것으로 추정되는 상황에서 LAN이 먹통이 되는 현상이 발생한 것을 물어보고 있다.

 

위의 글에서는 정확한 원인을 짚어주지는 않으나 적어도 IP 충돌이 발생할 때 LAN에 장애가 발생할 수 있다는 동일 사례를 확인할 수 있었다.

 

자료 2 - https://www.phpschool.com/gnuboard4/bbs/board.php?bo_table=talkbox2&wr_id=879948&sca=&sfl=wr_subject%7C%7Cwr_content&stx=&sop=and

 

위의 글은 어떤 PC의 LAN 카드가 고장 났을 때 벌어진 일에 대해 회고하고 있는데 댓글에 꽤 중요한 정보를 확인할 수 있었다.

 

제가 배운게 아직까지 통용되는거라면.. (원래 학업에서 나오는 기술은 오래전 것들이죠 ㅋㅋ)

LAN은 당연히 물려있는 녀석들끼리 동시에 통신이 됩니다.
통신선은 한개임에도 불구하고 동시통신이 되는건 당연히 패킷단위로 나눠져서 통신이 되기 때문인데요

그말은 결국 실제로 동시에 통신은 불가능 하다는 겁니다. 이미 특정 패킷이 네트워크를 타고 전송중이면
다른녀석들은 그 패킷이 다 전송될때 까지 기다렸다가 통신을 시작해야 하는 것이죠..
물론 패킷이 워낙 작아서 의미가 없지만요

그래서 실제 동시통신은 안되기 때문에 종종 동시에 통신하려고 해서 일종의 충돌이 일어나는데,
이 충돌 해결 방법이라는게 쫌 거시기 합니다. lan은 기본적으로 관리자나 서버같은 개념이 없이
물려있는 녀석들이 전부 동일한 우선순위를 갖기 때문이죠...

충돌이 발생하면 순간적으로 네트워크의 모든 녀석들이 통신을 중단합니다 -_-;
그리고 각 시스템들이 순차적으로 '랜덤한 시간을 기다렸다가' 통신을 재개합니다.
한마디로 뭐 특정한 회피 체계가 있는게 아니라, 각자 랜덤한 시간을 기다리므로,
통신 재개 역시 랜덤하게 순차적으로 시작될 것임을 기도하는 셈이죠 -_-;;;;

그러니 한녀석의 랜카드가 완전히 맛이 가서 패킷이고 뭐고 아무런 고려없이
주구장창 패킷이나 패킷처럼 보이는 통신을 마구잡이로 내뿜는다면
전체 네트워크는 당연하게도 영구히 복구되지 않습니다 -_-;;;;

 

어떠한 사유로 한 노드에서 패킷을 난사한다면 지속적인 충돌 발생으로 전체 네트워크가 먹통이 된다는 것이다.

 

댓글에서 언급하는 '랜덤한 시간을 기다렸다가'는 이더넷의 복구 방법인 백오프 방법을 사용한 것으로 이해할 수 있다.

 

이 포스팅에서 언급하는 현상도 네트워크의 충돌로 인해 지속적인 백오프를 시도하며 무한정 죽은 것으로 이해할 수 있다.

이것 역시 명확한 이유는 아니다. - ARP 관련

지금까지의 과정을 통해 백오프의 지속적인 발생으로 네트워크 장애가 발생했다는 결론은 적어도 내 프로젝트와는 완벽히 맞지 않는다.

 

자료 2의 사례는 랜카드 고장으로 인한 패킷 난사로 그 원인이 명확하다고 볼 수 있지만, 이 포스트 사례에는 딱히 랜카드가 고장 났다거나 그런 것으로 보이지는 않았다는 것이다.

 

이에 대해 더 알아보기 위해 ChatGPT한테 상황을 설명했고 다음과 같은 답변을 얻을 수 있었다.

 

 

ARP 테이블의 지속적 갱신으로 충돌이 발생했다는 것이다.

 

포스트의 상황에 대입해 보면

 

192.168.0.2 IP를 사용하는 노드가 2개 있어서 2개의 MAC 주소가 동일한 IP를 사용하는 꼴이 되어 충돌이 발생. 구축된 네트워크에서는 ARP 테이블을 갱신해야 하므로 ARP 브로드 캐스트를 하지만 OS 단에서 고정된 IP가 재할당 될 일은 없고 요청이 계속 발생하여 네트워크에 장애를 일으킴

 

그래서 처음에는 DHCP가 작동되어 어떻게든 다른 IP를 취득하는 과정을 통해 그 클라이언트만 서버에 연결하지 못하게 되었으나, 윈도우에서 DHCP 기능을 완전히 차단한 이후로는 다른 IP를 취득하고 싶어도 취득할 수 없었기에 요청 폭주로 장애가 발생했다고 볼 수 있다.

 

이와 관련하여 찾아보니 IP 충돌을 아예 범죄라 규정하며 분노하는 포스트도 있었다.

 

https://tech-network.tistory.com/entry/L3-%EC%8A%A4%EC%9C%84%EC%B9%98%EC%97%90%EC%84%9C-arp%EB%A5%BC-%EC%9D%B4%EC%9A%A9%ED%95%9C-IP-%EC%B6%A9%EB%8F%8C%EC%8B%9C-%ED%95%B4%EA%B2%B0%EB%B0%A9%EC%95%88-NAC%EC%9D%B4-%EC%97%86%EB%8A%94-%EA%B2%BD%EC%9A%B0

 

이런 문제는 조직에서 각 노드마다 사용 IP를 지정하는 경우에 겪을 수 있는 시나리오로 보인다.

 

앞으로 소규모라도 이런 LAN을 직접 구축할 경우에는 IP 충돌과 관련한 문제를 꼼꼼히 점검해야 추후에 생길 장애를 예방할 수 있을 것이다.

 

다음에 비슷한 환경을 구축할 기회가 된다면 IP가 충돌되었을 때의 상황을 와이어샤크로 모니터링하여 자세히 파악해 보도록 하겠다.

 

IP 충돌과 관련한 RFC 5227 링크를 남기며 글을 마친다.

 

https://datatracker.ietf.org/doc/html/rfc5227

RFC 5227: IPv4 Address Conflict Detection