Czy Home Assistant powinien korzystać z sieci hosta czy z sieci mostkowanej?

Home Assistant powinien korzystać z sieci hosta, gdy wykrywanie urządzeń w sieci LAN jest bezwzględnie wymagane; sieć mostkowana jest lepsza, gdy ważniejsze są jawnie określone porty i izolacja.

Żaden z tych trybów nie jest uniwersalnie szybszy ani bezpieczniejszy. Wybór zmienia przestrzeń nazw sieci, którą widzi Home Assistant, sposób docierania do niego wykrywania multicastowego i rozgłoszeniowego, publikowane porty oraz sposób łączenia się innych kontenerów. Podejmij decyzję na podstawie integracji, które muszą działać po ponownym uruchomieniu, a następnie przed uznaniem konfiguracji za stabilną przetestuj wykrywanie, bezpośrednie sterowanie, bramy MQTT lub radiowe oraz zdalny dostęp przychodzący w wybranym trybie.

Najpierw sprawdź, czy Home Assistant musi odbierać ruch wykrywania z sieci LAN

Wiele integracji Home Assistant może korzystać ze znanego adresu IP lub połączenia z brokerem, ale inne zależą od mDNS, SSDP, UPnP albo wykrywania rozgłoszeniowego. To właśnie te protokoły są głównym powodem, dla którego sieć hosta jest często używana w instalacjach kontenerowych: Home Assistant uczestniczy bezpośrednio w przestrzeni nazw sieci LAN hosta, zamiast wymagać przekazywania ruchu multicastowego przez most Dockera.

Poradnik dotyczący sieci Dockera wyjaśnia, że sieć hosta usuwa granicę mostu, co ułatwia działanie usług opartych na rozgłoszeniach, ale jednocześnie eliminuje publikowanie portów Dockera i separację przestrzeni nazw sieci. Dla większości instalacji Home Assistant ten kompromis ma większe znaczenie niż surowa przepustowość.

Wypisz integracje, które rzeczywiście wymagają wykrywania. Jeśli każde kluczowe urządzenie korzysta z jawnych adresów, MQTT, Zigbee przez koordynator podłączony przez mapowanie albo innego precyzyjnie określonego punktu końcowego, tryb mostu może działać bezproblemowo. Jeśli kilka integracji zależy od wykrywania lokalnego i nie chcesz utrzymywać przekaźników multicastowych, tryb hosta jest zwykle prostszym rozwiązaniem operacyjnym.

Sieć hosta sprawdza się, gdy prostota wykrywania jest ważniejsza od izolacji przestrzeni nazw

W trybie hosta Home Assistant wiąże się bezpośrednio ze stosem sieciowym hosta. Nie ma warstwy mapowania portów Dockera, a kontener widzi interfejsy hosta w sposób, który zwykle lepiej współpracuje z lokalnym wykrywaniem. Ceną jest słabsza izolacja sieciowa i konieczność zarządzania konfliktami portów na poziomie hosta.

Instrukcja projektowania Home Assistant w Dockerze prowadzi do tego samego warunkowego wniosku: tryb hosta upraszcza wykrywanie mDNS i UPnP, podczas gdy tryb mostu wyraźniej definiuje granice sieci i publikowane porty.

Wybierz tryb hosta, gdy problemy z wykrywaniem powtarzają się, a serwer jest zaufanym domowym hostem z kontrolowanym zestawem usług. Nie używaj trybu hosta wyłącznie po to, by ukryć nieznany problem z łącznością. Jeśli urządzenie nadal nie działa z siecią hosta, przyczyną mogą być reguły VLAN, izolacja klientów Wi-Fi, lokalny DNS, uprawnienia urządzenia albo problem na poziomie integracji, a nie most Dockera.

Sieć mostkowana sprawdza się, gdy integracje mają jawnie określoną osiągalność

Tryb mostu nadaje kontenerowi prywatny adres Dockera i pozwala publikować tylko te porty Home Assistant, które powinny być dostępne. Inne kontenery mogą komunikować się za pośrednictwem nazwanych sieci Dockera, a urządzenia w sieci LAN łączą się z opublikowanym portem hosta. Jest to czystsza granica, gdy wykrywanie nie jest niezbędne lub gdy celowo przekazujesz ruch multicastowy przez serwer proxy.

Użytkownicy Home Assistant porównujący konfiguracje bridge i macvlan zgłaszają, że zwykły most może komplikować mDNS, podczas gdy alternatywne projekty sieci przywracają bezpośrednią widoczność w sieci LAN. Z dyskusji na temat zachowania wykrywania w sieci mostkowanej wynika praktyczna lekcja: testuj potrzebny protokół, zamiast zakładać, że opublikowane porty TCP przenoszą również wykrywanie multicastowe.

Wybierz tryb mostu, gdy wymagane urządzenia są dostępne przez jawny adres IP, nazwę hosta, brokera albo zmapowaną ścieżkę sprzętową, a Ty chcesz uzyskać ściślejsze granice między usługami. Jeśli jedna integracja nie działa wyłącznie dlatego, że nie może wykryć urządzenia w sieci LAN, najpierw spróbuj skonfigurować punkt końcowy jawnie. Przejdź na tryb hosta lub bardziej zaawansowaną sieć dopiero wtedy, gdy integracja rzeczywiście wymaga takiego sposobu wykrywania.

-15% OFF

ZimaBoard 2 – Mini serwer domowy dla Twojego wielkiego pomysłu

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Zweryfikuj wybór za pomocą tej samej macierzy integracji po ponownym uruchomieniu

Przygotuj pięć testów: dostęp do lokalnego panelu, jedno urządzenie mDNS lub SSDP, jedną integrację korzystającą z jawnego adresu IP, jednego brokera lub bramy radiowej oraz zwykłą ścieżkę przez odwrotne proxy lub VPN. Testuj po ponownym utworzeniu kontenera i ponownym uruchomieniu hosta, a nie tylko bezpośrednio po zmianie konfiguracji Compose, ponieważ zapisane dane wykrywania mogą ukryć problemy trybu sieci, które ujawnią się później.

Analiza problemów z osiągalnością podsieci Dockera w ZimaSpace pokazuje tę samą granicę: dostępność aplikacji i osiągalność sieci kontenera to różne testy, nawet gdy obie usługi działają na tym samym serwerze fizycznym.

Pozostań przy trybie hosta, jeśli niezawodnie zachowuje wymagane wykrywanie, a Ty akceptujesz współdzieloną przestrzeń nazw. Pozostań przy trybie mostu, jeśli każda wymagana integracja pozostaje osiągalna, a wyraźna granica zmniejsza niejasności operacyjne. Jeśli żaden tryb nie przejdzie testów, przestań przełączać tryby i sprawdź routing VLAN, przekazywanie multicastu, reguły zapory lub sam transport integracji; tryb sieci to tylko jedna z warstw całej ścieżki.