이 보고들은 모두 같은 소리로 들리지만 의미는 서로 다릅니다: 노트북이 주소 충돌을 호소하는데, 늘 그런 것은 아니고 대부분 VPN이 켜져 있을 때 생깁니다. 이 메시지를 만드는 장애는 세 가지입니다: 자기 링크 위의 진짜 중복, 원격 네트워크가 내 LAN 범위를 쓰는데 아무것도 중복되지 않은 겹침, 그리고 한 주소를 두 피어에 준 터널입니다. 고치는 방법은 경우마다 다르고, 틀린 처치는 증상을 없애기는커녕 옮겨 놓을 뿐입니다. 그러니 무엇이든 고치기 전에 어느 경우인지 먼저 판별하세요.

같은 오류 메시지를 내는 세 가지 장애

중복이란 같은 세그먼트의 두 기계가 한 주소를 동시에 주장하는 상태입니다. 커널이 알아차리는 이유는 자기 프로브에 대한 응답이 다른 MAC에서 오기 때문이고, 그다음 동작은 스택에 달려 있습니다: Linux는 로그를 남기고, Windows는 인터페이스를 비활성화하고 시스템 로그에 항목을 쓰며, DHCP 클라이언트는 그 제안을 거절할 수 있습니다.

겹침은 어떤 주소도 중복시키지 않습니다. 당신의 LAN은 192.168.1.0/24이고 사무실 네트워크도 192.168.1.0/24인데, 이제 사무실로 가는 경로가 프린터와 NAS이기도 한 주소를 가리킵니다. ARP의 의미에서는 아무것도 충돌하지 않고, 패킷은 두 네트워크 중 하나에서 엉뚱한 장치로 갈 뿐입니다.

풀 충돌은 터널 자체의 잘못입니다. 두 피어가 같은 터널 주소로 설정되었거나 그 주소를 받았기 때문에, 서버는 돌아오는 트래픽을 보낼 때 둘을 구분할 수 없습니다. 두 클라이언트 중 하나는 핸드셰이크는 되는데 데이터가 오지 않는 상태가 되고, 이는 라우팅 문제처럼 읽히지만 그렇지 않습니다.

테스트 1: 중복이 내 세그먼트에 있는가

기억하는 설정이 아니라 기계가 실제로 가진 것을 나열하는 것으로 시작하세요. VPN 어댑터 주소는 터널 전용이며 웹사이트가 보는 주소와 같지 않습니다, 공유된 공인 출구는 충돌이 아닙니다.

ip -br addr
ip neigh
ip route show table all | grep -E 'wg|tun|ppp'

Windows에서는 같은 정보를 ipconfig /all와 Get-NetIPAddress에서 얻고, 이웃 캐시는 arp -a에 있습니다. 문제의 주소가 물리 어댑터에 있고 VPN을 켜지 않아도 증상이 나타난다면 VPN은 방관자이므로 그 진단은 그만두어야 합니다.

추측 대신 중복을 증명하려면 그 주소를 갖지 않은 장치에서 프로브하세요. arping -D는 출발지 주소를 영으로 두고 프로브를 보내므로, 예상치 못한 MAC에서 응답이 오면 다른 호스트가 이미 그 주소에 응답하고 있다는 증거입니다.

sudo arping -D -I eth0 -c 3 192.168.1.50

그다음 직접 다른 주소를 고르는 대신 네트워크 관리자를 통해 소유자를 찾으세요. 누군가의 메모에만 존재하는 고정 할당, 고정 주소 프린터, DHCP 서버의 예약이 흔한 원인이며, 전원이 꺼진 장치도 자기 임대를 계속 보유합니다.

테스트 2: 두 네트워크가 겹치는가

터널이 주는 프리픽스와 내 인터페이스의 프리픽스를 비교하세요. 원격 범위가 LAN과 같거나 그것을 포함한다면 장애는 겹침이고, 단서는 VPN 없이 닿던 호스트가 사라지거나 내 프린터가 사무실 주소에서 응답하는 것입니다.

ip route get 192.168.1.10
ip -br addr show

경로 조회는 커널이 어느 인터페이스를 쓸지 알려 주고, 그 답이 진단의 전부입니다. 로컬 프린터에 속한 주소에 대해 터널을 말한다면 겹침이 있고, 임대를 갱신해도 바뀌지 않습니다.

빠져나갈 정직한 길은 세 가지이며 보통 하나만 쓸 수 있습니다. 원격 쪽이 겹치는 서브넷의 트래픽을 마스커레이드하면 클라이언트는 서버의 터널 주소만 보게 됩니다. 터널이 LAN과 충돌하지 않는 더 좁은 원격 프리픽스를 실어 나를 수도 있습니다. 또는 클라이언트가 정책 규칙으로 출발지 주소에 따라 경로를 나눌 수 있는데, 동작은 하지만 깨지기 쉽고 동료에게 넘기기 어렵습니다.

사무실 네트워크를 다시 번호 매기는 일은 좀처럼 당신의 결정이 아닙니다. 충돌을 피하려고 자기 LAN을 다시 번호 매기는 것은 프린터와 카메라, 고정 호스트가 얽히면 대부분이 생각하는 것보다 큰 변경입니다.

테스트 3: 터널이 한 주소를 두 번 주었는가

WireGuard에는 주소 풀이 없습니다. 각 피어는 공개 키와 AllowedIPs의 프리픽스로 식별되므로, 같은 터널 주소를 두 피어 항목에 적거나 같은 키 쌍을 두 기계에 설치하면 중복이 생깁니다.

wg show all allowed-ips
wg show wg0 latest-handshakes
wg show wg0 transfer

여기서 유용한 열은 트래픽 카운터입니다: 최근 핸드셰이크는 보이는데 전송이 없는 피어는 주소가 잘못되었거나, 같은 프리픽스를 주장하는 다른 항목에 가려져 있습니다. 프리픽스는 정확히 한 피어에 두고 각 장치에 고유한 키 쌍을 주세요.

OpenVPN에는 풀이 있고, 흔한 충돌은 고정 --ifconfig 줄이 포함된 클라이언트 프로필을 두 번째 기계로 복사하는 것입니다. 그러면 두 클라이언트가 같은 터널 주소를 요청하고, 서버는 먼저 처리한 세션을 받아들입니다. --duplicate-cn를 쓴 상태의 풀 고갈도 한 인증서의 여러 세션이 한 항목을 두고 다투면 비슷한 결과를 냅니다.

이 경우에는 클라이언트 로그가 아니라 서버 로그를 읽으세요. 어느 세션이 어느 주소를 가져갔는지 서버가 알고 있고, 거기서 중복된 주소는 클라이언트에는 닿지 않는 경고로 나타납니다.

근원에서 고치고 두 장치를 다시 확인하기

순서가 중요합니다. 먼저 LAN 중복을 고치세요, 주소를 유지하지 못하는 클라이언트는 터널도 유지하지 못하기 때문입니다. 다음으로 VPN 쪽 프로비저닝을 고치세요, 풀 할당에 대한 클라이언트 측 변경은 다음 연결에서 취소되기 때문입니다. 마지막으로 중복된 신원을 다루세요: WireGuard에서는 키 쌍을 분리하고, OpenVPN에서는 인증서를 나누거나 적어도 프로필을 나누세요.

클라이언트 쪽 기계적인 작업은 짧습니다. DHCP 임대를 해제하고 갱신하거나, 예약을 위해 서버에서 주소를 바꿔 달라고 요청하세요. 비어 보이는 임의의 주소를 입력하지 마세요.

sudo dhclient -r eth0 && sudo dhclient eth0
ipconfig /release && ipconfig /renew

그다음 한쪽이 아니라 양쪽에서 확인하세요. 게이트웨이, 실제로 필요한 서비스, 다시 연결해 재확인 순서입니다. 두 장치가 관련되었다면 둘 다 확인하세요: 한 주소를 옮기면 다른 쪽에는 오래된 이웃 항목이나 나중에 다시 나타나는 옛 임대가 남습니다.

가는 길에 하지 말아야 할 것

증상을 입 다물게 하지 마세요. 중복 주소 검출은 이미 쓰이는 주소를 가져가지 않도록 막는 장치이고, 이것을 끄면 보이던 충돌이 추적하기 훨씬 어려운 간헐적 패킷 손실로 바뀝니다. 예상치 못한 호스트의 인증서 경고를 받아들이는 경우도 같습니다: 그것은 주소 문제가 아니며, 그냥 넘기면 다른 장애를 가립니다.

관리되는 네트워크의 주소 설계도 직접 바꾸지 마세요. 원래 설정을 기록하고, 주소가 중앙에서 할당된다면 소유자에게 물어보고, 변경은 되돌릴 수 있을 만큼 작게 유지하세요. RFC 5227의 주소 충돌 검출 규칙은 올바른 프로브가 무엇을 증명하는지 설명하며, 충돌을 진짜라고 부르기 전에 알아 둘 가치가 있습니다.

관련 글