유선이 끊겨도 포트포워딩을 무선이 이어 받게 하는 IP 별칭 폴백

공유기의 포트포워딩 규칙은 내부 IP 하나를 가리키기 때문에, 유선이 끊기면 같은 장비의 무선이 살아 있어도 들어오는 연결은 끊긴다. 유선 링크가 연속 n회 끊겼다고 판정될 때 포워딩 대상 IP 를 무선 인터페이스에 /32 별칭으로 붙이고 공유기의 ARP 표를 무선 MAC 으로 갱신시키면, 공유기 설정을 건드리지 않고 넘어갈 수 있다. 유선이 돌아오면 별칭은 그 즉시 떼야 한다.

01 나가는 쪽은 넘어가도 들어오는 쪽은 그대로다

유선과 무선이 같은 서브넷에 붙은 장비라면 나가는 트래픽은 OS 의 인터페이스 우선순위를 따라 무선으로 옮겨 간다. 들어오는 쪽은 사정이 다르다. 포트포워딩 규칙에 적힌 목적지는 대개 유선의 IP 이고, 유선이 사라지면 그 주소로 온 요청은 갈 곳이 없다.

어긋난 설정도 흔하다. 포워딩 대상은 무선 IP 인데 기본 경로가 유선이면, 요청은 무선으로 들어오고 응답은 유선으로 나가는 비대칭이 생긴다. 그래서 폴백보다 먼저 포워딩 대상을 실제로 쓰는 인터페이스의 IP 로 맞추고, 그 IP 를 공유기의 DHCP 고정 할당으로 묶어 둔다.

02 공유기를 바꾸기 어렵다면 별칭이 가장 가볍다

03 끊기면 별칭을 붙이고 공유기의 ARP 를 갱신시킨다

감시 데몬은 유선 링크 상태를 일정 간격으로 보고, 순간 끊김에 흔들리지 않게 연속 n회 끊겼을 때만 장애로 판정한다. 판정 시간은 간격과 횟수의 곱을 넘지 않으니, 3초 간격에 2회 연속이면 길어야 6초쯤이다. 장애로 판정되면 포워딩 대상 IP 를 무선에 /32 로 붙인다. 주소 하나만 더할 뿐 무선 쪽 서브넷 설정은 바뀌지 않는다.

남은 일은 공유기가 그 IP 를 아직 유선 MAC 으로 기억한다는 점이다. ARP(IP 주소로 MAC 주소를 찾는 프로토콜)를 정한 RFC 826 은 이미 표에 있는 주소의 패킷을 받으면 MAC 을 새것으로 덮어쓰게 정해 두었고, 묻지 않았는데 보내는 gratuitous ARP 가 이 규칙을 이용한다. 하지만 RFC 5227 은 ARP 를 온전히 구현하지 않은 장비가 있다고 보고, 응답(Reply)보다 요청(Request) 형태의 알림이 더 많은 장비에서 통한다고 적는다. 그래서 요청 형태로 보내고, 그 IP 를 출발지로 게이트웨이에 ping 을 보내는 것을 보조 수단으로 둔다.

# 리눅스 — 예시 주소는 문서용 대역(RFC 5737), 무선은 wlan0
ip address add 192.0.2.10/32 dev wlan0
arping -U -c 3 -I wlan0 192.0.2.10      # -U: 요청 형태의 gratuitous ARP
ping -c 2 -I 192.0.2.10 192.0.2.1
ip address del 192.0.2.10/32 dev wlan0  # 유선이 돌아오면

# macOS — WIFI 에 무선 인터페이스 이름
ifconfig "$WIFI" inet 192.0.2.10/32 alias
ping -c 2 -S 192.0.2.10 192.0.2.1
ifconfig "$WIFI" inet 192.0.2.10 -alias  # 유선이 돌아오면

04 별칭을 늦게 떼면 유선이 주소를 못 받는다

DHCP 클라이언트는 받은 주소를 쓰기 전에 ARP 로 그 주소를 이미 쓰는 장비가 있는지 확인하고, 있으면 그 주소를 거절한다(RFC 2131). RFC 5227 의 충돌 검사도 같은 판단을 내린다. 별칭이 무선에 남아 있으면 이 확인에 무선이 답하므로, 유선은 자기 주소를 충돌로 보고 쓰지 않는다. 그래서 링크가 돌아오면 별칭부터 떼고, 그래도 유선에 IP 가 붙지 않을 때만 DHCP 를 다시 요청한다.

05 무선은 켜 두고, 스크립트는 root 소유 경로에 둔다

무선을 평소 꺼 두고 장애 때 켜면 재접속과 DHCP 를 거치는 만큼 늦다. 저장된 네트워크에 붙지 못하면 폴백이 아예 실패한다. 늘 켜 두면 별칭만 붙이면 되니 빠르고 실패할 곳도 적다.

켜 둔 무선에는 다른 비용도 있다. 2025년 RIPE 91 발표에 따르면 AirDrop 같은 애플 기기 간 직접 연결에 쓰는 AWDL 은 주변 기기를 찾으려 정해진 채널로 주기적으로 옮겨 가고, 공유기가 다른 채널을 쓰면 그때마다 무선 지연이 출렁인다. 서비스 트래픽이 평소 유선으로 다니면 이 영향에서 빠진다.

보안도 따져야 한다. 주소를 바꾸는 감시 데몬은 root 로 돈다. 그런 데몬이 일반 사용자가 고칠 수 있는 경로의 스크립트를 실행하면, 그 사용자는 스크립트만 고쳐 root 명령을 돌릴 수 있다(CWE-732). 설치할 때 root 소유·다른 사용자 쓰기 불가 경로로 복사하고, launchd 나 systemd 는 그 사본을 실행하게 한다.

06 케이블을 뽑았다 꽂으며 바깥에서 매초 요청해 본다

내부망에서 시험하면 포트포워딩을 거치지 않으니 결과가 의미 없다. 휴대폰 데이터 같은 바깥 네트워크에서 공인 주소로 매초 요청을 보내고, 요청마다 시각과 성공 여부를 남긴다. 케이블을 뽑은 시각과 다시 꽂은 시각을 이 기록에 겹치면 끊긴 요청 수와 전환 시점이 나온다.

뽑을 때만 보지 말고 꽂을 때도 본다. 별칭을 늦게 떼는 실수는 복구 쪽에서만 드러나기 때문이다. 시험은 유선 인터페이스에 원래 IP 가 다시 붙은 것까지 확인해야 끝난다.

07 자주 묻는 질문

gratuitous ARP 만 보내면 충분한가?

아니다. ARP 를 온전히 구현하지 않은 장비도 있어서, 요청 형태로 보내고 그 IP 를 출발지로 한 ping 을 보조로 함께 쓴다.

무선을 평소 꺼 두면 안 되나?

된다. 다만 장애 때 재접속과 DHCP 만큼 전환이 늦고, 저장된 네트워크에 붙지 못하면 폴백이 실패한다.

복구 때 DHCP 를 꼭 다시 요청해야 하나?

아니다. 별칭을 뗀 뒤에도 유선에 IP 가 붙지 않을 때만 다시 요청한다.