Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
eko.one.pl → Posty przez Grzesinski
Ale domyślnie w konfiguracji tego nie widzę a standardowo przyjmuje 1 i 5
/usr/sbin/pppd nodetach ipparam vpnpptp ifname pptp-vpnpptp lcp-echo-interval 1 lcp-echo-failure 5 lcp-ec
przy okazji są takie dwa procesy, chyba coś za dużo.
Chodzi o options.pptp ?
lcp-echo-interval 15
lcp-echo-failure 4
Chciałbym nieco odświeżyć temat.
Tunel PPTP działa prawidłowo ale monitorując router będący serwerem VPNów zauważyłem, że połączenie PPTP z Gargoyle (1.13.0.0pre11) jako jedyne z całej puli jednocześnie podłączonych klientów non stop negocjuje połączenie.
Nie mam pojęcia czemu co 1-2s wymieniane są magic numbers
PPTP (VPN-1) ==> Protocol:LCP(c021) EchoRep Identifier:0xD9 Magic Number: 0x0 00 01 ##
PPTP (VPN-1) <== Protocol:LCP(c021) EchoReq Identifier:0xD9 Magic Number: 0xaeb2 56 8f ##
Prawie cały log połączeń VPN to wpisy z tego połączenia pomimo, że transfer w nim zerowy.
Log systemowy Gargoyle czysty, konfiguracja VPN wygląda ok i działa.
uci show network pokazuje prawidłowe ustawienia
network.vpnpptp=interface
network.vpnpptp.proto='pptp'
network.vpnpptp.server='x.x.x.x'
network.vpnpptp.username='tunel'
network.vpnpptp.password='pass'
network.vpnpptp.defaultroute='0'
Da się to okiełznać?
Dwa razy -L w poleceniu?
O dziwnym zachowaniu firewalla w WRT było na forum pisane wielokrotnie.
Może czas na usystematyzowanie wiedzy.
Konkretny mój przypadek (domeny itp uprościłem, to tylko przykład) - dopuszczony ruch dla konkretnego hosta w określonym czasie do wybranych domen.
config restriction_rule 'rule_6'
option is_ingress '0'
option description 'Tylko wybrane witryny 07:00-16:00'
option family 'any'
option local_addr 'XX:XX:XX:XX:XX:XX'
option active_weekdays 'mon,tue,wed,thu,fri'
option active_hours '07:00-16:00'
option proto 'both'
option not_url_domain_exact '"www.google.com","www.google.pl"'
option not_url_domain_contains '"aka.ms","akadns.net"
option enabled '1'
Działa od wielu miesięcy bez problemowo.
Wczoraj pojawiła się konieczność włączenia dodatkowego dostępu do innej domeny w innych ramach czasowych.
Na szybko zrobiłem to jako wpis białej listy
config whitelist_rule 'exception_2'
option is_ingress '0'
option description 'Youtube Sr 08-09'
option family 'any'
option local_addr 'XX:XX:XX:XX:XX:XX'
option active_weekdays 'wed'
option active_hours '08:00-09:00'
option proto 'both'
option url_domain_contains '"youtube","youtu.be","googlevideo","ytimg"'
option enabled '1'
Efekt - przestały działać dostępy z pierwszej listy.
Wyłączyłem drugą regułę i wszystko zaczęło działać jak powinno.
Zastanawiałem się czy nie stworzyć kolejnej reguły restrykcji zamiast białej listy ale nie wiem jak to będzie działać.
Jeśli pierwsza reguła restrykcji nie zezwala na 'youtube' a kolejna w tym momencie tak, to jaki będzie wynik działania.
W większości urządzeń jest możliwość zmiany kolejności reguł, niestety Gargoyle (1.13.0.0pre11) tego nie udostępnia.
Można oczywiście ręcznie przenumerować, poprzesuwać reguły (ważna jest kolejność linii czy numery reguł?)
Identyczny efekt można uzyskać zarówno poprzez restrykcje jak i białą listę, która ma wyższy priorytet?
Czy są jakieś dobre praktyki którą listę stosować do czego? Może jest jakiś sensowny opis?
Nie wykluczam, że pojawiły się chwilowe błędy w systemie a sam restart firewalla rozwiązał problem (log systemowy jest czysty) ale niezależnie od tego pytania są aktualne, bo problem zapewne powróci.
To czas liczony od 01.01.1970
Dla wartości umieszczonej w komórce A1
formuła 
((A1/60)/60)/24)+DATA(1970;1;1)
i komórka sformatowana jako data
powinno wyświetlić datę rekordu.
Adguard wygląda ciekawie, ale to na przyszłość. Muszę się mu przyjrzeć.
sky:
Te reguły wskakują wyłącznie z /etc/firewall.user
W preroutingu nie mam żadnej tego typu, dokładam do ww. pliku dwie reguły:
iptables -t nat -I PREROUTING -s 192.168.2.0/24 -p tcp --dport 53 -m mac ! --mac-source xx -j DNAT --to 192.168.2.1
iptables -t nat -I PREROUTING -s 192.168.2.0/24 -p udp --dport 53 -m mac ! --mac-source xx -j DNAT --to 192.168.2.1
i w preroutingu pojawiają się:
num pkts bytes target prot opt in out source destination
1 0 0 DNAT udp -- * * 192.168.2.0/24 0.0.0.0/0 udp dpt:53 MAC ! xx to:192.168.2.1
2 0 0 DNAT tcp -- * * 192.168.2.0/24 0.0.0.0/0 tcp dpt:53 MAC ! xx 0 to:192.168.2.1
3 0 0 DNAT udp -- * * 192.168.2.0/24 0.0.0.0/0 udp dpt:53 MAC ! xx to:192.168.2.1
4 0 0 DNAT tcp -- * * 192.168.2.0/24 0.0.0.0/0 tcp dpt:53 MAC ! xx to:192.168.2.1
Coś zaczęło działać.
W iptables -v -L -n -t nat powinny być 4 wpisy? Wygląda jak duplikowanie tego samego. Pakiety zlicza tylko na pierwszym.
Pozostaje walka z cachowaniem wpisów na PC.
Analogicznie jak rozumie zamiast /etc/init.d/network restart /usr/lib/gargoyle/restart_network.sh
Odnośnie mediateka w Gargoyle 12 to zrobiłem nocne wyłączanie WiFi i póki co jest nieźle.
Za krótko żeby wyrokować o stabilności ale już widać że wyszukiwanie sieci WiFi przez klientów działa szybko.
A bywało z tym różnie, niekiedy bardzo źle.
To może być rozwiązanie/obejście problemów.
Pytanie czy wywoływany wtedy gargoyle_firewall_util.sh nie nadpisze ręcznych zmian konfiguracji?
Ale faktycznie restart_firewall.sh wykonuje operacje na BWMON, WEBMON, QOS.
Zauważyłem, że podany wcześniej problem pojawia się po zrestartowaniu firewalla z poziomu CLI, wszystko wraca do pracy po restarcie firewalla z www GUI. Zatem to chyba nie wina reguł a specyfiki Gargoyla.
W opisywanym przypadku zmieniałem ustawienia logowania z CLI i po restarcie firewalla (CLI) zaczęły się problemy z BWMOM.
Wyłączenie reguły firewalla (bez znaczenia) z GUI i restart z GUI (istotne) przywrócił prawidłowe działanie BWMON.
Wygląda na to, że Gargoyle może nadpisać ustawienia z CLI, ale również że komendy CLI mogą zakłócać pracę Gargoyle.
Warto pamiętać.
iptables -L -n -t nat
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
REDIRECT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:53 MAC ! xx:xx:xx:xx:xx:xx redir ports 53
REDIRECT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:53 MAC ! xx:xx:xx:xx:xx:xx redir ports 53
REDIRECT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:53 MAC ! xx:xx:xx:xx:xx:xx redir ports 53
REDIRECT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:53 MAC ! xx:xx:xx:xx:xx:xx redir ports 53
.....
Chain zone_lan_prerouting (1 references)
target prot opt source destination
REDIRECT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:53
REDIRECT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:53
prerouting_lan_rule all -- 0.0.0.0/0 0.0.0.0/0 /* !fw3: Custom lan prerouting rule chain */
Tak wiem, są obie są zmienione w /etc/firewall.user - osobno tcp i udp (wpisy jak podałem kilka postów wyżej).
Chodzi o prawidłowość składni, bo coś mi to wykluczenie nie działa.
Tak to powinno wyglądać?
iptables -t nat -I PREROUTING -p tcp --dport 53 -j REDIRECT --to-ports 53 -m mac ! --mac-source xx:xx:xx:xx:xx:xx
Bo niestety wykluczenie nie zaskoczyło (po restarcie firewalla i flush DNS na PC).
Nadal korzysta z DNS routera a nie ręcznego wpisu.
Mam nadzieję, że poprawiony będzie w końcu driver do Mediateka.
Ten w Twoim wydaniu jest lepszy (czytaj wiesza się zdecydowanie rzadziej) niż w wydaniu 12.
Ale się wiesza niestety co kilka dni.
Myślę nad watchdogiem ew. okresowym restartem WiFi (lub jego harmonogramem).
Pytanie czy to wystarczy (tj. samo WiFi) czy konieczny jest restart całego urządzenia.
Tyle, że Gargoyle zatrzymało się już dawno.
Twoja wersja jest najnowsza.
Nie widziałem żadnych zapowiedzi.
Problem rozwiązany.
Włączona była reguła czasowa zezwalająca na połączenia dla wybranych komputerów tylko dla określonych domen.
Padło gdy włączyłem drugą zabraniając sztywno określonych domen przez cały czas.
Oczywiście listy nie pokrywały się, przynajmniej literalnie.
Ale ostatnio nie mogłem zablokować domeny i okazało się, że jest przekierowana w DNS jako poddomena w dopuszczalnej w firewallu puli domen. Wymagałoby to dogłębniejszej analizy.
Problem jest tu
/etc/init.d/bwmon_gargoyle reload
uci: Entry not found
Bad argument `CONNMARK'
Pliki mogę zachować ale muszę to uruchomić. Dość sprawnie.
Skasowanie raportów z dzisiaj (tmp) i restart BWmon ?
Znalazłem w sieci informacje o problemie ale rozwiązań brak.
Pojawiły mi się dzisiaj błędy BWmon i nie działa rejestracja wykorzystanych danych.
ERROR: Bandwidth query failed, make sure rule with specified id exists, and that you are performing only one query at a time.
Thu Apr 15 10:05:17 2021 daemon.err uhttpd[2001]:
Nie chciałbym kasować zarejestrowanego wcześniej ruchu, bo muszę nadzorować wykorzystanie limitów LTE.
Z poziomu modemu widać, że transfer idzie.
Spotkał się ktoś z takim problemem?
Dziękuję 
Właśnie sprawdzałem. I zawsze informacja fragmentaryczna w konkretnym kontekście.
Szczegóły zawsze można sobie doszukać, chodzi o dostępne przełączniki itp.
Nie zamierzam się doktoryzować, potrzebny dobry punkt wyjścia.
A jest gdzieś dobry, pełny opis składni iptables?
Faktycznie Gargoyle wrzuca to w /etc/firewall.user
iptables -t nat -I PREROUTING -p tcp --dport 53 -j REDIRECT --to-ports 53
iptables -t nat -I PREROUTING -p udp --dport 53 -j REDIRECT --to-ports 53
Jaki jest przełącznik wykluczenia hosta?
A dał się zrobić wyłączenie "Wymuszaj używanie routera jako serwera DNS" dla wybranego hosta?
Ma dostawać standardowy DNS z DHCP ale ręcznie ustawiony adres DNS nie powinien być przekierowany przez router.
W Gargoyle standardowo listy są aktualizowane z automatu raz na tydzień (wpis do crona ze skryptu).
Dla blokowania reklam to będzie OK, ale dla pishingu wydaje się stanowczo za rzadko.
Myślę, że raz na dzień ew. dwa powinno być rozsądnym kompromisem.
eko.one.pl → Posty przez Grzesinski
Forum oparte o PunBB, wspierane przez Informer Technologies, Inc