Home Assistant가 Wi-Fi에서는 작동하지만 이더넷이나 VPN에서는 작동하지 않음

에바 왕기술 작가 그리고 이자 ZimaSpace의 상주 장인입니다. 평생을 기술에 열정을 가진 사람으로서 홈랩과 오픈소스 소프트웨어에 열정을 가지고 있으며,복잡한 기술 개념을 쉽게 이해할 수 있는 실습 가이드로 번역하는 데 전문성을 가지고 있습니다.에바는 셀프 호스팅이 어렵지 않고 재미있어야 한다고 믿습니다. 그녀의 튜토리얼을 통해 커뮤니티가 하드웨어 설정의 신비를 풀도록돕고 있습니다. 첫 NAS 구축부터 Docker 컨테이너 마스터링까지.

Home Assistant가 Wi-Fi에서는 작동하지만 Ethernet이나 VPN에서는 실패한다면 애플리케이션은 정상일 가능성이 높습니다. 문제는 대개 링크 상태, 주소 설정, 라우팅, 정책, DNS, 반환 트래픽 또는 멀티캐스트 검색에 있습니다.

Ethernet과 VPN을 각각 테스트하는 동안 정상적으로 작동하는 Wi-Fi 경로를 계속 사용할 수 있도록 유지하세요. 먼저 대상 인터페이스의 직접 IP를 사용한 다음 게이트웨이와 반환 경로를 확인하고, 서비스 포트, 호스트 이름, 검색 기능을 차례로 테스트하세요. 여러 네트워크 계층을 동시에 변경하면 접속이 차단될 수 있고, 성공 원인을 파악하기도 어려워집니다.

Ethernet 인터페이스에 사용 가능한 주소가 있는지 확인

Home Assistant 호스트 또는 하이퍼바이저에서 물리적 링크, 협상된 속도, 인터페이스 상태, 할당된 주소, 서브넷, 게이트웨이, DHCP 임대를 확인하세요. 같은 Ethernet 네트워크에 연결된 정상 클라이언트와 비교하세요. 링크 표시등이 켜져 있다고 해서 올바른 레이어 3 구성이 보장되는 것은 아닙니다.

한 커뮤니티 사례에서는 예상한 eth0 장치가 없어 nmcli로 모든 인터페이스를 확인할 것을 권장합니다. 첫 번째로 유용한 테스트는 모든 플랫폼의 유선 포트 이름이 eth0일 것이라고 가정하는 것이 아니라 실제 인터페이스 이름과 주소를 확인하는 것입니다.

같은 서브넷의 클라이언트에서 Ethernet IP를 ping하거나 다른 방법으로 테스트하고 포트 8123이 열려 있는지 직접 확인하세요. IP에 연결할 수 없다면 링크, VLAN, DHCP, 서브넷 확인 단계에 머무르세요. IP는 작동하지만 호스트 이름이 실패한다면 Ethernet 서비스는 정상이며 다음으로 DNS를 확인해야 합니다.

라우팅 선택, 방화벽 정책, 반환 트래픽 확인

Wi-Fi와 Ethernet이 모두 활성화된 상태에서 라우팅 테이블을 확인하세요. 기본 경로, 인터페이스 메트릭, 테스트 클라이언트 또는 VPN 서브넷으로 돌아가는 경로를 확인합니다. 요청이 정상적으로 도착했더라도 응답이 잘못된 인터페이스를 통해 나가면 인바운드 연결이 차단된 것처럼 보일 수 있습니다.

라우터 정책을 통과하기 전에 같은 VLAN에서 일시적으로 테스트하세요. 동일 서브넷에서는 접속되지만 라우팅된 접속이 실패한다면 VLAN 간 방화벽 규칙, 컨테이너 네트워크 모드, 하이퍼바이저 브리지, VPN 허용 네트워크, Home Assistant 측의 역방향 경로를 확인하세요.

ZimaSpace의 호스트 네트워킹과 브리지 네트워킹 비교 자료는 컨테이너 포트 또는 검색 경계 문제와 물리적 Ethernet 장애를 구분하는 데 도움이 됩니다. 유선 경로가 독립적으로 통과할 때까지 정상적으로 작동하는 Wi-Fi 경로를 유지하세요.

직접 연결 가능 여부와 DNS 및 검색 기능을 구분

Ethernet 또는 VPN IP, 서비스 포트, 설정된 호스트 이름, 자동 검색 순서로 테스트하세요. 직접 IP로는 접속되지만 호스트 이름으로는 실패한다면 DNS 또는 오래된 캐시 주소가 원인일 수 있습니다. 직접 UI에는 접속되지만 장치가 표시되지 않는다면 검색 기능 또는 장치 서브넷 정책 문제일 가능성이 높습니다.

서브넷을 가로지르는 Home Assistant 관련 논의에 따르면 일반 유니캐스트 트래픽이 허용되더라도 mDNS 확인은 실패할 수 있습니다. 멀티캐스트 검색에는 명시적인 전달 또는 리플렉터가 필요하기 때문입니다. 이 멀티캐스트와 유니캐스트의 차이는 VLAN과 라우팅된 VPN에서 특히 중요합니다.

검색 기능이 작동하도록 모든 방화벽 규칙을 무작정 허용 범위로 넓히지 마세요. 지원되는 경우 명시적인 통합 주소를 사용하거나 신뢰할 수 있는 세그먼트 사이에 범위를 좁힌 멀티캐스트 릴레이를 구성하세요. 직접 IP로 UI에 접속할 수 없다면 아직 검색 기능을 해결할 단계가 아닙니다.

네트워크 문제를 한 번에 하나씩 수정하고 모든 경로를 다시 테스트

확인된 계층만 수정하세요. 케이블 또는 스위치 포트, DHCP 예약, 서브넷 또는 게이트웨이, 인터페이스 메트릭, 방화벽 규칙, 반환 경로, DNS 레코드, VPN 허용 네트워크, 멀티캐스트 릴레이 중 해당 항목만 변경합니다. 이전 구성을 저장하고 네트워크 서비스를 다시 시작하기 전에 로컬 접속 방법을 마련하세요.

같은 순서로 Ethernet IP, 호스트 이름, 로컬 장치, VPN 클라이언트, 원격 UI, WebSocket 안정성, 검색 기능을 다시 테스트하세요. 호스트를 한 번 재시작하고 클라이언트의 네트워크 상태를 갱신하여 오래된 경로와 DNS가 일시적으로 성공한 것처럼 보이게 하지 않도록 하세요.

성공적인 결과는 안정적인 Ethernet 접속을 유지하고, 의도한 VPN 경로를 보존하며, 중복된 기본 경로를 피하고, 승인된 경계 내에서만 장치를 검색합니다. 정상적으로 작동하던 Wi-Fi 경로가 사라지거나 세그먼트 간 트래픽이 누출되면 롤백하세요. 요청은 도착하지만 응답이 여전히 잘못된 경로로 나가는 경우에는 인터페이스, 라우팅, 방화벽, 패킷 흐름 정보를 함께 제공하여 문제를 에스컬레이션하세요.

지원 및 팁

더 읽어보기

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.