이 글의 목차
이번 IPv6 DNS 하이재킹 문제인지 확인
이 글은 조건이 명확한 OpenClash 장애를 다룹니다. IPv6, 라우터 자체 프록시, 로컬 DNS 하이재킹과 Fake-IP를 활성화한 뒤 라우터의 SmartDNS 같은 리졸버가 공용 IPv6 DNS에 접근하면 198.18.x 주소를 받으며, 이후 도메인을 서버 주소로 사용하는 프록시 노드가 연결되지 않는 경우입니다.
일반 단말에서 웹페이지가 열리지 않거나 LAN 기기가 IPv6를 받지 못하는 현상, 구독 다운로드 실패 또는 AdGuard Home이 DNS 포트를 점유한 상황만으로는 같은 문제라고 단정할 수 없습니다. 장애가 라우터 자체에서 공용 IPv6 DNS로 보내는 조회에서 발생하는지 먼저 확인하고 IPv6가 보인다는 이유만으로 네트워크 전체 기능을 끄지 마세요.
아래 조건을 모두 충족할 때만 계속 진행하세요
- OpenClash 버전이 수정이 포함된 v0.47.156보다 낮거나 업그레이드 후 서비스를 아직 재시작하지 않음
- 시스템이 fw4/nftables 또는 legacy ip6tables를 사용하고 라우터 자체 프록시가 활성화됨
- 로컬 DNS 하이재킹과 Fake-IP가 활성화되어 있고 라우터 자체에도 SmartDNS 같은 리졸버가 있음
- 해당 리졸버에 공용 IPv6 DNS 업스트림이 설정되어 있고 노드 서버 주소가 도메인을 사용함
설정을 바꾸기 전에 롤백 가능한 버전 저장
먼저 OpenClash에서 플러그인 설정과 현재 구성을 백업하고 현재 설치 가능한 IPK 또는 APK를 보관하세요. 플러그인 버전, 코어 버전, 실행 모드, IPv6, 라우터 자체 프록시, 로컬 DNS 하이재킹과 SmartDNS 업스트림을 기록하면 업그레이드나 조정 후 네트워크가 더 나빠져도 원래 상태로 돌아갈 수 있습니다.
테스트 중에는 구독, 규칙, DNS 업스트림과 실행 모드를 동시에 바꾸지 마세요. 한 번에 하나만 변경하고 변경 전후의 조회 결과를 보존해야 노드가 복구된 뒤에도 어느 단계가 효과가 있었는지 판단할 수 있습니다.
롤백 자료 준비
플러그인 설정 내보내기
구성 파일 관리에서 설정과 현재 구성을 백업하고 라우터 외부 기기로 내려받아 보관합니다.
기존 설치 패키지 보관
현재 버전에 해당하는 공식 IPK 또는 APK를 저장하고 시스템이 opkg와 apk 중 어느 것을 사용하는지 기록합니다.
문제를 유발하는 옵션 기록
IPv6, 라우터 자체 프록시, 로컬 DNS 하이재킹, Fake-IP와 SmartDNS IPv6 업스트림의 상태를 적어 둡니다.
직접 관리 경로 준비
LAN을 통해 라우터를 관리할 수 있는지 확인하세요. 원격으로 유지보수할 때 예비 연결 없이 DNS와 방화벽을 변경하면 안 됩니다.
지정 서버 조회와 규칙 카운터로 원인 찾기
라우터 터미널에서 현재 접근 가능한 공용 IPv6 DNS를 직접 지정해 실제 도메인을 조회합니다. 정상 결과는 해당 도메인의 공개 A 또는 AAAA 레코드입니다. 198.18.0.0/16이 반환되고 실행 전후 해당 IPv6 OUTPUT DNS Hijack 규칙 카운터가 증가한다면 조회가 로컬 Clash DNS로 잘못 되돌아간 것입니다.
OpenClash issue #5251의 재현에는 2400:3200::1이 사용되었습니다. 이 주소가 현재 네트워크에 적합한지는 먼저 확인해야 합니다. IPv6 경로 자체가 도달할 수 없다면 시간 초과는 업스트림을 사용할 수 없다는 의미일 뿐 하이재킹이 발생했다는 증거는 아닙니다. 조회 도메인도 공개 레코드가 있다고 확실히 아는 일반 도메인으로 바꿀 수 있습니다.
nslookup www.nic.ad.jp 2400:3200::1결과에 따라 다음 단계 결정
| 조회 결과 | 규칙 카운터 | 결론 |
|---|---|---|
| 198.18.x 반환 | IPv6 OUTPUT 카운터 증가 | 확인된 라우터 자체 IPv6 DNS 하이재킹에 해당 |
| 실제 A 또는 AAAA 반환 | 카운터가 증가하지 않음 | 이 경로는 정상이므로 구독의 노드 이름 해석 DNS를 확인 |
| 조회 시간 초과 | 카운터가 증가하지 않음 | IPv6 경로와 선택한 DNS에 접근할 수 있는지 먼저 확인 |
| LAN 기기는 비정상이지만 라우터 조회는 정상 | 관련 변화 없음 | RA, DHCPv6, RDNSS 또는 브라우저 보안 DNS 확인 |
SmartDNS 조회만 비정상이고 Mihomo 업스트림은 정상
프로세스 신원과 경로를 확인하세요. Mihomo는 대개 제외된 GID로 실행되지만 다른 로컬 리졸버는 OUTPUT 규칙에 일치할 수 있습니다.
모든 DNS에서 connection refused 반환
로컬 수신 포트와 업스트림 구성을 확인하고 이 글의 IPv6 규칙 수정을 적용하지 마세요.
지정한 IPv4 DNS는 정상이고 지정한 IPv6 DNS는 198.18.x를 반환
이 비교 결과와 카운터 변화를 보존하고 버전 업그레이드로 진행합니다.
- SmartDNS 등의 로컬 리졸버공용 IPv6 주소의 53번 포트로 조회 전송
- OpenClash OUTPUT 규칙이전 버전은 ::/0으로 모든 IPv6 DNS 대상 주소를 잘못 일치시킴
- 로컬 Clash DNS리디렉션된 조회가 Fake-IP 모드에서 198.18.x를 반환
- 프록시 노드 도메인잘못된 결과로 도메인을 사용하는 노드가 연결을 완료하지 못함
수정에서는 라우터 자체 IPv6 DNS 하이재킹 범위를 모든 주소에서 루프백 주소 ::1로 좁혔으며 LAN 기기의 DNS 인수 규칙은 제거하지 않았습니다.
공용 IPv6 DNS가 로컬 조회로 간주되는 이유
기존 규칙은 원래 라우터 자체에서 루프백 주소로 보내는 DNS만 인수해야 했지만 IPv6 대상 범위를 ::/0으로 작성했습니다. 이 범위에는 모든 IPv6 주소가 포함되므로 SmartDNS가 공용 IPv6 DNS의 TCP 또는 UDP 53번 포트에 접근할 때도 로컬 DNS로 리디렉션됩니다.
문제는 PR #5209가 ::/0을 새로 추가한 데 있지 않습니다. 이 커밋이 IPv4와 IPv6 규칙을 분리해 식별하면서 이전에는 일찍 건너뛰던 기존 분기가 안정적으로 실행되었고, 그 결과 결함이 v0.47.117부터 더 쉽게 드러났습니다. PR #5252는 nftables의 두 곳과 legacy ip6tables의 네 곳을 모두 ::1로 바꾸고 LAN 측 DNS 인수는 유지했습니다.
수정이 포함된 v0.47.156으로 업그레이드
OpenClash v0.47.156은 현재 공식 출시 기록으로 #5252 포함을 확인할 수 있는 안정 버전입니다. 공식 Release에서 시스템에 맞는 설치 패키지를 사용하고 실제 패키지 관리자가 opkg인지 apk인지에 따라 업그레이드하세요. 개발 브랜치 파일과 IPK, APK를 섞거나 업그레이드 중 코어와 구성을 함께 바꾸면 안 됩니다.
설치가 끝나면 OpenClash를 반드시 재시작해야 합니다. 기존 ::/0 규칙이 런타임에 남아 있을 수 있으므로 방화벽 규칙을 다시 생성해야 소스 코드의 ::1이 실제로 적용됩니다. 시작에 실패하면 저장해 둔 기존 설치 패키지와 구성을 즉시 복원하고 변경을 더 쌓지 마세요.
한 번에 롤백할 수 있는 업그레이드
시스템 패키지 형식 확인
opkg 시스템은 공식 IPK를, apk 시스템은 공식 APK를 선택하고 다운로드 출처가 v0.47.156 Release인지 확인합니다.
추가 변경 중단
기존 코어, 구독, 실행 모드와 DNS 설정을 유지하고 OpenClash 플러그인만 업그레이드합니다.
설치 후 서비스 재시작
설치를 마친 뒤 OpenClash를 재시작하고 방화벽과 DNS 규칙이 다시 생성될 때까지 기다립니다.
인터넷 연결 전 로그부터 확인
구성 테스트, 코어 시작과 DNS 수신이 성공했는지 확인하고 실패하면 기존 패키지와 백업을 복원합니다.
재시작 후 세 가지 검증 수행
업그레이드 전과 같은 라우터, 도메인, 공용 IPv6 DNS로 다시 조회합니다. 수정이 적용되면 실제 A 또는 AAAA가 반환되고 공용 조회로 IPv6 OUTPUT DNS Hijack 카운터가 더 이상 증가하지 않아야 합니다. 로컬 루프백 ::1로 보내는 조회는 계속 OpenClash가 인수할 수 있어야 합니다.
DNS 비교가 통과한 뒤 기존에 도메인을 사용하던 노드를 테스트해 이름 해석, 연결과 실제 웹 요청을 관찰합니다. 지연 시간 숫자만 보는 것으로는 부족하며 최소한 노드 연결 기록 하나와 실제 페이지 하나가 모두 복구되었는지 확인하세요.
수정 검수 목록
- OpenClash에 v0.47.156이 표시되고 설치 후 서비스가 재시작됨
- 지정한 공용 IPv6 DNS가 198.18.x 대신 실제 A 또는 AAAA를 반환함
- 공용 IPv6 DNS 조회로 라우터 자체 IPv6 하이재킹 규칙 카운터가 더 이상 증가하지 않음
- ::1 조회 시 로컬 DNS 인수가 계속 정상이고 LAN 기기의 이름 해석도 손상되지 않음
- 기존 노드가 도메인 이름 해석, 연결과 실제 접속 한 번을 완료함
당장 업그레이드할 수 없을 때 우회 및 롤백하는 방법
당장 업그레이드할 수 없다면 SmartDNS에서 공용 IPv6 DNS 업스트림을 제거하고 검증된 IPv4 업스트림을 사용할 수 있습니다. 라우터 자체 프록시 또는 로컬 DNS 하이재킹을 유발하는 항목 하나를 임시로 꺼도 됩니다. 각 방법은 라우터 자체 트래픽이나 DNS 인수 동작을 바꾸므로 하나씩 테스트해야 하며 장기 수정으로 간주하면 안 됩니다.
업그레이드 후 이상 범위가 커지면 시스템 프록시와 TUN 의존 기능을 끄고 기존 플러그인 패키지와 설정 백업을 복원한 뒤 OpenClash를 재시작하세요. 그런 다음 업그레이드 전의 IPv4/IPv6 조회 비교를 사용해 원래 상태로 돌아왔는지 확인합니다.
공용 IPv6 DNS가 실제 결과를 반환하는데도 노드가 계속 실패하면 proxy-server-nameserver, 구독 내용, TLS와 노드 서버를 확인하고 OUTPUT 규칙은 더 이상 수정하지 않습니다.
임시 방안의 영향
| 작업 | 적합한 상황 | 반드시 다시 확인할 항목 |
|---|---|---|
| SmartDNS에서 접근 가능한 IPv4 업스트림 사용 | 즉시 업그레이드할 수 없지만 노드 이름 해석을 복구해야 하는 경우 | 로컬 도메인, 캐시와 노드 도메인이 모두 정상적으로 해석되는지 확인 |
| 라우터 자체 프록시 임시 비활성화 | 라우터 자체 DNS만 영향을 받는 경우 | 라우터 업데이트, 구독과 플러그인 다운로드의 외부 연결 경로 |
| 로컬 DNS 하이재킹 임시 비활성화 | 단말이 DHCP로 배포된 DNS를 사용해도 되는 경우 | LAN 기기가 예정된 트래픽 분기와 DNS 정책을 우회하는지 확인 |
| 기존 패키지와 구성 복원 | 업그레이드 후 서비스가 시작되지 않거나 LAN 연결이 끊긴 경우 | 버전, DNS 수신, 방화벽 규칙과 실제 접속 확인 |