DNS 터널링·검열 우회 도구의 합법성은 국가·지역마다 크게 다릅니다. 일부 국가에서는 우회 도구의 사용·배포 자체가 형사 처벌 대상이 될 수 있습니다. 저장소 역시 스스로를 "과학적·연구 목적 프로젝트"로 규정합니다. 이 문서는 특정 국가의 검열을 뚫는 운용 지침을 제공하지 않으며, DNS·터널링·재전송 프로토콜 설계 원리를 학습하는 데 초점을 둡니다. 실습은 반드시 본인 소유의 서버와 합법적인 환경에서만 진행하고, 거주 지역의 법률을 직접 확인한 뒤 책임 있게 사용하세요.
이 레포가 무엇을 하는 물건인가.
검열 환경에서 방화벽은 HTTPS·VPN·SSH를 막아도 DNS만은 통과시킨다. 그래야 어떤 사이트든 이름→IP 변환이 되기 때문이다. MasterDnsVPN은 당신의 실제 트래픽을 암호화·분할해 aGVsbG8.v.example.com 같은 평범해 보이는 도메인 질문에 실어 보내고, 응답(레코드)에 답신 데이터를 담아 돌려받는다.
핵심은 단순 "터널이 된다"가 아니라 "열악한 네트워크에서도 끊기지 않고, 빠르게"다. 그래서 다중 리졸버·패킷 중복·자체 재전송(ARQ)·초저(超低) 오버헤드라는 네트워크 공학 장치들이 겹겹이 들어간다.
MasterDnsVPN은 DNS 질의/응답에 TCP 트래픽을 실어 나르는 터널링 VPN이다. 저장소 본문 표현 그대로 — "DNS 질문과 응답을 통해 TCP 트래픽을 운반하는, 과학적·연구 지향 프로젝트"다. 큰 목표는 DNSTT·SlipStream과 비슷하지만, 구조와 구현 접근이 근본적으로 다르다고 스스로 밝힌다. 주력 구현은 Go이며(레거시 Python 버전도 존재), 서버는 한 줄 설치 스크립트로 systemd 서비스로 올라가고, 클라이언트는 로컬에 SOCKS 프록시를 띄워 앱 트래픽을 받는다.
v.example.com의 모든 DNS 질문에 답하는 공식 네임서버"가 되도록, DNS에 NS 레코드로 그 서브도메인을 위임받는 것. 그러면 전 세계 어느 리졸버에 질문을 던져도, 재귀 해석 끝에 그 질문이 결국 터널 서버까지 도달한다. 이것이 DNS 터널링이 "리졸버를 우회 통로로 쓰는" 비결이다.트렌딩 이유 · 선배 도구(DNSTT·SlipStream) 대비 장점.
DNS 터널링 자체는 십수 년 된 아이디어(iodine·dns2tcp 등)다. 그런데도 MasterDnsVPN이 트렌딩에 오른 이유는 세 가지다. 첫째, "극한 검열에서 실제로 살아남았다"는 실전 서사 — 88일간의 인터넷 전면 차단 상황(국제 대역폭 99% 물리적 단절)에서도 동작했다고 보고한다. 둘째, 선배 도구 대비 측정 가능한 성능 우위 — 헤더 오버헤드를 5~7바이트로 줄여 DNSTT 대비 약 9배, SlipStream 대비 약 3.6배 빠른 속도를 주장한다. 셋째, 다중 리졸버 + 패킷 중복 + 백그라운드 헬스체크라는, 분산 네트워크 공학을 정통으로 적용한 안정화 설계다.
| 비교 항목 | SlipStream | DNSTT | MasterDnsVPN |
|---|---|---|---|
| 전송 프로토콜 | QUIC | KCP + Noise | 커스텀 프로토콜 + ARQ |
| 헤더 오버헤드 | ~24B | ~59B | 5~7B (DNSTT 대비 ≈88%↓) |
| 다중 리졸버 | 멀티패스 | 없음 | 멀티 리졸버 + 중복 전송 |
| 패킷 손실 안정성 | 양호 | 중간 | 매우 높음(멀티패스+ARQ) |
| 속도(상대) | DNSTT의 ~5배 | 기준 | DNSTT의 ~9배 |
| 구현 언어 | Rust | Go | Go (레거시 Python) |
| 리졸버 자동 복구 | 없음 | 없음 | 백그라운드 헬스체크로 부활 |
DNS는 데이터 전송용이 아니다. 질문(도메인 이름)에 담을 수 있는 바이트는 작고(라벨당 63B·전체 255B 제한), 중간 리졸버들은 캐싱·재정렬·잘림(truncation)·레이트리밋을 마구 일으킨다. 그래서 옛 터널들은 프로토콜 오버헤드가 크면 실효 대역폭이 바닥나고, 리졸버 하나가 막히면 통째로 끊겼다. 검열 환경의 네트워크는 패킷 손실까지 심하다.
① 5~7B 초저 오버헤드로 작은 DNS 라벨 안에 최대한 많은 실데이터를 욱여넣고, ② 여러 리졸버에 동시에 보내(멀티패스) 한 경로가 막혀도 다른 경로로 도달시키며, ③ 중요한 패킷은 중복 전송해 손실 확률을 낮추고, ④ 빠진 조각은 자체 ARQ(자동 재전송)로 다시 받는다. ⑤ 죽은 리졸버는 빼두고 백그라운드 헬스체크로 살아나면 다시 투입한다.
서버 · 클라이언트 · 인프라(DNS 위임)를 각각 본다.
| 요소 | 내용 |
|---|---|
| 주력 언어 | Go 1.25+ (go.mod: go 1.25.0) — 단일 정적 바이너리로 배포, 고루틴 기반 동시성에 강함(수많은 리졸버·세션 워커를 가볍게 굴림). 레거시 Python 버전도 병존. |
| 전송 계층 | UDP/DNS 위에 얹은 커스텀 프로토콜 + 자체 ARQ. TCP를 직접 안 쓰고, 신뢰성(순서·재전송)을 애플리케이션 레벨에서 직접 구현. |
| 신뢰성 | 스트림별 ARQ 윈도우(ARQ_WINDOW_SIZE=1000), 데이터/제어 패킷 분리 RTO(ARQ_INITIAL_RTO_SECONDS 등), 패킷 패킹. |
| 암호화 | 서버-클라이언트 공유 비밀키(encrypt_key.txt ↔ 클라 ENCRYPTION_KEY). 여러 암호화 방식을 골라 속도/보안 균형 조절. |
| 경로 다중화 | 멀티 리졸버 + 선택적 패킷 중복(duplication). 세션 멀티플렉싱으로 한 터널 위에 여러 논리 스트림. |
| 클라이언트 출구 | 로컬 SOCKS 프록시를 띄워, 앱·브라우저가 그 프록시로 트래픽을 흘려보내면 터널로 전달. |
MTU_TEST_PARALLELISM=32)해, 각 경로에 맞는 조각 크기를 정하고 너무 작은 리졸버는 걸러낸다. 작은 MTU에서도 동작하도록 오버헤드를 극단적으로 낮춘 이유가 여기 있다.서버 설치 스크립트(server_linux_install.sh)는 단순 다운로드가 아니라 고부하 DNS 서버를 위한 OS 튜닝까지 한다. 여기서 "검열 우회 도구"가 아니라 대용량 UDP 서버 운영의 정석을 배울 수 있다.
| 구성 항목 | 스크립트가 하는 일 |
|---|---|
| 53번 포트 확보 | 기존 systemd-resolved·dnsmasq·bind9·unbound 등 포트 53 점유 서비스를 탐지·중지하고 충돌 NAT 리다이렉트 규칙 제거. |
| 방화벽 | UFW / firewalld / iptables / nftables를 자동 감지해 53/udp·53/tcp 개방. |
| 커널 튜닝 | /etc/sysctl.d/99-masterdnsvpn.conf: UDP 버퍼(rmem_max·wmem_max=32MB), somaxconn, conntrack 한도, 짧은 UDP conntrack 타임아웃 등. |
| 리소스 한도 | nofile=1048576(파일 디스크립터 100만) — 수많은 동시 UDP 소켓 대비. |
| 서비스화 | masterdnsvpn.service systemd 유닛(Restart=always, LimitNOFILE, irqbalance로 멀티코어 패킷 분산). |
설치 스크립트는 "식당 개업 준비 매뉴얼"과 같다. 가게 자리(포트 53)에 이미 다른 가게(기존 DNS 서비스)가 있으면 정중히 내보내고, 손님 동선(방화벽)을 열고, 주방 화력(커널 버퍼·FD 한도)을 대량 주문에 맞게 키운 뒤, 자동 재오픈 장치(systemd Restart=always)까지 단다. "터널 코드"보다 이 운영 자동화 스크립트가 더 교과서적이다.
| 구성 | 역할 |
|---|---|
| KevinNet DNS | 동작하는 공개 리졸버를 발견·검증해 바로 쓸 수 있는 client_resolvers.txt를 생성해 주는 동반 도구. |
| Android 클라이언트 | 같은 Go 엔진 위에 얹은 모바일 클라이언트(별도 저장소). |
| 설정 파일 | 서버 server_config.toml / 클라 client_config.toml + 리졸버 목록 client_resolvers.txt. TOML 기반. |
앱 → DNS 질의 캡슐화 → 리졸버 → 터널 서버 → 인터넷, 그리고 핵심 설계 패턴.
핵심은 "클라이언트와 서버는 직접 연결되지 않는다"는 점이다. 둘 사이엔 항상 중간 DNS 리졸버(재귀 해석기)가 끼어 있고, 그 리졸버를 우체부처럼 이용한다. 클라이언트는 리졸버에게 질문을 던지고, 리졸버는 권한 위임(NS)을 따라 그 질문을 터널 서버까지 전달하며, 서버의 응답을 다시 클라이언트에게 돌려준다.
리졸버 하나에만 의존하면 그게 막히는 순간 끝이다. MasterDnsVPN은 client_resolvers.txt에 적힌 수십~수백 개 리졸버를 동시에 쓴다. 각 리졸버의 품질(지연·성공률·MTU)을 측정해 좋은 것에 트래픽을 더 보내고, 실패가 누적되면 일시 제거했다가 백그라운드 헬스체크로 회복되면 자동 복귀시킨다(원문: "background reactivation of healthy resolvers" — 비교 표에서 MasterDnsVPN만 ✅).
손실이 심한 망에서는 ARQ 재전송조차 왕복 지연(RTT)을 잡아먹는다. 그래서 중요한 패킷을 처음부터 2벌 이상, 서로 다른 리졸버 경로로 보낸다. 한쪽이 유실돼도 다른 쪽이 도착하면 그만 — 대역폭을 살짝 더 써서 지연과 끊김을 산다. 무조건이 아니라 "선택적(selective)"이라 평상시엔 절약한다.
DNS 라벨은 좁다. 헤더가 1바이트라도 작아질수록 실데이터가 늘어난다. MasterDnsVPN의 5~7B 헤더는 DNSTT(~59B)·SlipStream(~24B)을 압도하며, 이것이 곧 속도 우위(DNSTT 대비 ~9배 주장)의 직접 원인이다. 작은 MTU 리졸버에서도 살아남는 비결이기도 하다.
엽서 한 장에 쓸 수 있는 글자 수는 정해져 있다(=DNS 라벨 크기). 봉투에 우표·주소·반송지 같은 형식 정보(헤더)가 자리를 많이 먹으면 정작 본문 쓸 칸이 줄어든다. MasterDnsVPN은 이 형식 정보를 5~7글자로 압축해 엽서 한 장에 본문을 최대한 적어 보낸다. 그래서 같은 수의 엽서로 더 많은 내용을 더 빨리 전달한다.
한 번 맺은 DNS 터널 세션 위로 여러 논리 스트림을 동시에 흘린다(브라우저 탭 여러 개처럼). 또 순서에 민감하고 설정 비용이 큰 작업(스트림 셋업·SOCKS connect·DNS 조립)은 별도 지연 세션 워커(DEFERRED_SESSION_WORKERS=6, 큐 한도(DEFERRED_SESSION_QUEUE_LIMIT) 8192)가 전담해, 빠른 데이터 경로와 무거운 셋업 경로를 분리한다. 전형적인 "빠른 경로 / 느린 경로 분리" 동시성 설계다.
릴리스 바이너리 + 설정 + 설치 스크립트 중심 구성.
이 저장소는 소스 전체 공개형(cmd/, internal/ Go 소스) + 릴리스 바이너리 배포 + 운영 스크립트 겸용 구조다. 그래서 핵심은 설정 파일(.toml)과 설치 스크립트를 읽으며 동작을 역추적하는 것이다.
① README.md의 "DNS 레코드(A+NS) 만들기"로 위임이 왜 필요한지 이해 → ② server_linux_install.sh를 정독하며 대용량 UDP 서버 운영 자동화 패턴 학습 → ③ client_config.toml.simple의 ARQ·MTU·세션 키들을 보며 프로토콜 파라미터의 의미 추적. 바이너리를 못 읽어도 이 세 파일이 설계의 90%를 말해 준다.
DNS 프로토콜 · 터널링 · 검열 우회 원리 — 무엇을 배우고 무엇을 실습할까.
이 레포를 제대로 읽으려면 먼저 DNS를 알아야 한다. 질의(query)는 도메인 이름(라벨 시퀀스)으로, 응답은 레코드(A·AAAA·TXT·CNAME 등)로 구성된다. 라벨은 최대 63바이트, 전체 이름은 255바이트 제한. UDP/53이 기본이고 큰 응답은 TC(truncated) 비트로 TCP 재시도를 유도한다. 터널링은 이 "이름에 데이터를 담는다 / 레코드에 답을 담는다"는 구조를 통신 채널로 재해석한 것이다.
dig TXT example.com·dig +trace v.example.com을 직접 돌려 보고, 질의가 루트→TLD→권한 NS로 어떻게 위임을 따라가는지 출력을 한 줄씩 해석해 보라.임의 바이트를 도메인 라벨에 넣으려면 Base32/Base64류 인코딩으로 "도메인에 허용되는 문자"로 바꿔야 한다(라벨은 영숫자·하이픈만 안전). 받는 데이터는 레코드 응답에 인코딩한다. 여기서 "채널 용량 = (라벨 가용 바이트 − 헤더 오버헤드)"라는 공식이 나오고, MasterDnsVPN이 헤더를 5~7B로 줄인 이유가 정량적으로 와닿는다.
<encoded>.v.example.com 형태 라벨을 만들어 보고, 255바이트 한계 안에 실데이터가 몇 바이트 들어가는지 직접 계산하라.DNS·UDP는 순서·도착을 보장하지 않는다. 그래서 TCP가 커널에서 하는 일(시퀀스 번호·ACK·RTO·윈도우·재전송)을 애플리케이션이 직접 구현해야 한다. ARQ_WINDOW_SIZE·ARQ_INITIAL_RTO_SECONDS·데이터/제어 RTO 분리 같은 파라미터가 그 증거다. 이건 네트워크 프로그래밍의 정수를 배우는 최고의 교재다.
검열망은 ① 외부 직접 접속 차단, ② 강제 로컬 리졸버, ③ 높은 패킷 손실·레이트리밋이 특징이다. MasterDnsVPN의 대응(멀티 리졸버·중복·헬스체크·적응형 백오프)은 사실상 "적대적 네트워크에서의 가용성 공학" 카탈로그다. CDN·엣지 시스템 설계에도 그대로 옮겨갈 패턴이다.
server_linux_install.sh는 그 자체로 운영 교재다. 포트 충돌 해소, 방화벽 4종 추상화, 커널 버퍼·conntrack 튜닝, FD 한도 100만, systemd 자동 복구 — "코드를 잘 짜는 것"과 "서버를 잘 굴리는 것"이 다르다는 걸 보여 준다.
sysctl 항목(rmem_max, somaxconn, nf_conntrack_udp_timeout 등)을 하나씩 검색해, "왜 DNS/UDP 서버에 이 값이 필요한가"를 한 줄씩 주석 달아 보라.서버 · 클라이언트 · 그리고 반드시 필요한 "도메인".
| 구분 | 필요한 것 |
|---|---|
| 서버 OS | Linux (Ubuntu/Debian/RHEL·Rocky·Alma 계열). 아키텍처별 빌드: AMD64·ARM64·ARMV7·X86 + Legacy 빌드. |
| 서버 권한 | root(포트 53 바인딩·방화벽·systemd 필요). 패키지 매니저 apt/dnf/yum 중 하나. |
| 필수 자산 | 도메인 1개 — 서브도메인을 NS로 위임할 수 있어야 함(예: v.example.com의 A+NS 레코드). 공인 IP가 붙은 VPS 권장. |
| 네트워크 | 서버는 53/udp·53/tcp 인바운드 개방. DNS 전파 대기(수 분~최대 48시간). |
| 클라이언트 | Go 1.25+ (소스 실행 시) 또는 릴리스 바이너리 / Android 앱. 동작하는 리졸버 목록(client_resolvers.txt). |
| 공유 비밀 | 서버 encrypt_key.txt ↔ 클라 ENCRYPTION_KEY 완전 일치. 불일치 시 패킷이 쓰레기로 해석돼 터널 불통. |
위 실습·구성은 당신이 소유·통제하는 서버와 도메인에서, 거주 지역의 법이 허용하는 범위 안에서만 진행하세요. 우회 도구의 사용·배포가 금지된 지역에서는 이 도구를 운용하는 것 자체가 위법일 수 있습니다. 이 문서는 그런 환경에서의 사용을 권장하거나 지시하지 않습니다.
난이도별 5단계 — 모두 본인 소유 인프라/합법 환경 한정으로 설계.
본인이 보유한 도메인에 lab.example.com 서브도메인을 만들고, dig +trace lab.example.com으로 루트→TLD→권한 NS로 질의가 위임을 타고 내려가는 과정을 캡처한다. 터널 없이도 "왜 NS 위임이 터널의 핵심인지" 눈으로 확인.
client_config.toml.simple과 설치 스크립트를 읽고, ARQ·MTU·세션·리졸버 관련 파라미터 15개를 골라 "이름 / 기본값 / 무엇을 조절하나 / 너무 크면·작으면" 표를 직접 완성한다. 코드 실행 없이 설계 의도를 복원하는 훈련.
로컬 루프백에서 인위적 손실 30%를 주는 UDP 채널을 만들고, 그 위에 시퀀스 번호·ACK·RTO 재전송을 얹은 "신뢰성 있는 파일 전송"을 구현한다. ARQ_INITIAL_RTO·ARQ_WINDOW_SIZE를 바꿔가며 처리량/지연 변화를 측정. (자기 PC 안에서만)
본인 소유 VPS와 도메인으로 서버 설치 스크립트를 돌려 서버를 올리고, 로컬에서 클라이언트를 띄워 본인 서버까지의 왕복만 검증한다(외부 검열 회피가 아니라, 자기 인프라 안에서의 동작 학습). 끝나면 --uninstall로 깨끗이 제거. 거주 지역 법 확인 필수.
리졸버 N개에 대해 지연·성공률·MTU를 병렬 측정하고, 점수 기반으로 트래픽을 분배하며, 실패 누적 시 격리 → 백그라운드 재검사로 회복 시 자동 복귀시키는 모듈을 직접 만든다. 정적 임계값 대신 이동 창(moving window) 기반 적응형으로 설계할 것.
6주 코스 — DNS 기초에서 터널 프로토콜 설계까지.
| 주차 | 주제 | 실습 · 참고 |
|---|---|---|
| 1주차 | DNS 프로토콜 정독(레코드·라벨 한계·재귀 해석·위임) | RFC 1034/1035 핵심 · dig/dig +trace 실습 |
| 2주차 | DNS 터널링 원리 + 인코딩(Base32/64) + 채널 용량 계산 | iodine·dnscat2 개념 비교 · 과제 2 |
| 3주차 | UDP 위 신뢰성: 시퀀스·ACK·RTO·슬라이딩 윈도우(ARQ) | 과제 3 · KCP/QUIC 신뢰성 모델 읽기 |
| 4주차 | 멀티패스·패킷 중복·MTU 스캐닝 — 손실망 가용성 공학 | MasterDnsVPN 비교 표 · 과제 5 |
| 5주차 | 대용량 UDP 서버 운영: sysctl·conntrack·FD·systemd | server_linux_install.sh 한 줄씩 주석 |
| 6주차 | 검열 우회 큰그림 + 트래픽 위장/탐지(DPI) 윤리·법 | Tor pluggable transports · 지역별 법률 조사 |
본문·설정에 나온 용어 빠른 참조.
| 용어 | 의미 |
|---|---|
| DNS 터널링 | DNS 질의/응답 필드에 임의 데이터를 인코딩해 통신 채널로 쓰는 기법. |
| 리졸버 (resolver) | 재귀 해석 DNS 서버(예: 8.8.8.8). 터널의 중계 우체부 역할. |
| NS 위임 (delegation) | 서브도메인의 권한 네임서버를 터널 서버로 지정하는 NS 레코드. 질의가 서버까지 도달하는 근거. |
| ARQ | 자동 재전송 요청. ACK/RTO로 빠진 패킷을 다시 받아 신뢰성을 만드는 기법. |
| RTO | 재전송 타임아웃. 이 시간 안에 ACK가 없으면 패킷을 재전송. |
| 윈도우 (window) | ACK 없이 미리 보낼 수 있는 패킷 수. 크면 처리량↑ 메모리·재전송 비용↑. |
| 멀티패스 / 멀티 리졸버 | 여러 리졸버 경로로 동시에 보내 한 경로가 막혀도 도달시키는 설계. |
| 패킷 중복 (duplication) | 중요 패킷을 2벌 이상 다른 경로로 보내 손실 확률을 낮춤(대역폭↔안정성 트레이드). |
| MTU 스캐닝 | 리졸버별 최대 통과 페이로드를 측정해 조각 크기를 맞추고 부적합 리졸버를 제외. |
| 오버헤드 (overhead) | 실데이터 외에 붙는 헤더 바이트. 작을수록 같은 DNS 라벨에 더 많은 실데이터. |
| 세션 멀티플렉싱 | 한 터널 위에 여러 논리 스트림을 동시에 운반. |
| 지연 세션 런타임 | 순서 민감·셋업 무거운 작업을 전담 워커로 분리(빠른/느린 경로 분리). |
| SOCKS 프록시 | 클라이언트가 앱 트래픽을 받는 로컬 출입구. 앱은 여기로 보내면 터널로 전달됨. |
| encrypt_key | 서버·클라이언트가 공유하는 암호화 키. 불일치 시 터널 불통. |
| conntrack | 리눅스 커널의 연결 추적 테이블. 대량 UDP 처리 시 한도·타임아웃 튜닝 대상. |