Port 2015/2016

[kajetan.kubik]

Witam. Mam pewien problem z wystawieniem portu 2015/2016 na zewnątrz z prywatnej chmury. Mniejsza w zasadzie o problem, zastanawiałem się nad czym innym. Po co właściwie te porty muszą być wystawione na zewnątrz?

Moje dość prymitywne rozumowanie:
- WWW supla-cloud ma mnóstwo funkcjonalności, i działa na samym porcie 443
- aplikacja na Androida ma mało funkcjonalności (nie ma działu automatyka itd., tak naprawdę skromny podzbiór tego co mamy na WWW), i wymaga portu 443 i 2015/16
- EDIT: integracja z Google home też zadowala się tylko portem 443

Gdzie tu jest jakaś logika?

Z tego co kojarzę port 2015/16 jest dla protokołu Supla, urządzenia się po nim łączą. W sieci wewnętrznej to oczywiste że port musi być dostępny. Ale po co ma być wystawiony na świat?

Jest to też jakaś potencjalna dziura w której można szukać i znaleźć być może jakieś exploity. Wolałbym tego portu nie otwierać.

Czy jest jakaś możliwość aby apka mobilna działała bez tego portu z prywatną chmurą?

[pzygmunt]

Do komunikacji pomiędzy urządzeniami, a serwerem wykorzystujemy dedykowany protokół i to jest podstawa komunikacji w Supli. Web to drugi kanał komunikacji, a zarazem druga warstwa. Są tam zupełnie inne opóźnienia niż w przypadku natywnej komunikacji. Jeśli chcesz korzystać z apki poza swoją siecią musisz udostępnić przynajmniej port 2016 lub zestawić VPN-a.

[kajetan.kubik]

Do komunikacji pomiędzy urządzeniami, a serwerem wykorzystujemy dedykowany protokół i to jest podstawa komunikacji w Supli. Web to drugi kanał komunikacji, a zarazem druga warstwa. Są tam zupełnie inne opóźnienia niż w przypadku natywnej komunikacji. Jeśli chcesz korzystać z apki poza swoją siecią musisz udostępnić przynajmniej port 2016 lub zestawić VPN-a.

Hm co do komunikacji urządzeń typu ROW-02 z serwerem to nie widzę problemu, żeby był otwarty jakiś customowy port z waszym protokołem. Natomiast co do komunikacji z telefonem to z kilku powodów jest problematyczne:
1. Customowego portu/protokołu często nie lubią firewalle, proxy, itd.
2. Wystawianie tego na świat wiąże się jednak z większym ryzykiem niż wystawienie tylko nginxa.
3. Port 2016 jest zahardkodowany, co uniemożliwia wystawienie większej liczby supli-cloud na świat z prywatnej chmury. Można wystawić tylko po HTTP, ale apki w telefonie już nie ma jak skierować pod różne porty.

Żeby nie było, to nie jest jakiś mój wymyślony problem, tylko mój konkretny przypadek. Mam dwie lokacje gdzie mam supla-cloud. W tej drugiej niestety mam tylko LTE, więc nie mogę jej udostępnić na zewnątrz. Obie są natomiast połączone vpnem. W tej pierwszej mam dwa łącza internetowe, i tylko dlatego w ogóle mam możliwość wystawienia obydwu supli-cloud na świat, pod dwoma różnymi domenami. Gdyby był to tylko port https, i można go podać w apce na telefon, no to można by wystawić dowolną liczbę supli cloud pod jednym łączem. A tak muszę 2016 wystawiać dwoma łączami. Jakbym miał 3 lokacje, no to byłoby już w ogóle niewykonalne.

Co do opóźnień, to z tego co widzę, stronka robi polling rest callem co jakiś czas, no to niedziwne, że są opóźnienia. Ale przecież można to zrobić na jakimś websockecie, i zmienić to na model push. Pewnie nawet tym websocketem można by puścić z grubsza to samo co na 2016.

Od biedy rozwiązaniem na bolączkę z punktu 3 powyżej byłoby też umożliwienie zmiany tego portu 2016 na inny w apce mobilnej przy dodawaniu kolejnego konta. Może to byłoby w miarę proste do zrobienia?

[pzygmunt]

1. Customowego portu/protokołu często nie lubią firewalle, proxy, itd.

Nie ma z tym problemów, a jak są to bardzo rzadko do tego stopnia, że jest to dla nas niezauważalne. Częściej w firmach się to zdarza ale tam zwykle jest ktoś, kto ogarnia temat. Z 443 nie jest tak kolorowo jak myślisz bo są firmy i organizacje, która stosują inspekcję ruchu szyfrowanego HTTPS (WAF/IPS/IDS/NGFW/ProxySG) co czasami potrafi przyczepić się do wszystkiego co nie jest html-em po http. Działa to na tej samej zasadzie jak atak man-in-the-middle tylko certyfikaty są globalnie akceptowane przez organizację. Zwykle dystrybuowane przez Active Directory.

2. Wystawianie tego na świat wiąże się jednak z większym ryzykiem niż wystawienie tylko nginxa.

Myślisz, że grupie przestępczej, która konsumuje miliony USD lepiej inwestować czas w szukanie exploitów na Suplę, czy nginx-a, którego liczba instancji dostępnych z sieci w 2020r przekroczyła 490 milionów ?
Do kwestii bezpieczeństwa podchodzimy bardzo rygorystycznie. Pilnujemy dobrych praktyk, na bieżąco weryfikujemy kod przy użyciu dedykowanych ku temu narzędzi oraz nieprzerwanie fazujemy serwer z użyciem między innymi AFL-a.
W dodatku regularnie przechodzimy audyty bezpieczeństwa przeprowadzane przez firmy trzecie.

3. Port 2016 jest zahardkodowany, co uniemożliwia wystawienie większej liczby supli-cloud na świat z prywatnej chmury. Można wystawić tylko po HTTP, ale apki w telefonie już nie ma jak skierować pod różne porty.

Staramy się nie wprowadzać funkcjonalności na które nie ma zapotrzebowania. W tym przypadku trudno mi sobie przypomnieć kogoś kto by w ostatnich latach zgłaszał podobny problem. Tego typu funkcjonalność wymagałaby również rozbudowania aplikacji tak aby umożliwiała ustawienie niestandardowych portów. Staramy się aby ustawień było raczej mniej niż więcej.

Żeby nie było, to nie jest jakiś mój wymyślony problem, tylko mój konkretny przypadek. Mam dwie lokacje gdzie mam supla-cloud. W tej drugiej niestety mam tylko LTE, więc nie mogę jej udostępnić na zewnątrz. Obie są natomiast połączone vpnem.

1. Jak masz VPN-a to możesz postawić jeden serwer dla dwóch lokalizacji.
2. Możesz użyć dwóch adresów IP nawet na jednym łączu i tam publikować wymagane porty.
3. Nie musisz w ogóle publikować tych usług na świat. Użyj VPN-a.
4. Możesz też oczywiści zrobić tak jak napisałeś wyżej.

[kajetan.kubik]

1. Customowego portu/protokołu często nie lubią firewalle, proxy, itd.

Nie ma z tym problemów, a jak są to bardzo rzadko do tego stopnia, że jest to dla nas niezauważalne. Częściej w firmach się to zdarza ale tam zwykle jest ktoś, kto ogarnia temat. Z 443 nie jest tak kolorowo jak myślisz bo są firmy i organizacje, która stosują inspekcję ruchu szyfrowanego HTTPS (WAF/IPS/IDS/NGFW/ProxySG) co czasami potrafi przyczepić się do wszystkiego co nie jest html-em po http. Działa to na tej samej zasadzie jak atak man-in-the-middle tylko certyfikaty są globalnie akceptowane przez organizację. Zwykle dystrybuowane przez Active Directory.

2. Wystawianie tego na świat wiąże się jednak z większym ryzykiem niż wystawienie tylko nginxa.

Myślisz, że grupie przestępczej, która konsumuje miliony USD lepiej inwestować czas w szukanie exploitów na Suplę, czy nginx-a, którego liczba instancji dostępnych z sieci w 2020r przekroczyła 490 milionów ?
Do kwestii bezpieczeństwa podchodzimy bardzo rygorystycznie. Pilnujemy dobrych praktyk, na bieżąco weryfikujemy kod przy użyciu dedykowanych ku temu narzędzi oraz nieprzerwanie fazujemy serwer z użyciem między innymi AFL-a.
W dodatku regularnie przechodzimy audyty bezpieczeństwa przeprowadzane przez firmy trzecie.

3. Port 2016 jest zahardkodowany, co uniemożliwia wystawienie większej liczby supli-cloud na świat z prywatnej chmury. Można wystawić tylko po HTTP, ale apki w telefonie już nie ma jak skierować pod różne porty.

Staramy się nie wprowadzać funkcjonalności na które nie ma zapotrzebowania. W tym przypadku trudno mi sobie przypomnieć kogoś kto by w ostatnich latach zgłaszał podobny problem. Tego typu funkcjonalność wymagałaby również rozbudowania aplikacji tak aby umożliwiała ustawienie niestandardowych portów. Staramy się aby ustawień było raczej mniej niż więcej.

Żeby nie było, to nie jest jakiś mój wymyślony problem, tylko mój konkretny przypadek. Mam dwie lokacje gdzie mam supla-cloud. W tej drugiej niestety mam tylko LTE, więc nie mogę jej udostępnić na zewnątrz. Obie są natomiast połączone vpnem.

1. Jak masz VPN-a to możesz postawić jeden serwer dla dwóch lokalizacji.
2. Możesz użyć dwóch adresów IP nawet na jednym łączu i tam publikować wymagane porty.
3. Nie musisz w ogóle publikować tych usług na świat. Użyj VPN-a.
4. Możesz też oczywiści zrobić tak jak napisałeś wyżej.

Ok. Dzięki za odpowiedź w kwestii bezpieczeństwa i audytów, to ważna i dość uspokajająca informacja. Co do exploitów na Suplę, to kto wie ile będziecie mieli instalacji za jakiś czas może ktoś się skusi.

Tak, na VPNie też to stawiałem jakiś czas temu, ale to jest w jakimś tam stopniu niewygodne. Trudno, pokombinuję z tymi dwoma łączami.

Mam też wszystko wystawione po home assistant, i tam dzięki temu, że jest remote home assistant, mam wszystko wystawione pod jednym łączem/domeną na jednym porcie, i mogę tym sterować obydwiema suplami. Także porównując wygodę HA i supli pod tym względem wychodzi na korzyść HA. Ale ok, przyjmuję do wiadomości powyższe odpowiedzi, jest jak jest. Choć odpowiedź, że staracie się aby było raczej mniej ustawień niż więcej, a równocześnie udostępniacie ludziom dockera do samodzielnego ustawiania z masą rzeczy typu proxy certyfikaty, mqtt... no raczej jednak macie mega dużo opcji, a możliwość wyboru portu wydaje się przy wspomnianych dość trywialna.

W ogóle to HA ma dwie istotne przewagi: apkę na zegarek (wearable), i carplay. W zasadzie to jedyne powody, dla jakich użyłem HA. Czy macie w planach carplay i apkę na zegarki? Tu jakoś ciężko mi będzie uwierzyć, że nikt tego nie potrzebuje W domu człowiek prędzej będzie mieć na sobie zegarek, niż telefon, i jest to po prostu wygodne. Carplay natomiast przydaje się do rzeczy typu otwieranie bramy, światło w garażu itd. Fajnie, że da się to ogarnąć z użyciem HA, natomiast nie ukrywam, że raczej wymagało to sporo pracy i umiejętności. Fajniej byłoby, aby natywnie apka supli po prostu działała na carplay / zegarku. Przeszukując wasze forum nie znalazłem jakoś info o planach aplikacji zegarkowej, co jest dość zaskakujące.

[klew]

Supla nie pretenduje do bycia konkurencją dla HA. Do ich jednego repozytorium (ze 105) tylko w ciągu ostatniego miesiąca, kontrybuowało 199 osób.
W Supli mamy przeciętnie około 1-2 osób miesięcznie do każdego z naszych 4 głównych repozytoriów

[pzygmunt]

Odkąd dołączył do naszego zespołu Michał to nadrabiamy zaległości z mobilną apką. Oczywiście chcielibyśmy trafić do CarPlay i na zegarki. Jest to w planach. Kwestia tylko (i aż) czasu.

[kajetan.kubik]

Supla nie pretenduje do bycia konkurencją dla HA. Do ich jednego repozytorium (ze 105) tylko w ciągu ostatniego miesiąca, kontrybuowało 199 osób.
W Supli mamy przeciętnie około 1-2 osób miesięcznie do każdego z naszych 4 głównych repozytoriów

Zdaję sobie sprawę, że HA to projekt o innej skali, ale też o nieco innym zastosowaniu, i na całym polu nie ma co z nim konkurować. Niemniej jak zawęzimy rozważania do kwestii tylko sterowania urządzeniami z zegarka/carplay, no to jest już jednak corowy feature takiego systemu, jak Supla, i trudno tu uciekać od porównania do HA. Ale nie tylko do HA, także google home, apple homeapp, itd., wszystko to ma wersję na wearables i samochody.

Odkąd dołączył do naszego zespołu Michał to nadrabiamy zaległości z mobilną apką. Oczywiście chcielibyśmy trafić do CarPlay i na zegarki. Jest to w planach. Kwestia tylko (i aż) czasu.

Świetna wiadomość, trzymam kciuki!

Podsumowując też wątek, wystawiłem ten port 2016 na dwóch łączach, i działa OK bez VPNa. Co do mojego oporu korzystania z VPNa, no to nie każdy jest osobą techniczną, i raczej instalowanie każdej osobie z gospodarstwa domowego VPNa na telefonie odpada, konieczność generacji kluczy itd., strasznie upierdliwe.

Jakby ktokolwiek potrzebował, to opiszę też mój setup, może komuś się przyda na przyszłość:

Lokalizacja 1:
Supla-cloud 1 <-> MQTT 1 <-> Home assistant 1
Łącze bez publicznego IP

Lokalizacja 2:
Supla-cloud 2 <-> MQTT 2 <-> Home assistant 2
Dwa łącza z publicznymi IP

Routery TP Link ER 605 w obydwu lokalizacjach
Pomiędzy Lokalizacją 1 i Lokalizacją 2 jest VPN zestawiony na poziomie routerów, także sieci w obydwu lokalizacjach widzą się jakby były w jednym LAN
Home assistant 1 widzi Home assistant 2 za pomocą pluginu Remote home assistant, także Home assistant 2 zawiera encje z obydwu lokalizacji HA

W lokalizacji 2 na świat wystawione są:
Supla-cloud 1 (łącze 1)
Supla-cloud 2 (łącze 2)
Home assistant 2 (łącze 1)
(mógłby być wystawiony też home assistant 1 na osobnym porcie, ale nic dodatkowego by to nie dało)

Rezultat:
- W apce mobilnej Supla można dodać Supla-cloud 1 i Supla-cloud 2 i sterować wszystkimi urządzeniami z obydwu lokalizacji będąc poza domem
- W apce mobilnej Home assistant podpinamy Home assistant 2, i możemy sterować wszystkimi urządzeniami z obydwu lokalizacji będąc poza domem z apki na telefonie, zegarku, oraz carplay
- Ewentualnie automatyzacje w obydwu lokalizacjach będą działać także jak padnie internet, dlatego każda lokalizacja ma niezależną Supla-cloud

[klew]

Umówmy się, że osoby nie-techniczne nie instalują własnych serwerów, tylko raczej trzymają się publicznych

[Robert Błaszczak]

Umówmy się, że osoby nie-techniczne nie instalują własnych serwerów, tylko raczej trzymają się publicznych

Osoby techniczne (np. ja) również trzymają się publicznych serwerów. Bo im tak wygodniej