Sprawdzałem - nawet obawiałem się, że wielkość liter (choć nie powinna) może robić różnicę - nie zrobiła.
Router świeżo po przesiadce (ER-X -> Openwrt) więc nie ma nic poza standardowym 18.06.1 firewallem.
Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
eko.one.pl → Posty przez andrut
Sprawdzałem - nawet obawiałem się, że wielkość liter (choć nie powinna) może robić różnicę - nie zrobiła.
Router świeżo po przesiadce (ER-X -> Openwrt) więc nie ma nic poza standardowym 18.06.1 firewallem.
I dokładnie to chcę osiągnąć - aby sprzęty IoT z (długiej) listy MAC które nie potrzebują 'odbijać się' w cloudzie, nie robiły tego. :-)
Z tym, że magicznie ta reguła nie działa (tj. licznik wynosi 0, a ruch nie jest blokowany).
Przy żadnym innym z dokumentacji też nie :-) (hash i brak deklaracji także).
Tymczasowo chciałem zablokować te MAC-i pojedynczymi regułami i:
config rule
option enabled '1'
option src 'lan'
option proto 'all'
option name 'Drop-iot-1'
option target 'DROP'
option src_mac 'xxx'
option dest 'wan'Nie blokuje ruchu. Tej reguły już nie da się chyba bardzej uprościć, aby mogła zadziałać - czy coś pominąłem?
Udało się, choć w Luci nie widać odniesienia w żaden sposób do ipset'u (tylko w config/firewall).
Mam teraz problem z ipsetem dla MAC-adresów:
config ipset
option name 'bad_macs'
option match 'src_mac'
option storage 'list'
option enabled '1'
list entry 'xxx'
list entry 'xxx'
list entry 'xxx'Przy restarcie firewalla:
Warning: Section @ipset[1] (bad_macs) has an invalid combination of storage method and matchesChciałbym dla usługi wewnątrz LAN dopuścić ruch tylko z zewnętrznego proxy: Cloudflare
Publikują oni zakresy IP, które należy 'dopuścić', aby usługa działała prawidłowo - chciałbym odrzucać nieprawidłowy ruch już na firewallu, a nie dopiero na docelowej usłudze. Lista IP
Używam Firewalla z Luci, ale w tym wariancie jedyną możliwość widzę w 'wyklikiwaniu' ręcznie oddzielnej reguły dla każdego z zakresów.
Znalazłem też skrypt, który taką regułę doda automatycznie przy restarcie FW:
# for i in `curl https://www.cloudflare.com/ips-v4`; do iptables -I INPUT -p tcp -s $i --dport http -j ACCEPT; done
# for i in `curl https://www.cloudflare.com/ips-v4`; do iptables -I INPUT -p tcp -s $i --dport https -j ACCEPT; donePytania:
1. Czy ta reguła (wklejona w Luci) w zakładce 'własne reguły' będzie skonfigurowana prawidłowo mając na uwadze, że firewall w Openwrt jest nieco innej konstrukcji? INPUT nie powinien być zamieniony na zone_wan_input?
2. Jak zmodyfikować tą regułę, aby widoczna była w Luci? Zauważyłem (iptables --list) że te, które są w niej widoczne mają komentarz /* !fw3 */ niemniej jednak nie wiem gdzie go dodać w w/w skrypcie.
Docelowo ruch na port 443 i 80 powinien trafiać do wewnęrznego IP 192.168.1.11 na port 4567
EDIT:
Na forum trafiłem też na IPSET, udało mi się utworzyć listy więc teraz brakuje jedynie opcji użycia tych list w LUCI
Ok, udało się ustalić przyczynę - sieć działa na niezarządzalnych switchach i jeden z klientów (podobno) robił loopa.
Próbowałem zreplikować ten błąd, tj. zapętliłem niezarządzalny switch na WAN-ie routera - nie udało się, ale miałem tylko 'jeden' pakiet. W tcpdump widziałem wszystkie te dziesiątki zapytań ARP, w odróżnieniu od sytuacji kiedy pada sieć providera.
Nadal nie potrafię zrozumieć jakim cudem pada i odcina wszystkie podsieci routera do czasu wypięcia kabla.
Ponadto przetestowałem - WT3020 z najnowszym LEDE także 'wykrzacza' się po kilku minutach bycia podpiętym do 'zawieszonej' sieci. Oczywiście do czasu wypięcia kabla.
Jakieś pomysły jak uratować LAN przed podobną sytuacją w przyszłości?
Tu wpisujesz IP supernode'a na którym działa n2n z dostępem z zewnątrz.
Drop hostów BOGON nie pomógł, 'awaria' dziś się powtórzyła - brak pakietów na interfejsie.
Kończą mi się pomysły. ;-)
Trafił mi do rąk dongle, którego chciałem przetestować w ramach tego artykułu.
W ostatniej wersji z kernelem 4.4.112 jest błąd:
# opkg install kmod-rfkill kmod-bluetooth bluez-utils
Unknown package 'kmod-rfkill'.
Package kmod-bluetooth (4.4.112-1) installed in root is up to date.
Package bluez-utils (5.38-2) installed in root is up to date.
Configuring kmod-lib-lzo.
failed to find a module named lzo_compress
failed to find a module named lzo_decompress
Collected errors:
* opkg_install_cmd: Cannot install package kmod-rfkill.
* pkg_run_script: package "kmod-lib-lzo" postinst script returned status 255.
* opkg_configure: kmod-lib-lzo.postinst returned 255.Coś się pozmieniało w systemie po drodze, że tego modułu już nie ma?
Jesli próbujesz się dobrać do usługi WWW, to prponuję Cloudflare - ma darmowy 'most', dodatkowo zabezpieczający' z hostami IPv6.
A widzisz.
A ja miałem to w cronie, co 5 minut.
Nie używałem arp-scan, a zwykłego 'arp'
Później 'grep' na tych wynikach.
Flaga jest ustawiana jak pakiet nie dotrze do hosta, a przy dhcp-script jest odpalane tylko przy lease.
Co do arp to flaga 0x0 lub 0x2 odświeża się dziwnie. Z opóźnieniem i to nie wiadomo nigdy kiedy się odświeży.
Przed odświeżeniem puszczasz ping do hosta, że jest takie zachowanie?
@Cezary: o tym nie pomyślałem, ale musiałem wykrywać także kabelkowe hosty nie odpowiadające na pinga i pewnie dlatego nie skojarzyłem ;-)
Ze wszystkich opcji wspomnianych polecam swoją, przetestowaną.
Pingujemy IP smartfona (musi być na stałe przypisany w dhcp, żeby nie ulegał zmianie), a następnie przeglądamy tablicę arp.
Jeśli jest flaga 0x2 to telefon jest, jeśli 0x0 to nie ma. :-)
--EDIT:
Doprecyzowując - zaraz po rozłączeniu telefonu z WiFi, pierwszy kolejny ping wysłany do niego przestawi flagę w tablicy arp na 0x0.
Skrypt można odpalać w cronie co minutę.
Wieszające się WiFi występuje we wszystkich ostatnich releasach :-(
Bug jest zgłoszony i na razie nic nie zapowiada by był rozwiązany.
A ten projekt nie umarł?
-- EDIT:
Ok, pytasz o istniejący serwer.
Taki kwiatek właśnie szybki tcpdump pokazał na WANowym interfejsie:
23:53:41.868392 ARP, Request who-has 192.168.1.110 tell 192.168.1.252, length 46
23:55:59.044815 ARP, Request who-has 192.168.1.105 tell 192.168.1.252, length 46
23:55:58.343804 ARP, Request who-has 192.168.0.254 tell 192.168.0.252, length 46i tak dalej. Jednak DROP na publiczne klasy powinien pomóc. :-)
Nie mam dowodów na to, że ten pakiet się tam pojawił, ale profilaktycznie dodam te reguły.
Moje skojarzenia wywołała próba podłączenia kiedyś-kiedyś routera świeżo po flashu do openwrt, gdzie ten router swoim WAN-em podpięty był do innego routera także z adresacją 192.168.1.1
Finał był taki, że nie dao się 'dobić' do routera do czasu wyjęcia kabla LAN.
Tutaj niestety na końcówce (mojej) WAN mogą pojawiać się takie pakiety, na chwilę obecną infrastruktura opiera się na zwykłych switchach (niezarządzalnych), a sąsiedzi potrafią być kreatywni jeśli chodzi o podpięcie routerów, jak widać.
Dla mających podobny problem: obecnie moje jedyne domysły (wynikające z doświadczeń także z OpenWRT), które mogą prowadzić do takich zachowań:
- ktoś na 'końcówce' switchowej od operatora wpiął router, który operuje w tej samej klasie adreoswej co ja (192.168.1.1). Routery w takich chwilach zachowują się co najmniej dziwnie, a najczęściej tracą łączność z każdej ze stron.
Dla testu przemigrowałem wszystkie hosty w sieci na inną klasę adresową, raczej nie popularną - teraz pozostaje czekać na awarię. Wrócę z informacją, jeśli diagnoza się powiedzie (tylko skąd wtedy będę wiedział, że na sieci jest 'pętla'? ;-))
Adres IP mam na stałe przypisany (i jest on jednocześnie zewnętrznym), więc nie odpytuje DHCP.
tcpdump jedynie pyta przez ok 5 minut ARP o gateway i po tych 5 minutach dostęp ze strony LAN do routera pada. Zajmuje to +/- dokładnie 5 minut i jedyna opcja przywrócenia łączności/pinga do routera to wypięcie kabla ze strony WAN.
Ułamek sekundy później router odpowiada na pingi, pozwala zalogować się do ssh etc.
Na gorąco, z telefonu: sytuacja znowu ma miejsce. Nie ma internetu, tcpdump -i eth0 pokazuje tylko zapytania ARP routera, po 5 minutach router znika.i zaczyna odpowiadać ponownie dopiero po wypięciu kabla WAN.
Co sprawdzić, żeby zdiagnozować problem?
Lekki OT: Na cóż ten PMK może się przydać?
Ja też, tym bardziej że Luci sporo poszło do przodu, a tej opcji brak. :-)
Ale żeby to wywaliło komunikację na ER-X?
Chyba, że ktoś wystawił... prywatną adresację? Chyba dorwę jakieś padło i przetestuję.
Dostawca poinformował, że usunęli usterkę, cytuję: "Ktoryś z klientów na osiedlu zrobił tak zwaną pętlę na łączach co powodowało brak sygnału".
Nie wiem o jaką pętlę chodzi (pewnie ktoś chciał dołożyć router), ale skoro był w stanie wywalić ER-X... to nadal mnie to martwi. :-)
eko.one.pl → Posty przez andrut
Forum oparte o PunBB, wspierane przez Informer Technologies, Inc