eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.misc.elektronikaNTG ale może... › Re: NTG ale może...
  • Path: news-archive.icm.edu.pl!agh.edu.pl!news.agh.edu.pl!newsfeed2.atman.pl!newsfeed.
    atman.pl!.POSTED!not-for-mail
    From: sundayman <s...@p...onet.pl>
    Newsgroups: pl.misc.elektronika
    Subject: Re: NTG ale może...
    Date: Mon, 12 Jun 2017 19:45:54 +0200
    Organization: ATMAN - ATM S.A.
    Lines: 93
    Message-ID: <ohmk0o$boe$1@node2.news.atman.pl>
    References: <ohcvjh$cja$1@node2.news.atman.pl>
    <1...@g...com>
    <ohemui$nkh$1@node1.news.atman.pl> <ohlqgd$t48$6$gof@news.chmurka.net>
    <ohmdns$akg$1@node1.news.atman.pl> <ohmis7$7fh$1$gof@news.chmurka.net>
    NNTP-Posting-Host: 91.205.72.35
    Mime-Version: 1.0
    Content-Type: text/plain; charset=iso-8859-2; format=flowed
    Content-Transfer-Encoding: 8bit
    X-Trace: node2.news.atman.pl 1497289560 12046 91.205.72.35 (12 Jun 2017 17:46:00 GMT)
    X-Complaints-To: u...@a...pl
    NNTP-Posting-Date: Mon, 12 Jun 2017 17:46:00 +0000 (UTC)
    User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101
    Thunderbird/52.1.1
    In-Reply-To: <ohmis7$7fh$1$gof@news.chmurka.net>
    Content-Language: pl
    Xref: news-archive.icm.edu.pl pl.misc.elektronika:719130
    [ ukryj nagłówki ]


    > Czyli chcesz z tego zupełnie zrezygnować, wywalić soft producenta i zrobić
    > łączność sieciową samemu?

    nie no, skąd. Nic nie chcę wywalać.
    Modem ma pełne wsparcie dla komunikacji TCP.
    Sam zestawi połączenie, będzie go pilnować itp.
    Komendami AT można dane wysłać i pobrać. Wszystko od tej strony jest
    przygotowane przez skośnego.

    Jedyne co chcę zrobić - to przestać korzystać z chmury producenta i
    samemu - albo przesyłać tylko dane (czyli tak jak w tej chińskiej
    chmurze) - albo lepiej, od razu te dane trzymać tam i pokazywać. Czyli
    thingsboard.


    > 1. Keepalive'y - żeby nie było sytuacji, w której połączenie będzie
    > aktywne tylko teoretycznie, ale w praktyce będzie martwe (bo np. wyleci z
    > tablicy połączeń gdzieś po drodze, a klient nie złapie RST)
    > 2. Ponawianie połączeń - bo połączenie może umrzeć w każdym momencie i
    > klient musi sam połączyć się znowu
    > 3. Szyfrowanie połączenia - żeby nikt nie podsłuchał ruchu
    > 4. Uwierzytelnienie klienta - żeby nikt łącząc się na port serwera nie
    > mógł się podszyć za danego klienta
    > 5. Możliwość zablokowania konkretnego klienta - w przypadku kradzieży
    > modemu

    Ok.


    > Co będzie rozmawiało z modemem od strony klienta? Jeśli jakiś pecet lub
    > coś, na czym uruchomisz Linuksa, to doradzałbym Ci postawienie tam VPN-a i
    > stworzenie prywatnej, zamkniętej sieci, w ramach której będziesz miał
    > dostęp do wszystkich urządzeń.

    Panie, pan to ma wymaganiaaa... :)
    Nie, tak to się nie da. Dlaczego ?
    Ano - ponieważ komputer użyszkodnika, to np. komputer pana technika w
    jakiejś firmie komunikacji miejskiej. Tam jest problem zainstalować w
    ogóle cokolwiek - trzeba składać podania w 6 egz. z życiorysem całek
    rodziny. I mieć paszport ABW do pozwolenia użycia konkretnego portu.
    W dodatku nie wiadomo nigdy co to za PC - przeważnie jeszcze z XP.
    Czasem windows 7, rzadko 10.
    Linuksa to tam nikt na oczy nie widział.

    Ale to wszystko nie jest kłopot wielki - bo serwer (na razie chiński)
    pozwala stworzyć "grupę" urządzeń, podpiętych do tego wirtualnego COM.
    Poza tą grupę user nie wyjdzie. Poza tym, żeby się z urządzeniem
    połączyć trzeba znać jego numer seryjny.
    Nawet gdyby ktoś zaś się do tego wszystkiego włamał
    i chciał rozpracowywać ramkę danych itp. to musiałby poświęcić na to
    duużo czasu. Ale po co nie wiem :)

    Dodatkowo są zabezpieczenia w postaci ograniczenia ilość połączeń/czas,
    czy nadawane przez urządzenie podczas połączenia "pieczątki" określajace
    max. czas sesji itp.

    Nawet jednak, gdyby jakiś desperat włamał się do tego skutecznie, to i
    tak nie narobi szkód wielkich - bo ustawienia, które można zdalnie
    zmienić to tylko wybrane tak, aby nie spowodować zagrożeń.

    A z racji tego, że modem jest poza urządzeniem i łączy się tylko via
    RS232 za pomocą określonych komend, to nie ma żadnej możliwości
    "hackowania" tak, aby urządzenie zrobiło cokolwiek poza tym, co wolno mu
    zrobić.

    > umożliwia łatwe zrobienie mutual authentication (czyli że nie tylko klient
    > weryfikuje certyfikat serwera, ale serwer weryfikuje certyfikat klienta -
    > czyli oba muszą mieć swój tajny klucz). Warunkiem jest to, żeby komputer
    > kliencki (czyli ten połączony z modemem kablem) miał zegar RTC lub
    > możliwość pobrania czasu w inny sposób (choćby z Twojego VPS-a), bo bez
    > tego sesja TLS się nie uda z powodu ważności certyfikatów.
    >
    > Problem może być jedynie z tym, że OpenVPN spodziewa się interfejsu
    > socketowego - nie będzie gadał z modemem jego funkcjami. To można
    > rozwiązać na kilka sposobów, najprościej napisać jakieś małe proxy, które
    > będzie odbierało połączenia na localhoście i łączyło się z serwerem już
    > poleceniami modemu.
    >
    > Czyli:
    >
    > 1. OpenVPN łączy się z localhostem (po socketach)
    > 2. Proxy odbiera to połączenie
    > 3. Proxy wysyła prośbę o połączenie do modemu
    > 4. Proxy tuneluje ruch
    > 5. Jeśli OpenVPN się rozłączy, proxy zamyka połączenie na modemie
    > 6. Jeśli serwer zdalny się rozłączy (modem musi jakoś o tym powiadomić),
    > proxy zamyka połączenie z lokalnym OpenVPN-em

    To wszystko zastosuję, kiedy dojdzie do skutku ten kontrakt, na który
    liczę, z US Army, na obsługę silosów z rakietami :)
    Ale dzięki - wiedza na pewno się mi przyda.

Podziel się

Poleć ten post znajomemu poleć

Wydrukuj ten post drukuj


Następne wpisy z tego wątku

Najnowsze wątki z tej grupy


Najnowsze wątki

Szukaj w grupach

Eksperci egospodarka.pl

1 1 1

Wpisz nazwę miasta, dla którego chcesz znaleźć jednostkę ZUS.

Wzory dokumentów

Bezpłatne wzory dokumentów i formularzy.
Wyszukaj i pobierz za darmo: