--- [네트워크 트러블슈팅] 대마도망 붕괴 사태: 기형적인 L1(물리 계층)과 VPN 터널링 실패기 발단: 멀쩡하던 시놀로지 OpenVPN의 사망 대마도 숙소에 구축해 둔 네트워크를 통해 한국 홈서버로 연결되던 시놀로지 OpenVPN이 약 일주일 전부터 툭툭 끊기기 ...
발단: 멀쩡하던 시놀로지 OpenVPN의 사망
대마도 숙소에 구축해 둔 네트워크를 통해 한국 홈서버로 연결되던 시놀로지 OpenVPN이 약 일주일 전부터 툭툭 끊기기 시작했다. 처음에는 단순 라우터 꼬임인 줄 알았으나, 상황은 생각보다 심각했다. 오늘 하루 종일 일본 특유의 해괴한 물리 네트워크 구조를 파악하고 온갖 터널링 프로토콜과 패킷 우회 기법을 총동원하며 겪은, 처절한 네트워크 디버깅 기록을 남긴다.
🔌 1. 물리 계층(L1)의 혼돈: 도대체 이 네트워크 구성은 무엇인가?
소프트웨어를 건드리기 전, 물리적 병목을 해결하기 위해 단자함을 열어본 나는 경악할 수밖에 없었다. 현재 대마도 집의 인터넷 인프라는 상식을 파괴하는 기형적인 배선 구조를 가지고 있었다.
메인 장비로 보이는 **'Super OPT 100E'**이라는 기기가 있었는데, 정작 메인 인터넷이 들어와야 할 WAN 포트는 비어 있고, LAN 포트 3개만 꽂혀서 마치 스위칭 허브처럼 동작하고 있었다. 그 3개의 포트는 다음과 같이 연결되어 있었다.
전봇대 직결선: 전봇대에서 집 안으로 다이렉트로 들어오는 파란색 메인 케이블.
정체불명의 ADSL 단말기: 랜선이 꽂혀 들어가고, 기기 아래쪽으로는 전화선(RJ11)이 빠져나가는 구조. (일본 통신사의 VoIP IP전화 분배기로 추정되나 정확한 용도를 알 수 없음)
전화기 형태의 게이트웨이 ➡️ iptime 라우터: 전화기처럼 생긴 또 다른 단말기를 거쳐서야 최종적으로 내가 사용하는 iptime 공유기의 WAN 포트로 연결됨.
가장 황당한 점은 이 인증 체계였다.
Super E100이 단순 허브 역할을 하는 것 같은데도, 이 세 가지 기기 중 단 하나라도 포트가 뽑히면 인터넷 자체가 먹통이 되어버렸다. 통신사 단에서 MAC 주소 기반 인증을 하는지, 아니면 이 세 기기 간에 어떤 암호화된 핸드셰이크가 오가는지 알 수 없지만, 극도로 폐쇄적인 일본 통신사(ISP)의 장비 종속성을 보여주는 완벽한 예시였다.
결국 인터넷 기사가 기본 제공 공유기에 비밀번호를 걸어둔 것을 우회하기 위해, 내 개인 공유기에 MAC 어드레스 복제(MAC Cloning) 신공을 발휘해 억지로 엮어내는 데 성공했다. 물리적 병목을 뚫어냈으니 이제 끝인 줄 알았다.
🔍 2. 증상 분석: 길 잃은 패킷과 할당되지 않는 로컬 IP
MAC 복제로 라우터를 교체했음에도 OpenVPN은 연결되지 않았다. 가장 큰 증상은 VPN 연결 시 로컬 IP(인터넷 공유기 대역)가 제대로 할당되지 않는 현상이었다. 운 좋게 IP를 받아 연결 상태(Connected)가 떠도, 라우팅 테이블이 꼬이면서 응답 테스트 시 목적지를 찾지 못해 세션이 끊어졌다.
가장 원시적이고 확실한 방법인 ping 테스트로 회선 자체의 순수(Raw) 상태를 체크해 보았다.
> ping 8.8.8.8 -t
...
64 bytes from 8.8.8.8: icmp_seq=101 ttl=116 time=65.2 ms
64 bytes from 8.8.8.8: icmp_seq=102 ttl=116 time=78.1 ms
Request timed out. (응답이 없습니다.)
64 bytes from 8.8.8.8: icmp_seq=104 ttl=116 time=62.8 ms
...
비정상적인 지연율 (Latency): 대마도 로컬이나 일본 내 게이트웨이를 타는 핑이 기본 62~78ms 사이를 널뛰고 있었다.
Packet Loss (패킷 손실): 약 10개의 패킷을 보내면 1번 꼴로 Request timed out이 발생했다. 패킷 로스율 10%. TCP/UDP 통신, 특히 세션 유지가 생명인 VPN에서 10%의 패킷 드랍은 사형 선고다.
이때 눈치를 챘어야 했다. 하지만 "일본 ISP의 해외망 QoS나 UDP 차단 때문일 것이다"라는 잘못된 가설을 세우고, 기나긴 삽질을 시작했다.
🛠️ 3. 기술적 우회 시도 (그리고 장렬한 실패)
Attempt 1: 일본 내 백본망 우회 (Oracle Cloud 도쿄 리전 + WireGuard)
대마도에서 한국으로 쏘는 해저 케이블 라우팅이 막혔다고 판단했다. 그래서 일본 내 최고의 백본망을 자랑하는 오라클 클라우드 도쿄 리전에 인스턴스를 파고 WireGuard 도커(Docker)를 올렸다.
가설: [대마도 ➡️ 도쿄 우회 ➡️ 한국] 경로를 타면 로컬망의 해외망 차단을 우회할 수 있을 것이다.
결과: 도쿄까지 가는 과정에서도 패킷 로스가 발생하며 실패. 패킷이 도쿄 데이터센터에 닿기도 전에 로컬망에서 증발해버렸다.
가설: OpenVPN의 프로토콜을 TCP로 강제 전환하고, 포트를 일반적인 보안 웹 서핑(HTTPS)과 동일한 443 포트로 변경해 트래픽을 위장한다.
결과: 핸드셰이크는 성공했으나, 이내 극심한 패킷 로스로 인한 TCP 재전송(Retransmission) 폭풍이 몰아치며 오버헤드를 견디지 못하고 연결이 뻗어버렸다.
Attempt 3: MTU (최대 전송 단위) 튜닝
일본망 특유의 캡슐화 오버헤드로 인해 패킷이 단편화(Fragmentation)되면서 유실되는 현상을 의심했다.
가설: VPN 인터페이스의 패킷 크기(MTU)를 기본 1500에서 1420, 1360, 심지어 1280까지 점진적으로 줄여 패킷 쪼개짐을 방지한다.
결과: 패킷 로스율이 아주 약간 줄어드는 듯했으나, 근본적인 연결 끊김은 전혀 방어하지 못했다.
Attempt 4: DNS 우회 및 IP 모니터링 스크립트 작성
로컬 통신사 DNS의 오염이나 차단을 막기 위해 커스텀 DNS 설정으로 우회했다. 동시에, 연결이 수시로 끊어지는 상황에서 VPN 생존 여부를 파악하기 위해 쉘 스크립트를 하나 짰다.
조치: 주기적으로(cron) curl ifconfig.me를 날려 현재 내 외부 IP가 한국 대역으로 정상 인가되었는지, 아니면 일본 로컬로 풀려버렸는지 체크하여 로그를 남기도록 했다.
결과: 꼬박꼬박 쌓이는 [Connection Lost], [IP Reverted to JP] 메시지만 멍하니 쳐다봐야 했다.
💡 4. 최종 결론: 무너진 고속도로 위에서는 스포츠카를 몰 수 없다
하루 종일 도커 컨테이너를 올리고, TCP 443 우회부터 MTU 튜닝까지 L3(네트워크 계층)에서 L7(응용 계층)을 아우르는 모든 삽질을 끝낸 후 내린 결론은 허탈했다.
문제는 내 VPN 세팅도, 프로토콜도 아니었다. 전봇대에서부터 Super E100을 거쳐 들어오는 인터넷 회선 자체가 완전히 맛이 간 상태였다.
기본 핑이 70ms를 넘나들고 패킷 로스가 10%씩 발생하는 너덜너덜한 흙길 위에서, 나는 그동안 "왜 페라리(WireGuard)나 포르쉐(OpenVPN)가 달리지 못하냐"며 엔진 오일(MTU)을 갈고, 번호판(TCP 443)을 바꿔 다는 헛수고를 하고 있었던 것이다. 인프라망 자체가 물리적 장애를 겪고 있는 상황에서는 엔드 유저의 그 어떤 화려한 기술적 꼼수도 무용지물이었다.
📝 오늘의 교훈
OSI 7계층 트러블슈팅의 대원칙을 잊지 말자. 화려한 프로토콜과 소프트웨어를 의심하기 전에, 제발 L1 물리 회선의 순수 핑 상태부터 체크하자. (핑 로스 10%면 거기서 소프트웨어 디버깅은 멈췄어야 했다.)
일본 통신망의 폐쇄성: Super E100과 3개의 얽히고설킨 단말기들이 보여준 기형적인 인증 구조는, 문제가 발생했을 때 개인이 물리 계층을 통제하거나 트러블슈팅하는 것을 원천적으로 차단한다.
대마도 로컬 인터넷망이 자체적으로 복구될 때까지 나의 터널링 삽질은 강제 휴업이다. 기형적인 구형 네트워크 인프라를 얕보다 소중한 하루를 통째로 날려버린 뼈아픈 삽질기를 마친다.
