Witam.

@Cezary
Dopytam dla pewności. W powyższym artykule dostęp do sieci lokalnej w opisany przez Ciebie sposób (na OpenWRT) zakłada, że klient ZeroTier jest postawiony na routerze, który jest bramą domyślą dla danej sieci? Przez co stacje w sieci lokalnej idą przez domyśle gw, ktory to już wie gdzie dalej routing zrobić.

Czy w przypadku gdy router z klientem ZeroTier nie jest "default gw" należy:

a) jak to jest możliwe przez DHCP wymusić trasę do danej sieci na stacjach z LAN przez dany adres IP (router z klientem)? Swoją droga Android ma problem z opcją/parametrem dhcp 121 (po prostu go ignoruje - moje testy).
b) na takim routerze dodatkowo ustawić SNAT do sieci lokalnej co rozwiązuje problem routingu dla połączeń przychodzących przez vpn.

Powiedz czy dobrze myślę, kombinuję?

P.S.
Pytanie czy "snat" nie robi już ten wpis "uci set firewall.@zone[-1].masq=1" i mój wywód o default gw jest delikatnie mówią nie na miejscu...


Pozdrawiam,
MvincM

152

(207 odpowiedzi, napisanych Oprogramowanie / Software)

Teraz jasne. Dzięki!

153

(207 odpowiedzi, napisanych Oprogramowanie / Software)

Ok. Szukałem z LUCI. Dzięki!

P.S.
A z ciekawości dlaczego nie z LUCI?

154

(207 odpowiedzi, napisanych Oprogramowanie / Software)

@Cezary

Jest szansa na Twoje obrazy (19.x) dla tego modelu?

Z góry dzięki,
MvincM

155

(75 odpowiedzi, napisanych Oprogramowanie / Software)

Ok. Jasne.

Idę w takim razie w opcje esp8266 + micropython (pomiar temp + czujnik fazy w cyklu dajmy to co minutę). Odczytane wartości wystawie jako json albo prosty tekst. Do przemyślenia czy nie zrobię Ethernet (via SPI) na bazie w5500 co by wt3020 nie dawać w ogóle.

156

(75 odpowiedzi, napisanych Oprogramowanie / Software)

Thx!

A pytanie jeszcze. Nie portujesz do nowszej wersji z racji niekompatybilnosci kodu czy małego zainteresowania odbiorców?

Alternatywa oczywiście jest ale to zawsze dwa urządzenia, dwa zasilania itd.

157

(75 odpowiedzi, napisanych Oprogramowanie / Software)

Dziękuję. Tak zrobię - w sensie rozwiąże obie opcje.

P. S.
Która ostatnia wersja openwrt/lede wspiera lw?

158

(75 odpowiedzi, napisanych Oprogramowanie / Software)

Witaj.

Potrzebuje GPIO (4 wejścia) a w opcji wypas I2C - dałbym wtedy ekspander. Chciałem zgrabny i mały zestaw zrobić wraz z wt3020 (tu akurat udało mi się odszukać dwa dodatkowe pady/wolne gpio na płytce i dolutować kynar ale nadal brak tych dodatkowych 2-3).

Zastosowanie to pomiar temperatury po 1-wire i czujnik zaniku fazy (dla każdej fazy oddzielnie oczywiście izolowane optycznie).

Takie "maleństwa" wydały mi się idealne do takiego zastosowania (tym bardziej że bez WiFi bym sprawę załatwił).

Alternatywy jakie ja widzę to: wt3020 + esp8266/esp32 lub Raspberry.

Będę wdzięczny za podrzucenie innych rozwiązań/alternatyw. Chętnie się zainteresuje.

P. S.
"Komercyjne" rozwiązania do wykrycia zaniku fazy są drogie (relatywnie) a i tak nie ma komunikacji itd.

Pozdrawiam
MvincM

159

(75 odpowiedzi, napisanych Oprogramowanie / Software)

Witam.

Powiedzcie proszę czy się mylę czy dla OpenWrt 18.06 i 19.07 nie ma modułu "kmod-gpio-lw-usb" jak i pakietu "littewire"? Bez tego jak rozumiem, nie da się używać tiny85 z wgranym littlewire?

Z góry dzięki za informację.

MvincM

Witam.

Faktycznie można wyłączyć DHCP na routerze LTE i przenieść na OpenWRT. Wtedy w dnsmasq wykorzystać opcję 121 (zgodnie z RFC-3442). W tej opcji wszytko może opierać się na routingu na poziomie hostów (wsparty wewnętrznym routingiem w tunelu VPN - opcja "iroute" w odpowiednich plikach *.ccd) i faktycznie nie będzie potrzeba SNAT.

BTW... dlaczego NATa w tym przypadku SNATa uważasz za zło konieczne?

ROZWIĄZANE !!!

Dla potomnych.

plik: /etc/config/firewall

Jest:

config zone
        option name 'lan'
        option input 'ACCEPT'
        option output 'ACCEPT'
        option forward 'ACCEPT'
        option network ' '

Powinno być:

config zone
        option name 'lan'
        option input 'ACCEPT'
        option output 'ACCEPT'
        option forward 'ACCEPT'
        option network 'lan'

Brakuje "lan" w "option network". Efektem czego było odrzucanie pakietów wychodzących z lan do vpn. Oczywiście w pierwszym swoim poście uznałem te linie za mało ważne i ich nie zamieściłem jako zrzut z /etc/config/firewall no ale już wiemy, że były ważne.

Dzięki za chęć pomocy !

P.S.
Podpowiem, że nie mam pojęcia jakim cudem zniknął ten znaczący drobiazg z pliku.

Pozdrawiam,
MvincM

Dzięki za odpowiedź i chęć pomocy !

Generalnie to co proponujesz jest oparte  na routingu i powinno działać. Jest mi to znajome. Ogólnie dodawałem routing (na testy) poprzez "route add..." na klientach i serwerze a nie wymuszone z OpenVPN ale nie w tym rzecz ponieważ:

- mój klient OpenWRT nie jest deafult gw w swojej sieci
- dostępu do routera/bramy nie mam wprost
- a nawet jakbym miał to jest to router LTE (brandowany) w którym nie można dodać "static route" a tym bardziej specyficznych opcji DHCP aby wskazać dedykowane bramy
- a poza tym wszystkim kurcze ten SNAT musi chodzić, to nie magia... i to mnie najbardziej denerwuje, tym bardziej, że na starszym OpenWRT (jeszcze LEDE) taka konfiguracja działała poprawnie. Czyli coś w ustawieniach firewall na OpenWRT nie jest poprawne

Może ktoś ma jeszcze jakiś pomysł? Z góry dzięki.

MvincM

Witam.

Szanowni wiem, że temat OpenVPN był poruszany już milion razy ale takiego cuda jeszcze chyba nie było.

Konfiguracja:

- Serwer VPN na publicznym IP, Debian 9.5, konfiguracja TUN, subnet, sieć 192.168.26.0/24, ip von 192.168.26.1 (plik konfiguracyjny później).
- Klient OpenWRT (sieć lokalna: 192.168.24.0/24, ip vpn: 192.168.26.10)
- Klient Windows (sieć lokalna: 192.168.22.0/24 ip vpn: 192.168.26.12)
- Klient OpenWRT nie jest bramą domyślną w sieci lokalnej i nie będzie raczej (co rzutuje na przedstawiany problem)

Scenariusz:

Klient Windows z sieci 192.168.22.0/24 ma mieć dostęp do sieci lokalnej klienta OpenWRT tj. 192.168.24.0/24 (ku pamięci OpenWRT nie jest bramą domyślną dla 24.0). Wniosek, że klient OpenWRT musi robić SNAT z sieci vpn 26.0 na swój adres IP (192.168.24.31) do swojej sieci lokalnej 24.0.

Stan obecny:

Ruch/pingi między klientami działają, między serwerem OpenVPN a klientami działają. Ruch pingi do dowolnego hosta w sieci 24.0 idzie ale klient OpenWRT zwraca REJECT a konkretnie "destination host unreachable". Pakiety na kliencie OpenWRT trafiają do destination REJECT (widać do po rosnącym liczniku pakietów REJECT w iptables).

No i nie wiem dlaczego ten SNAT mi nie dzieła i dlaczego któraś reguła wymusza skierowanie do REJECT. Z góry dodam (czego nie widać w konfigu), że dodaję oczywiście trasę do sieci 24.0 (robiłem to na dwa sposoby: przez ip klienta OpenWRT jako  "gw" do sieci 24.0 oraz inaczej routing do sieci 24.0 po prostu przez interfejs tun0 bez podawania "gw"). Z resztą routing działa bo można pingać 192.168.24.31.

Konfiguracja:

Serwer OpenVPN (server.conf)

port 443
proto udp
dev tun
ca /etc/openvpn/certs/keys/ca.crt
cert /etc/openvpn/certs/keys/server.crt
key /etc/openvpn/certs/keys/server.key
dh dh4096.pem
topology subnet
server 192.168.26.0 255.255.255.0
client-to-client
keepalive 5 30
tls-auth /etc/openvpn/certs/keys/ta.key 0
cipher AES-256-CBC
auth SHA512
tls-cipher TLS-DHE-RSA-WITH-AES-256-GCM-SHA384:TLS-DHE-RSA-WITH-AES-128-GCM-SHA256:TLS-DHE-RSA-WITH-AES-256-CBC-SHA:TLS-DHE-RSA-WITH-CAMELLIA-256-CBC-SHA:TLS-DHE-RSA-WITH-AES-128-CBC-SHA:TLS-DHE-RSA-WITH-CAMELLIA-128-CBC-SHA
persist-key
persist-tun
status openvpn-status.log
verb 3
explicit-exit-notify 1

OpenWRT (client.conf):

config openvpn 'sample_client'
        option client '1'
        option dev 'tun'
        option proto 'udp'
        option resolv_retry 'infinite'
        option nobind '1'
        option persist_key '1'
        option persist_tun '1'
        option user 'nobody'
        option comp_lzo 'yes'
        option verb '3'
        option pull '1'
        option remote_random '0'
        option cert '/etc/luci-uploads/cbid.openvpn.sample_client.cert'
        option key '/etc/luci-uploads/cbid.openvpn.sample_client.key'
        option ca '/etc/luci-uploads/cbid.openvpn.sample_client.ca'
        list remote 'moj.vpn.pl 443'
        option tls_auth '/etc/openvpn/ta.key 1'
        option cipher 'AES-256-CBC'
        option auth 'SHA512'
        option keepalive '5 30'
        option enabled '1'
        option keysize '256'

OpenWRT (firewall)

config zone
        option input 'ACCEPT'
        option output 'ACCEPT'
        option name 'vpn'
        option forward 'ACCEPT'
        option network 'vpn'

config redirect
        option target 'SNAT'
        option src 'vpn'
        option dest 'lan'
        option name 'vpn-lan'
        option src_dip '192.168.24.31'
        option enabled '1'
        option src_ip '192.168.26.0/24'
        option dest_ip '192.168.24.0/24'
        option proto 'all'

config forwarding
        option dest 'lan'
        option src 'vpn'

config forwarding
        option dest 'wan'
        option src 'vpn'

config forwarding
        option dest 'vpn'
        option src 'lan'

Z góry dzięki za pomoc w rozwiązaniu tej zagadki !!!

Pozdrawiam
MvincM

164

(58 odpowiedzi, napisanych Oprogramowanie / Software)

intruder napisał/a:

Tu może coś dla siebie znajdziecie: https://trzepak.pl/viewtopic.php?t=51177

I wszystko jasne! Dzięki za dobry link - wytłumaczone i podane rozwiązanie.

Dziękuję.

MvincM

165

(58 odpowiedzi, napisanych Oprogramowanie / Software)

Czyli teza jest taka, że:

Ad. VLAN
Powinien być ustawiony ten sam ID jak ma FunBox?

Ad. WiFi
Nie mówię o zaśmieconym eterze i spowolnieniu ruchu wifi. Ewidentnie chodzi o pracę z FunBox i ftth od Orange. Spowolnienie jest takie, że to nie wina eteru. Ten sam router, to samo wifi w tym samym miejscu ale na upc śmiga.

166

(58 odpowiedzi, napisanych Oprogramowanie / Software)

Witam.

Podłączam się pod pytanie. Napotkałem ten sam problem. Dodatkowa obserwacja jest taka, że nawet router wpięty do routera orange ogranicza transfer ale już tylko po WiFi, po kablu jest ok. Faktycznie może być coś z tagowaniem VLANów.

@Cezary
Co miałeś na myśli w swojej odpowiedzi? Możesz rozwinąć proszę.

Pozdrawiam
MvincM

Wiem wiem :-) że tmp to ram :-)

Dlatego wątki łączę :-)

Hmmm!!!!

Taka obserwacja... Może to nie wina LEDE... W sensie zapewne jest mocniej zasobożerną odmianą systemu (zgodnie z tym co piszecie) jednak nie wiem czy przyczyną nie jest program/demon "smstool3".

Po pierwsze ciężko wyśledzić bo reboot się robi i po logach... muszę logi przepiąć na pendrive to zobaczę więcej. Nie mniej jednak smsd loguje swoją prace do katalogu /tmp. Przy okazji te logi są duże w rozumieniu, że na bogato loguje. Ten plik z logami leży sobie w /tmp i go zapycha do zera wolnego. I teraz zapewne to, że LEDE wywala się przy logowaniu (udanym!) przez ssh jest powiązane z faktem, że ssh chce coś pisać do /tmp a tam zero miejsca i pewnie tak to się już dalej dzieje.

Odtwarzam sytuację na CC i sprawdzę ale już po jednym dniu log smsd zapchał mi /tmp a wykryłem to faktem, że nie utworzył się plik "/tmp/resolv.conf.auto" przy restarcie wan (z racji braku miejsca w tmp)  i przestał działać nazwijmy to "dns" tj. dnsmasq nie podawał adresów na zapytania klientów.

Resume:
- czy powyżej opisana sytuacja może prowadzić do reboot? Do czasu przepięcia logów na pendrive trochę zgaduje...
- czy ktoś miał przejścia z smsd i potwierdza niezbyt racjonalne zarządzanie logami?
- czy ma ktoś doświadczenie z logrotate dla openwrt/lede?

Dzięki i pozdrawiam,
MvincM

No i jasne... Router w wersji 32MB na LEDE raczej jest średnio używalny (w moim przypadku).

Wróciło CC i będę testował... W moim zastowaniu CC wystarczy a stabilnie. Co nie zmienia faktu, że przyjdzie czas gdy wersje/pakiety/sterowniki przy którymś zastosowaniu okażą się nie wystarczające i wtedy pożegnam wydłużonego, poczciwego 1043v1.

MvincM

Pozdrawiam
MvincM

Dzięki za info...

Nie siedząc mocno w samej architekturze LEDE zastanawiam się czy to zwiększone zapotrzebowanie na RAM wynika z błędu, braku optymalizacji, itd.?

Swoją drogą zanim się reboot zrobi przy logowaniu przez ssh to kawałek banera było widać i na moment logowania nie było krytycznie mało pamięci (widać na tym kawałku banera) co może sugerować błąd jakiś. Zastanawiające..

Pozdrawiam
MvincM

@Cezary

A OpenWRT w szczególności CC już umarło całkowicie?

MvincM

Dzięki za info.

No to CC w pierwszej kolejności...

Witam.

Czy ktoś się może spotkał z podobnym problemem? Czyste LEDE bez LUCI po bootcie taka zajętość

Machine: TP-Link TL-WR1043N/ND v1
Uptime: 0d, 00:40:44
Load: 0.04 0.07 0.06
Flash: total: 4.1MB, free: 2.2MB, used: 45%
Memory: total: 27.1MB, free: 12.5MB, used: 53%

i po pewnym czasie router zalicza reboot... przeważnie w momencie logowania się przez ssh... pojawia się pół banera i zwiecha (bo reboot się robi). Zakładam, że to przez wyzerowaną ilość wolnego ram ale zakładam bo ciężko z logami przy takim reboot...

Z ekstrasów mam hub usb z własnym zasilaniem a do niego podpięty modem usb oraz UPS marki APC (no i apcupsd do niego)

Na CC jakoś nie było takiego problemu... Ktoś może coś podobnego doświadcza?

Dzięki,
MvincM

174

(4,561 odpowiedzi, napisanych Oprogramowanie / Software)

Dla wszystkich mających możliwość kupienia z USA (ktoś jedzie, ktoś i tak coś wysyła do PL itd.) nie ma lepszej propozycji niż ta:

https://www.amazon.com/Linksys-WRT1200A … +WRT1200AC

czyli Linksys WRT1200AC AC1200 Dual Band Smart Wi-Fi Router (Certified Refurbished) za 50USD

Pozdrawiam,
MvincM

O tyle ciekawe, że w CC nie było tego problemu a zakładam, że stare opkg = to co było CC