게이트웨이 오설정 (DHCP 오류, 통신 차단, HSRP 이중화)

게이트웨이(Gateway) 설정

인터넷은 멀쩡한데 특정 팀만 외부 접속이 안 된다는 신고를 받아본 적 있으십니까? 저도 같은 상황을 겪었습니다. 스위치 문제인가, 방화벽 정책인가 뒤지다가 결국 원인은 숫자 하나였습니다. 게이트웨이 IP 끝자리가 .1이어야 할 것이 .2로 배포되고 있었습니다. 이 글은 그 사고의 전말과, 같은 실수를 반복하지 않기 위해 저희가 바꾼 것들을 정리한 기록입니다.

DHCP 오류 하나가 팀 전체를 단절시키는 이유

혹시 ipconfig를 쳤을 때 게이트웨이 항목을 꼼꼼히 확인해본 적 있으십니까? 저는 그날 사고 전까지 솔직히 그냥 넘겼습니다. 그런데 약 20명 규모 팀의 PC를 한 대씩 확인해보니, 전부 게이트웨이가 192.168.10.2로 잡혀 있었습니다. 실제 라우터 주소는 192.168.10.1이었는데 말입니다.

원인은 DHCP 서버의 옵션 3(Option 3) 값이었습니다. 여기서 DHCP 옵션 3이란 DHCP 서버가 IP 주소를 배포할 때 함께 내려보내는 기본 게이트웨이 정보를 의미합니다. 쉽게 말해 "너는 외부로 나갈 때 이 주소를 거쳐라"고 클라이언트에게 알려주는 값입니다. 이 값이 존재하지 않는 IP를 가리키고 있었으니, 해당 서브넷의 모든 PC가 외부로 나가는 경로 자체를 찾지 못한 것입니다.

같은 서브넷 안에서 파일 공유나 프린터는 됐냐고요? 맞습니다, 됐습니다. 서브넷(Subnet) 내부 통신은 게이트웨이를 거치지 않고 직접 MAC 주소로 통신하기 때문입니다. 서브넷이란 하나의 네트워크를 논리적으로 나눈 구간으로, 같은 구간 안에서는 라우터 없이도 통신이 가능합니다. 그래서 같은 팀 PC끼리는 멀쩡했는데, 인터넷이나 다른 부서 서버는 전혀 열리지 않았던 겁니다.

정기 점검 중에 누군가 해당 스코프의 옵션 값을 실수로 변경한 것이 원인이었습니다. 제가 직접 DHCP 서버에서 스코프 옵션을 확인하는 순간, 아차 싶었습니다. 옵션 3 값이 .2로 바뀌어 있는 것을 보고 나서야 전체 그림이 맞춰졌습니다. 수정 후 클라이언트에서 ipconfig /release, /renew를 실행하자 즉시 모든 PC가 정상으로 돌아왔습니다.

DHCP를 통한 게이트웨이 배포가 얼마나 광범위한 영향을 미치는지, RFC 2131은 DHCP 프로토콜 명세를 통해 이 옵션 값의 정확성이 클라이언트 전체의 라우팅에 직결된다는 점을 명시하고 있습니다(출처: IETF RFC 2131). 단순 설정 변경처럼 보여도 서브넷 전체를 멈출 수 있다는 뜻입니다.

이 사고에서 특히 뼈아팠던 건, 원인 파악까지 시간이 꽤 걸렸다는 점입니다. 처음에 스위치 포트 상태, 방화벽 정책, 물리 케이블 순으로 확인하다 보니 30분 이상이 지났습니다. 게이트웨이 오설정 시 나타나는 주요 증상을 미리 알고 있었다면 훨씬 빨리 짚었을 텐데 하는 아쉬움이 남았습니다.

게이트웨이 오설정 시 나타나는 주요 증상을 정리하면 다음과 같습니다.

• 같은 서브넷 내 통신은 정상이지만 인터넷 및 타 VLAN 접근 완전 차단
• 게이트웨이 IP 중복 시 간헐적 패킷 손실 및 예측 불가한 경로 선택
• DHCP 옵션 3 오설정 시 해당 서브넷 전체 외부 통신 불가
• HSRP/VRRP 미구성 시 게이트웨이 장비가 단일 장애점(SPOF)으로 작동

통신 차단 막는 HSRP 이중화, 선택이 아닙니다

이 사고를 겪고 나서 저희 팀이 가장 먼저 한 일은 DHCP 변경 절차에 2인 검토 프로세스를 박는 것이었습니다. 그런데 절차 개선과 함께 반드시 손봐야 했던 것이 하나 더 있었습니다. 바로 HSRP 미구성 문제였습니다.

HSRP(Hot Standby Router Protocol)란 두 대 이상의 라우터 또는 L3 스위치가 하나의 가상 IP(VIP, Virtual IP)를 공유하면서, 한 장비가 다운되더라도 다른 장비가 즉시 그 역할을 이어받도록 하는 이중화 프로토콜입니다. 쉽게 말해 게이트웨이 역할을 하는 장비가 고장 나도 네트워크 사용자는 끊김 없이 통신을 유지할 수 있게 해주는 장치입니다. Cisco가 공개한 FHRP(First Hop Redundancy Protocol) 구성 가이드에서도 이 구성은 엔터프라이즈 환경의 기본 요건으로 분류됩니다(출처: Cisco).

제 경험상 이건 좀 다릅니다. 많은 분들이 HSRP를 규모가 큰 데이터센터나 ISP 환경에서나 필요한 것으로 보는 시각도 있는데, 저는 사무실 규모 네트워크에서도 반드시 구성해야 한다고 봅니다. L3 스위치 한 대가 OS 업데이트나 장애로 재부팅되는 순간, HSRP가 없으면 그 사이트 전체가 외부와 단절됩니다. 수십 명이 동시에 업무를 멈추는 상황이 벌어지는 것입니다.

저희는 이 사고 이후 모든 게이트웨이 구간에 HSRP를 구성했습니다. Active 장비와 Standby 장비가 하나의 VIP를 공유하고, DHCP 옵션 3에는 그 VIP를 배포하도록 바꿨습니다. 이렇게 하면 물리 장비가 교체되거나 재부팅되더라도 클라이언트 입장에서는 게이트웨이 IP가 바뀌지 않으니 통신이 이어집니다. 솔직히 이건 예상 밖으로 효과가 컸습니다. 이후 L3 스위치 점검을 위한 재부팅을 두 차례 진행했는데, 사용자 단에서 전혀 인지하지 못할 정도였습니다.

VRRP(Virtual Router Redundancy Protocol)도 같은 목적으로 사용할 수 있는 표준 프로토콜입니다. VRRP는 HSRP가 Cisco 전용인 것과 달리 벤더에 관계없이 사용할 수 있는 오픈 표준으로, RFC 5798에 명세가 정의되어 있습니다. 여기서 VRRP란 특정 벤더 장비에 종속되지 않고 다양한 제조사의 장비를 혼용하는 환경에서도 게이트웨이 이중화를 구현할 수 있는 인터넷 표준 방식입니다. 저희 환경은 Cisco 장비 위주라 HSRP를 선택했지만, 멀티벤더 환경이라면 VRRP를 검토하는 것이 맞습니다.

변경 후 표준화한 절차를 간단히 정리하면 이렇습니다.

1. DHCP 옵션 3 변경 시 반드시 2인 검토 후 적용
2. 변경 직후 해당 서브넷의 샘플 PC에서 ipconfig /release, /renew로 즉시 검증
3. 모든 게이트웨이 구간에 HSRP(또는 VRRP) 구성 및 VIP를 DHCP 옵션 3으로 배포
4. 정기 점검 후 게이트웨이 통신 테스트를 체크리스트 항목으로 포함

이 절차 자체가 거창한 것은 아닙니다. 하지만 제가 직접 겪어보니 "단순 작업"이라는 분류가 가장 위험합니다. 검토 없이 넘어가는 순간 숫자 하나가 수십 명의 업무를 세 시간 가까이 멈출 수 있다는 걸 그날 실감했습니다.

게이트웨이 설정은 기술적으로 단순합니다. 그래서 더 위험합니다. 단순하다는 이유로 검토 절차 없이 진행되고, 이중화 없이 방치되는 경우가 적지 않습니다. DHCP 옵션 하나를 바꿀 때도 절차를 지키고, 게이트웨이 장비에는 반드시 HSRP나 VRRP를 구성해두시길 권합니다. 운영 최소 요건으로 보셔야 한다고 생각합니다. 사고가 난 뒤에 바꾸는 것보다, 지금 당장 스코프 옵션 값과 이중화 구성 상태를 한 번 확인해보시는 게 훨씬 낫습니다.

---

출처 및 참고 자료

• Cisco - Default Gateway 개념: https://www.cisco.com/c/en/us/support/docs/ip/routing-information-protocol-rip/13788-3.html
• Cisco - HSRP(Hot Standby Router Protocol) 설명: https://www.cisco.com/c/en/us/tech/ip/hot-standby-router-protocol-hsrp/index.html
• RFC 5798 - Virtual Router Redundancy Protocol (VRRP) Version 3: https://datatracker.ietf.org/doc/html/rfc5798
• Cisco - Understanding ARP Spoofing and Dynamic ARP Inspection: https://www.cisco.com/c/en/us/products/collateral/switches/catalyst-6500-series-switches/white_paper_c11_603925.html
• Wikipedia - Default gateway: https://en.wikipedia.org/wiki/Default_gateway
• Wikipedia - Asymmetric routing: https://en.wikipedia.org/wiki/Asymmetric_routing