▲

IPv4 연결 없이 인터넷 사용하기

 (jamesmcm.github.io)
1P by GN⁺ 1일전 | ★ favorite | 댓글 1개
  • IPv4 연결이 중단된 상황에서도 IPv6와 WireGuard, Hetzner VPS를 통해 전체 인터넷 사용이 가능해짐
  • Carrier Grade NAT(대규모 NAT) 로 인해 IPv4만 장애가 발생했으나, IPv6는 영향을 받지 않았음
  • WireGuard 터널을 설정하여 VPS를 통해 IPv4 트래픽을 터널링함으로써 정상적인 웹사이트 이용 환경을 복구함
  • 네트워크 네임스페이스와 Docker 활용법, 그리고 MTU 이슈 해결 방법도 나옴
  • Linux 환경과 오픈소스 도구 덕분에 복잡한 네트워크 문제를 스스로 해결하는 경험을 강조함

개요

며칠 전, 필자는 정전 이후 집의 라우터에서 IPv4 접속이 끊기는 문제를 겪었음. 다행히 IPv6 접속은 정상이라 일부 웹사이트(Google, Meta 등)에는 접속이 가능했으나, 대다수 사이트(GitHub 등)는 접속할 수 없는 상태였음. 이에 Linux, WireGuard, Hetzner VPS를 활용하여 IPv6만으로 전체 인터넷 이용 환경을 복구한 과정을 정리함.

장애 원인과 배경

네트워크 환경 이상 발견

  • 정전 후 복구 과정에서, IPv6 서버는 접속이 정상이나, IPv4 서버는 접속 불가 현상 확인
  • 진단 명령어(ping -6, traceroute) 실행 결과도 IP 버전에 따른 차이만 드러남
  • 문의 결과, 통신사 측 CG-NAT(Carrier Grade NAT) 계층에서 IPv4 변환에 문제가 발생한 것으로 판명됨
  • ISP 측 정비까지는 며칠 소요 예상으로, 직접 해결이 필요해짐

NAT와 CG-NAT 설명

  • NAT(Network Address Translation) : 여러 장치가 하나의 공인 IPv4 주소를 공유하게 해주는 방식임
    • 라우터에서 내부 IP를 공인 IP와 고유 포트로 치환해 트래픽을 관리, 역방향 전송 시 매핑 정보로 내부 목적지 복원
    • 이 구조로 인해 암묵적인 방화벽 역할과 포트 포워딩의 필요성이 생김
  • CG-NAT(Carrier Grade NAT) : ISP가 각 가정용 라우터를 대상으로 다시 NAT를 한 번 더 적용하는 계층 구조
    • IPv4 주소 부족 문제로 ISP 내부적으로 NAT를 중첩 적용함
    • CG-NAT 환경에서는 포트 포워딩 등 서비스 제공이 더욱 제한적임
    • IPv4 트래픽만 장애가 발생한 이유가 바로 이 계층 내 IPv4 패킷 처리 문제 때문임

IPv6의 장점

  • IPv6 주소 공간이 압도적으로 커 NAT 없이도 각 기기에 직접 주소 할당 가능
    • 대부분의 가정용 라우터에는 /64 서브넷이 할당되어 수조 개의 주소 사용 가능
  • 별도의 NAT가 불필요해 직접 통신 가능하지만, 방화벽 설정은 더욱 중요해짐
  • CG-NAT은 IPv4에만 적용되기 때문에, 본 사고에서는 IPv6만 정상 동작함
  • 하지만 아직 많은 서버(예: GitHub)는 IPv6만으로는 접속 불가임

WireGuard 터널로 IPv4 복구

구현 개요

  • Hetzner VPS(IPv4/IPv6 스택 모두 지원) 와 WireGuard를 활용하여 IPV6로만 인터넷 연결이 된 상태에서 전체 인터넷 접속 가능 환경 구축
    • VPS에서 WireGuard 서버 운영 및 클라이언트 장비와 터널 구축
    • 트래픽은 IPv6를 통해 VPS로 우회되어, VPS를 경유해 전체 사이트(IPv4 포함)에 접근 가능함
    • Dual-Stack Lite와 유사한 원리

서버 및 클라이언트 구성 예시

  • WireGuard 서버 구성에서 IPv4/IPv6 트래픽 모두 처리
    • MASQUERADE(동적 IP 변환), SNAT(고정 IP 변환) 규칙 예시 포함
    • 직접 할당된 글로벌 IPv6를 활용해 NAT 없이도 바로 WireGuard 피어 연결 가능함
    • PostUp/PostDown 항목을 여러 번 적어 각 명령 순차 실행 가능
  • 클라이언트 설정 예시
    • 직접 할당된 IPv6 주소 또는 NAT된 ULA 조합 예시 설명
    • AllowedIPs에 0.0.0.0/0, ::/0 적용으로 전체 트래픽 터널링 가능
    • 구글 DNS(IPv4, IPv6) 및 MTU 설정 방법 제공

터널 정상 작동

  • 양쪽 WireGuard 구성 완료 후, IPv4/IPv6 모두 정상 터널링
  • 부인 PC에도 동일 방법 적용하여 Linux WireGuard 클라이언트 간편 설치 진행
  • 단, 사내 VPN과 동시 연결은 일반적으로 불가하므로 추가 네트워크 namespace 사용 필요

네트워크 네임스페이스와 Docker

기능 및 활용법

  • vopono 등 도구로 애플리케이션별 네트워크 네임스페이스 생성, 해당 namespace에서 VPN 또는 WireGuard 인터페이스 직접 지정
    • 별도의 MASQUERADE 규칙 지정 필요, 내부 트래픽을 WireGuard 터널로 강제 전환
    • 외부와 격리된 DNS, gai.conf(IPv4 우선 DNS 설정) 등 설정 팁 포함
  • 네임스페이스 내부에서 VPN 접속 및 애플리케이션 실행 방식 구현 예시
    • 같은 네임스페이스에서 여러 서비스 실행으로 네트워크 충돌 미연 방지

Docker 컨테이너와의 조합

  • Docker 데몬은 기본적으로 호스트 네트워크 소켓을 사용하므로 일반 네임스페이스 실행만으로는 접근 불가
    • mount namespace, /sys 바인드 마운트 등 Unix 가상화 기법으로 workaround 제시
    • Dockerd를 네임스페이스 내부에서 실행, 별도의 소켓과 데이터 루트 지정해 컨테이너 내 인터넷 연결 복구
    • 복잡한 네트워크 브리지 환경에는 추가 세팅 필요 가능성 언급

WireGuard MTU(MTU: 최대 전송 단위) 이슈

  • WireGuard 연결 후 일부 웹사이트만 접속불가(SSL 등), ping은 정상 응답되는 현상 발생
  • 다양한 크기의 ping 테스트로 MTU가 너무 높아 큰 패킷이 도중에 드롭되는 원인을 규명
    • MTU를 1280으로 낮춰 문제 즉시 해결
  • MTU란, 한 번에 전송 가능한 최대 패킷 크기를 의미함
    • 터널/캡슐화 오버헤드 감안해 적절한 MTU 설정 필요, 그렇지 않으면 대용량 패킷 전송 시 연결 장애 발생
    • IPv6는 규격상 최소 MTU가 1280임

결론 및 활용 조언

  • WireGuard VPN 서버 구축, 네트워크 네임스페이스 관리, Docker 특수 환경 설정, MTU 트러블슈팅 등 Linux와 오픈소스 도구를 활용한 네트워크 문제 자가 진단 및 해결 경험 강조
  • Hetzner VPS 등의 서비스는 가격대비 안정적이며 WireGuard 등 합법적 네트워킹 서비스 운영이 용이함
  • 오픈소스 라우터 펌웨어(OpenWRT)와 Linux 네트워킹 기법의 가치 재평가
    • 직접 네트워크를 관리/수정할 수 있는 유연성이 원격 업무 환경에서 큰 이점을 제공
    • 충분한 이해와 연습이 있다면 복잡한 네트워크 장애도 스스로 해결 가능함

참고 자료

  • Tailscale – How NAT Traversal Works
  • ArchWiki – WireGuard use case 예시
  • Unix StackExchange – 네임스페이스 내 Docker 트릭
  • AskUbuntu – DNS 우선순위 설정

(관련 스크립트, config, 팁, 참고 링크 원문 참조)

▲
GN⁺ 1일전  [-]
Hacker News 의견

  • 제목이 약간 오해를 줄 수 있는 느낌인데, 사실 이 글은 “IPv6 터널을 통해 VPS로 연결해서 IPv4 인터넷에 접속하기”에 더 가깝다는 내용임, 흔히 4in6이라고 부름
    어쨌든 흥미로운 방식임
    우리 ISP에서 IPv4에 장애가 나면 바로 전체가 다운되어 지원 이슈가 비교적 단순하게 생기는데, IPv6에 장애가 나면 부분적으로 이상 동작하고, 느린 연결이나 간헐적 불통 등 이상하게 나타난다는 경험임
    특히 게이트웨이가 IPv6 있다고 착각하면 사용자 입장에서 문제가 더 골치아픈 형태로 몇몇 기능만 작동하지 않는 등으로 보임

    • 최근에 IPv4가 잠시 안 됐을 때 Github가 안 돼서 그제야 알게 되었음
      요즘은 대부분의 소비자 웹사이트가 IPv6로는 정상 동작함
      다만 라우터가 오직 IPv4 DNS만 제공하는 분들은 완전히 인터넷이 끊어지는 문제가 있었음
      Microsoft가 좀 더 신경 썼으면 좋겠다는 생각임
      IPv4가 돌아오는지 확인하려면 라우터에 할당한 mDNS 호스트네임을 기억해야 했던 점도 있음

    • 솔직히 IPv4가 끊긴 적이 집에서 있었는데, 아내는 눈치도 못 챘음
      Google, Facebook, Apple/iCloud, CloudFlare 기반 서비스 거의 대부분이 IPv6로 잘 동작하는 상황임

    • 내 경험도 비슷함
      IPv6 문제는 정말 원인 파악과 재현이 힘들고 “내 컴퓨터에서는 잘 되는데?”만 반복됨

    • 대부분 ISP가 여전히 IPv6를 차단하는 상황인데, 소기업들도 IPv6 시도만 하고 AAAA 레코드 같은 걸 잊어버리는 경우가 많음
      그래서 사용자들은 친구네 집이나 카페 등 저가형 ISP 환경에선 뭔가 되는데 자기 집에선 안 되는 상황이 생김
      이상하게 들릴 수 있는데, 특별한 좋은 해결책이 있는 것 같진 않고 그냥 IPv4가 사라지길 바라는 게 현실
      Happy Eyeballs 같은 기법(동시에 IPv4/IPv6 접속 시도하고 더 빠른 쪽 선택)도 있지만 실제로는 응용 프로그램 단에서 문제가 더 많이 발생하고, 그걸 해결할 일반적인 방법이 부족함
      나 같은 경우엔 네트워크에서 IPv6는 활성화하고, 브라우저에선 IPv6 DNS를 끄는 식의 타협책을 쓰는데 만족스럽진 않음

  • IPv6를 써보고 싶지만 ISP가 제공하지 않는 경우, Hurricane Electric(HE)에서 무료로 터널 서비스를 아주 오래전부터 제공함
    관련 정보 링크로는 tunnelbroker.net, ipv6.he.net, Fedora 설정법, Brandon Rozek 블로그, DD-WRT 설정법, Mikrotik 포럼 자동업데이트 스크립트, RockyLinux 가이드 같은 다양한 셋업 방법 있음

    • 한 가지 주의할 점이 있는데, 스트리밍 서비스를 쓸 때 이 터널을 막는 경우가 많음, 마치 VPN 우회로 인식해서 지역 제한 컨텐츠 차단 때문에 발생함
      그래도 RA(라우터 광고) 기능 덕분에 어떤 네트워크 장치도 /64 단위로 IPv6 네트워크를 브로드캐스팅해서, 라우터가 HE 터널을 직접 지원하지 않아도 네트워크 내 여러 기기들이 IPv6 주소 사용 가능함(단, 라우터가 보안상 RA를 필터하지 않을 경우)
      집에서 무언가 직접 서비스하려고 할 때 포트포워딩 없이 IPv6만으로 할 수 있어서 매우 편리함

    • Hurricane Electric 서비스는 좋지만, 이제 ISP가 IPv6를 기본 제공하는 일이 점점 많아지면서 일반 사용자는 터널 서비스에서 이탈 중임
      그리고 일부 네트워크 서비스들이 he.net 터널을 남용 또는 악용으로 보고 막아버리는 경우가 많아져서, 결국 내 네트워크에선 대부분 IPv6 사용을 중지해야 했던 상황임

    • 참고할 점, Hurricane Electric 터널은 반드시 공인 IPv4 주소를 ISP로부터 받아야만 동작함
      만약 캐리어그레이드 NAT 등 NAT 환경에 있다면, IPv6를 집에 도입하려면 이 방법 대신 다른 솔루션을 찾아야 함

    • HE의 무료 6in4 터널을 OpenBSD로 5년째 쓰고 있는 “고객” 경험임
      /etc/hostname.gif0 파일 등으로 네트워크 설정만으로 꾸준히 잘 동작함
      AWS에서 IPv4없이 일부러 구성한 VPS 클러스터와의 통신에도 씀
      AWS가 IPv4 주소 비용을 적극적으로 부과해서 이 방법이 비용 절감에 매우 큰 도움이 된다는 생각임

  • 만약 진짜 v6 only 환경에서 v4 접속이 필요하다면, 공개 DNS64+NAT64 Gateway를 쓰면 손쉽게 해결 가능함
    nat64.net의 공개 Provider 리스트 참고
    평소에는 DNS 서버만 바꿔주면 가능함
    DNS64는 AAAA 레코드가 없는 사이트에 대해 NAT64 박스에 연결될 수 있도록 AAAA 레코드를 합성해서 제공함
    그러면 NAT64가 트래픽을 받아서 프로토콜 변환 + NAT를 해줌
    실습 예시로 dig나 curl 명령어 써서 바로 github 같은 곳에 접속 가능함

    • 유럽에선 nat64.net을 직접 써도 꽤 쾌적하게 동작함
      실제로 좋은 경험만 있었음

    • Cloudflare WARP를 쓰면 훨씬 빠른 속도를 체감할 수 있음
      WARP를 통해 IPv4 주소에 직접 접근도 가능함

  • 가끔 IPv6-only 사용자가 있다는 게 신기함
    예전에 반대 상황(IPv4-only 환경에서 IPv6 접속 필요)에서는, 서버에 완전한 제어권이 있다면 아주 빠르게 쓸 수 있는 해결책으로 SOCKS5 프록시(ssh -D 옵션) 사용이 최고였음
    브라우저만 socks 프록시로 지정하면 바로 활용 가능함
    시스템 전체로 하면 오히려 ssh 연결이 끊길 수도 있어서 그건 걱정되는 부분임

  • 나와 비슷한 상황임
    2주 정도 IPv4 장애 관련 티켓이 열려있는데 “곧 기술자가 처리한다”는 답변만 반복됨
    IPv6는 정상이라 전체 장애로 보지 않는 듯함
    독일에선 이런 경우에 소비자 보상 관련 법규가 있지만, 이번 케이스가 해당되는지 확인할 예정임
    블로그 글에서 제안하는 방식의 문제는 데이터센터 IP 대역이 여러 서비스에서 차단되거나 캡차 같은 우회를 요구하거나 VPN 업체 IP처럼 다뤄지는 거라, 피할 방법이 별로 없음
    내 경우 집 전체에서 해결해야 해서 라우터에서 Wireguard로 라우팅 및 NAT 규칙을 세팅했는데, Ubiquiti EdgeRouter 같은 오픈형 장비라 다행이었음
    만약 FritzBox였다면 이 작업이 훨씬 어려웠을 것 같음
    다만, 라우터 성능이 부족해 연결량이 많으면 느려지는 단점 있어서 하드웨어 오프로딩 지원되는 IPSec으로 교체해야 고민 중임

    • FritzBox도 VPN 연결을 위한 매우 훌륭한 GUI 설정 과정을 제공함
      FritzBox to FritzBox가 기본 전제이나, 호환되는 VPN이면 OK임
      고정 IPv4/IPv6 라우트 설정도 제공함
      가장 큰 문제는 맞은편에서 어떤 IPSec 암호화 설정을 요구하는지 파악하는 것인데, Wireguard는 더 쉽지만, 반대로 하드웨어 가속 문제가 있음
      필요하다면 FritzBox 전체 설정을 백업해 직접 편집 후 체크섬만 다시 계산해서 재입력하는 테크닉도 있음
      AVM은 사용자에게 노출되지 않는 엄청난 양의 세부설정을 숨겨놓았는데, 의도적임
      실수로 라우터를 망가뜨리지 않게 일부러 좀 어렵게 해둔 면이 있음

    • 독일 상황은 잘 모르겠지만, 네덜란드에선 고정+모바일 인터넷 모두 같은 ISP를 쓴다면, 유선망에 장애 났을 때 무료 모바일 데이터를 요청할 수 있음
      가능하다면 ISP에 해당 옵션 문의하는 걸 추천함

  • 오랜 시간이 지나도 모든 장비와 가정용 랩을 IPv6로 바꿔야 할 명확한 이유를 못 찾겠음
    포트포워딩과 방화벽 설정이 그나마 직관적이고, IPv6로 바꿀 땐 몇 주씩 문제해결, 방화벽, 주소 재설정 등 복잡함이 예상됨
    내가 뭘 놓치고 있는지 궁금함

    • 현실적으로는 지금 단계에선 놓치고 있는 것은 거의 없음
      앞으로 Google, Cloudflare 등 대기업들이 계속 늘어나는 IPv4 주소 비용을 감당 못 하게 되면 IPv6로 인센티브를 줄 가능성도 있음(예: IPv4 연결은 속도 제한 등)
      AWS도 예전에는 미사용 IPv4 Elastic IP만 요금 부과하더니, 이제는 사용중이어도 무조건 요금 부과함
      향후 게이트웨이나 라우터를 업그레이드할 때 IPv6를 그냥 켜두는 게 좋을 듯하고, 지금은 IPv4/IPv6 듀얼로 쓰면 기존 장비와 기존 서비스 문제없이 작동함
      IPv6 자동주소할당 관련해서는 역사적으로 방식이 뒤죽박죽이었으나 SLAAC로 정착되는 분위기이고, ISP 중심에선 DHCPv6를 상당히 오래 사용할 전망임

    • 사실 그렇게 어렵진 않음
      특별히 복잡한 홈네트워크가 아니라면 저녁 잠깐만 투자해도 IPv6 세팅 가능함
      Comcast 기준으로 라우터에서 IPv6 옵션 켜면 ISP에서 prefix 받아오고, 이것만으로도 자동으로 네트워크에 광고되어서 원하는 포트만 방화벽 열어주면 끝임

    • 놓치는 부분 없음
      엔터프라이즈 환경에서는 IPv6 도입 플러스보다 단점이나 복잡성이 큼
      나는 약 3500대 장비, 7개 건물, 2개의 10Gbps, 1개의 4Gbps WAN, 그리고 26개 공인 IPv4 주소 관리
      지금까지 IPv6 써야만 하는 이유가 전혀 없음
      듀얼스택으로 운영하면 네트워크 불필요한 부하와 복잡성 발생함
      오히려 최근에 고정 IPv6 주소블록을 받으려 2번 신청했는데 계속 거절당함
      실질적으로 이득은 없고, 심지어 할당받기도 어려운 상황임
      ARIN IPv6 최초 신청 가이드 내용을 보면,
      → IPv4 할당 보유
      → IPv6 멀티홈 즉시 예정
      → 1년 내 13개 엔드사이트(오피스 등)
      → 1년 내 2000개 IPv6 주소
      → 1년 내 200개의 /64 서브넷
      중 하나라도 충족해야 신청 대상임

  • Apple App Store 정책 중 모든 앱이 IPv6-only 네트워크에서 동작해야 한다는 요구사항은 정말 높이 평가함
    개발자 입장에선 첫 경험에 놀랄 수 있는데, 소비자 입장에선 이런 요구가 매우 반가움

    • 하지만 이 정책이 서버단에서 IPv6 주소 보유를 필수로 요구하진 않음

    • 그러면 앱으로 github가 v6에도 접속 가능한지 궁금함

  • 회사 업무에서 내부 인프라 접근을 위해 IPv6 only VPN을 여러 개 운영 중임
    가장 큰 문제는 Windows, macOS 클라이언트가 반드시 v6 DNS 서버가 필요하다는 점임
    클라이언트가 v6 지원 네트워크에 있을 수도 있고 아닐 수도 있기에, VPN 내부에서 직접 DNS 서버를 돌린 뒤 이를 클라이언트에 자동 전달해주지만
    VPN 연결이 끊어지고도 Wireguard 앱이 원래 DNS로 복구해주지 못해서 다양한 문제가 발생함

    • 나는 ISP의 IPv4 only 네트워크와 macOS 환경에서도 별도의 DNS 없이 IPv6-only를 잘 활용한 적 있음
      정확한 방법은 기억 안 나지만, macOS가 v6 주소만 부여해도 문제 없이 동작
      ULA 주소를 호스트에 지정하면 되고, 이건 유저가 방법만 알면 쉬운 일임
      VPN 앱이 직접 IPv6-only 네트워크에 ULA를 추가해주는 스크립트를 활용할 수 있음
      단, 만든 ULA 주소를 무작정 방치하면, 사용자가 다른 v6 네트워크로 이동할 때 문제가 될 수 있음

  • 동일 상황 겪는다면 ssh 프록시(ssh -D 8080 user@hostname)로 손쉽게 socks 프록시 환경 구축 가능함
    이 연결 후 브라우저 프록시 주소를 localhost:8080으로 지정하면 됨

    • 나도 똑같이 조언하려고 했음
      임시 문제 해결용으로 매우 간단하면서, 필요할 땐 상시툴로 써도 훌륭함
      단, sshd_config에서 “AllowTcpForwarding”이 활성화되어야 함

    • 나는 공공 와이파이 쓸 때 항상 이 방법을 씀
      VPN 서비스 비용 안 내도 되고, 신뢰할 필요 없이 내 infomaniak 서버에서 socks 프록시로 보내면 됨

  • 개인적으로 IPv4에 대해 불만이 많고, 특히 내 ISP가 강제로 IPv4만 제공해서 더 답답함
    IPv6 도입이 이렇게 더딘 것은 기술업계의 큰 실패로 봄
    누가 책임져야 할지 고민임
    라우터 제조사가 허접한 펌웨어를 만드는 건지, ISP의 IPv4 추진 리더십 문제인지, IPv4 주소 투기꾼 때문인지, 네트워크 엔지니어 및 지원 인력 교육 부족 탓인지 등 원인에 대한 근본 논의가 더 필요하다고 생각함
    인터넷이 TLS 1.0에서 비교적 잘 전환된 것처럼, IPv4도 넘어갈 수 있어야 하지 않나 싶음
    레거시 코드를 위한 AI 프록시 같은 게 나중엔 해결책이 될 수도 있을듯함

    • TLS 1.0에서 전환이 더 쉬웠던 이유는 end-to-end principle 덕분임
      서버와 클라이언트만 새 프로토콜 지원하면 되는데, 중간 장비(라우터, 스위치 등)는 네트워크 계층(IP)만 보면 됐었고, TLS 신규 버전과 상관없었음
      네트워크 레이어 프로토콜(IP)까지 변경하면 중간 네트워크 장비 모두 영향을 받음
      참고로 TLS 1.3 도입 때도 middlebox가 end-to-end 원칙을 깨고 트래픽을 감시/변조해, 호환성 때문에 TLS 1.3이 TLS 1.2 재연결처럼 위장하는 꼼수를 써야 했던 황당함도 있었음

    • 그 차이는 TLS는 서버/클라이언트만 지원하면 되고, 중간 네트워크 장비는 TCP 패킷만 보면 됨
      IPv6는 서버-클라이언트 사이 모든 중간 장비가 지원해야 하므로, “최소공통분모”에 종속적인 기술임
      TLS 업그레이드는 크게 변경되는 부분 없었던 반면, IPv6는 너무 많은 부분을 동시에 바꿨음
      지금 돌아보면, IPv6는 단순히 주소를 64비트로만 늘렸으면 차라리 더 보급이 쉬웠으리라는 아쉬움임

    • 현실적으로는 많은 사람들이 교체의 실질적 이점이 너무 적거나 거의 없어서 도입에 소극적인 것임
      거대 IPv4 음모론 같은 건 없이, 단지 일과 리스크 대비 효과가 적음

    • 네트워크 업계 농담에 “IPv6는 엔지니어링 문제에 끼워 맞춘 학술적 해결책”이라는 말이 있음
      대규모로 IPv4와 호환성까지 유지하면서 실제 현장 도입, 운영, 유지보수까지 생각하면 IPv6가 너무 복잡함
      사실상 주소 부족 말고 실질적인 문제도 없는 IPv4가 없어질 리도 없음
      그러다 보니 현장에서는 IPv6가 실질적 솔루션이 되지 못하고 있음

답변달기