분할 DNS가 집 안에서만 작동하지 않는 자체 호스팅 앱을 해결할 수 있을까요?

네, split DNS는 공용 호스트명이 집에서 다른 로컬 주소로 해결되어야 할 때 내부 전용 실패를 해결할 수 있습니다.

셀프 호스팅 앱은 공용 DNS가 집의 WAN 주소를 가리키기 때문에 모바일 데이터에서는 작동할 수 있지만, LAN 내부의 장치는 라우터가 해당 연결을 공용 NAT 규칙을 통해 다시 되돌려 보내지 못해 실패합니다. Split DNS는 로컬 리버스 프록시나 앱 주소를 집 내부 클라이언트에 반환하여 이 루프를 피하지만, 동일한 호스트명, 인증서, 프록시 경로 및 애플리케이션 기본 URL이 두 경로 모두에서 유효할 때만 성공합니다.

먼저 외부에서 공용 이름이 작동하는지 확인하세요

모바일 데이터나 다른 외부 네트워크에서 정확한 애플리케이션 URL을 테스트하세요. DNS 해석, TLS, 리버스 프록시 라우팅, 로그인, 리디렉션 및 현재 집 내부에서 실패하는 애플리케이션 기능을 확인하세요.

Tailscale은 split DNS를 내부 및 외부 사용자를 동일한 경로로 강제하지 않고 문맥에 따라 클라이언트에 다른 DNS 응답을 제공하는 방법으로 설명합니다.

앱이 외부에서도 실패한다면 split DNS는 첫 번째 수리가 아닙니다. 공용 DNS, 터널 또는 포트 포워드, 프록시 라우팅, TLS 또는 애플리케이션 구성을 먼저 수정한 후 원래 문제를 숨길 수 있는 두 번째 응답을 만드세요.

내부 실패가 Hairpin NAT인지 확인하세요

집 내부 클라이언트에서 공용 호스트명을 쿼리하고 반환된 주소를 기록하세요. 만약 집 공용 IP로 해석된다면, 라우터가 해당 포워딩 서비스에 대해 NAT 루프백 또는 Hairpin NAT를 지원하는지 추적하세요.

Level1Techs 문제 해결 스레드는 Hairpin NAT가 신뢰할 수 없을 때 도메인을 내부 서버 주소로 가리키는 로컬 DNS 오버라이드를 권장합니다.

공용 이름 실패와 로컬 리버스 프록시 주소에 직접 접근하는 것을 비교하세요. 직접 로컬 접근이 의도한 프록시나 앱에 도달하는 반면, 공용 IP가 내부에서만 실패한다면 split DNS가 적합합니다.

내부 응답을 동일한 논리적 진입점으로 지정하세요

기존 공용 호스트명에 대해 내부 DNS 레코드를 생성하되, 리버스 프록시나 제어된 로컬 진입점의 LAN 주소를 가리키도록 하세요. 외부 사용자가 일반적으로 프록시를 통과하는 경우 백엔드로 직접 지정하는 것은 피하세요.

split DNS 비교는 로컬 클라이언트가 동일한 도메인을 사설 내부 주소로 해석할 수 있는 반면 외부 클라이언트는 계속 공용 주소를 받는다고 설명합니다.

두 경로 모두 동일한 프록시를 유지하면 호스트명 기반 라우팅, 접근 정책, 헤더 및 인증서가 보존됩니다. 집 내부 클라이언트를 프록시를 우회하도록 지정하면 페이지는 로드될 수 있지만 인증, 콜백, WebSocket 또는 프록시에만 존재하는 보안 제어가 깨질 수 있습니다.

Featured

ZimaCube 2 개인용 클라우드 홈 NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

필요한 모든 클라이언트가 내부 해석기를 사용하는지 확인하세요

내부 응답을 받아야 하는 휴대폰, 노트북, TV, 컨테이너 및 VPN 클라이언트가 사용하는 DNS 서버를 확인하세요. 브라우저 보안 DNS, 모바일 프라이빗 DNS, VPN 해석기 또는 하드코딩된 공용 DNS 서버는 집 내부 해석기를 우회할 수 있습니다.

셀프 호스팅 split DNS 안내는 VPN이나 클라이언트가 내부 네트워크에 있음에도 불구하고 잘못된 해석기 문맥을 계속 사용할 때 장애가 자주 발생한다고 경고합니다.

내부 DNS 서버를 직접 쿼리한 후 일반 클라이언트 조회 결과와 비교하세요. 서버가 로컬 주소를 반환하지만 클라이언트가 그렇지 않으면 DHCP DNS 배포, 암호화 DNS, VPN 정책 또는 클라이언트 오버라이드를 수정한 후 레코드를 다시 편집하세요.

TLS 및 애플리케이션 콜백에 동일한 호스트명을 유지하세요

내부 레코드가 활성화된 후 정상 도메인으로 앱에 접근하세요. HTTPS 인증서와 리버스 프록시 경로가 일반적으로 호스트명에 연결되어 있으므로 사설 IP로 북마크를 대체하지 마세요.

내부 경로는 애플리케이션의 공용 기본 URL, OAuth 리디렉션 URI, 웹훅 주소 및 전달된 헤더도 유지해야 합니다. Split DNS는 대상 주소만 변경하며 브라우저나 제공자가 사용해야 할 호스트명은 변경하지 않습니다.

앱이 공용 IP로 리디렉션하거나 내부 호스트명을 생성하거나 호스트 헤더를 거부하면 프록시 및 앱 URL 설정을 수정하세요. DNS만으로는 일관되지 않은 ID로 구성된 서비스를 복구할 수 없습니다.

두 경로가 예측 가능할 때만 Split DNS를 유지하세요

집 Wi-Fi, 게스트 Wi-Fi, VPN, 모바일 데이터 및 프라이빗 DNS를 사용하는 한 장치에서 테스트하세요. 각 클라이언트가 의도한 주소를 받고 동일한 애플리케이션 ID에 도달하는지 확인하세요.

ZimaSpace의 사설 클라우드가 한 네트워크에서만 작동하는 이유 가이드는 반대 증상을 제공하며 두 DNS 뷰가 의도적으로 다르게 유지되는지 확인하는 데 도움을 줍니다.

Split DNS는 동일한 도메인, TLS 인증서, 프록시 경로 및 애플리케이션 동작을 유지하면서 깨진 공용 루프를 제거할 때 올바른 해결책입니다. 라우터가 이를 안정적으로 처리하고 두 DNS 뷰를 유지하는 것이 위험보다 가치가 적을 때는 Hairpin NAT를 대신 사용하세요.