' target='_blank'>Link
20 Kwietnia 2024 14:10:59
Nawigacja
· Strona Główna
· Forum
· Tomato by Shibby
· FreshTomato

Wątki na forum
Najnowsze dyskusje
· Szukam zaproszenia n...
· konfiguracja router ...
· [Howto] Xpenology na...
· dodatkowe złącza s...
· RT-N18U - nie można...
· Asus TUF-AX3000_V2 p...
· [MOD] Tomato64 (x86-64)
· Firewall nie zawsze ...
· [MOD] FreshTomato-AR...
· Optware na CIFS
· RT-AX56U - Status kl...
· [MOD] FreshTomato-MI...
· Multiroom N z wykorz...
· [S] Asus RT-AC68U E1
· [S] ASUS RT-AC68U
· Rozłączanie klient...
· serwer VPN za wan'em
· Przejscie z dyndns f...
· WDR3600 i problem z WAN
· Jaki USB hub do syno...
Najpopularniejsze obecnie wątki
· [Howto] Xpenology... [21]
· Szukam zaproszeni... [16]
· dodatkowe złącz... [4]
· konfiguracja rout... [0]
Ankieta
Jaki procesor posiada twój router?

Broadcom MIPSEL
Broadcom MIPSEL
36% [151 głosów]

Broadcom ARM
Broadcom ARM
52% [216 głosów]

Atheros
Atheros
5% [22 głosów]

Marvell
Marvell
1% [4 głosów]

Ralink
Ralink
1% [3 głosów]

Intel/AMD/VIA
Intel/AMD/VIA
1% [5 głosów]

Żaden z powyższych
Żaden z powyższych
4% [15 głosów]

Ogółem głosów: 416
Musisz zalogować się, aby móc zagłosować.
Rozpoczęto: 02/02/2015 09:38
Twoje IP
18.221.165.246
Zobacz wątek
OpenLinksys » :: OPROGRAMOWANIE :: » Tomato - firmware
 Drukuj wątek
OpenVPN dla zdefiniowanych klientów
servee
Top  #1 Drukuj post
Dodano 04-12-2016 16:44
Mam spięte kilka sieci poprzez TAP wg tego tutoriala z niewielkimi modyfikacjami.
Chcę ograniczyć dostęp do tunelu wybranym klientom, którzy są podpięci do portów LAN routera (po stronie klienta) z wycielonym VLAN'em.
Najlepiej żeby było to filtrowanie po adresie MAC. Jak sądzę najlepiej sprawdzi się tu dodanie reguł iptables. Niestety nie ogarniam ich takim stopniu, żeby sobie z tym poradzić.
Czy może mi ktoś z Was podać zapis takiej reguły - będę wdzięczny.
Ewentualnie może inaczej da się rozwiązać ten problem?

Połączony z 04 grudzień 2016 21:26:39:
Wpisanie jakiejkolwiek reguły iptables w polu Custom powoduje zablokowanie ruchu przez tunel, np. ping.
Jak powinna być sformułowana reguła tu się znajdująca?
Można prosić o jakiś przykład? Chodź nie ukrywam, że najlepszy byłby zbliżony do tego co chcę osiągnąć Smile
Czy reguły tu wpisane gdzieś się zapisują? Można je wyświetlić/podglądnąć poprzez ssh?
servee załączono następujące plik:
Nie masz uprawnień, by zobaczyć załączniki w tym wątku.
Edytowany przez servee dnia 04-12-2016 21:26
 
dar3k
Top  #2 Drukuj post
Dodano 04-12-2016 21:47
W to miejsce nie wpisuj nic z iptables bo to custom config ale dla OpenVPN, iptables musisz wpisać np w script -> firewall (lub po SSH).

Zobacz tutaj:
http://unix.stackexchange.com/questions/88034/set-up-firwall-with-iptables-to-only-allow-vpn

PS: Trochę mało czytelnie opisałeś swój problem. Czy do tego samego VLANa co porty LAN routera klienta wpięte jest coś co ma mieć dostęp do VPNa?
ER-12 + 4x UAP-AC-PRO
 
servee
Top  #3 Drukuj post
Dodano 04-12-2016 21:53
Dzięki za odpowiedź.
Właśnie zauważyłem, że wpisując iptables w pole custom wywala mi tunel, czyli potwierdza się to co napisałeś - nie w tym miejscu.
Jutro postaram się wkleić jakiś schemat, żeby było czytelniej.
Ważne, że już jakieś postępy są :).

Połączony z 05 grudzień 2016 11:59:51:
Zgodnie z obietnicą wklejam schemat sieci oraz mam nadzieję czytelniejszy opis.

Lewa strona (klient 1 VPN):
Do portu 3 i 4 mam wpięte 2 komputery, które mają dostęp do sieci VPN. Zdarzyło się jednak, że wpieła się tam nieuprawnopna osoba i miała dostęp do wszystkich zasobów w obrębie tej sieci. Chciałbym w przyszłości uniknąć takiego przypadku.
W jaki sposób ogranicznyć dostęp do br1 tylko dla uprawnionych?
Blokada portów 3 i 4 tylko dla konkretnych MAC (da się tak ?), czy filtrowanie dostępu do VPN?

Środek (serwer VPN):
Tutaj nic nie chciałbym zmieniać, ani wprowadzać dodatkowych reguł.

Prawa strona (klient 2 VPN):
Dostęp do sieci VPN jest tylko poprzez wifi na oddzielnym VLAN'ie.
Zabezpieczeniem jest hasło do sieci bezprzewodowej. Myślę, że tutaj też wypadało by zrobić ogranicznie tylko dla znanych MAC, bo nie mam wpływu na to, czy hasła nie otrzyma nieuprawiona osoba.

Połączony z 06 grudzień 2016 15:24:59:
Doszedłem do wniosku (czy słusznie?), że zrobię filtrowanie MAC z poziomu portu LAN routera.
Czy będą działać takie ustawienia jak poniżej i czy składnia jest prawidłowa?

Kod Pobierz kod źródłowy  

iptables -(Y) INPUT -i eth(x) DROP #zablokuj cały ruch przychodzący do routera z portu eth(x)

iptables -(Y) FORWARD -i eth(x) DROP #zablokuj cały ruch przechodzący przez port eth(x) routera

iptables -(Y) FORWARD -i eth(x) -m mac --mac-source a1:aa:aa:aa:aa:aa -j ACCEPT #zezwól na ruch przechodzący przez router dla portu eth(x) dla klienta o MAC a1:aa:aa:aa:aa:aa


Czy to zadziała?
Nie wiem, też jakie parametry powinny się kryć pod (Y) oraz jakim poleceniem sprawdzić jaki numer ma port 3 i 4 w routerze. Tu oznaczone jako eth(x).
Komenda ifconfig wyświetla mi tylko eth0 i eth1, więc już sam nie wiem, czy to odnosi się do fizycznych portów w routerze.

Połączony z 10 grudzień 2016 17:49:51:
Jak zaznaczyłem na wstępie zmiany wykonuję w obrębie klienta openVPN.
Błądzę, błądzę, ale wydaje mi się, że w lesie jest coraz mniej drzew :)
Na razie działam na łańcuchach typu INPUT, bo łatwiej jest mi testować poprawność działania reguł pomiędzy ROUTER<->PC.
Czy to co (jak mi się wydaje) ustaliłem w rzeczywistości tak działa? A mianowicie:
Na początek co i jak mam poustawiane:

Router IP Addresses br0 (LAN) - 10.1.1.1/24
br1 (LAN1) - 192.168.1.202/24
DHCP br0 (LAN) - 10.1.1.2 - 10.1.1.10
br1 (LAN1) - Disabled

Kod Pobierz kod źródłowy  

# cat /etc/iptables

*mangle

:PREROUTING ACCEPT [0:0]

:OUTPUT ACCEPT [0:0]

-I PREROUTING -i vlan2 -j DSCP --set-dscp 0

COMMIT

*nat

:PREROUTING ACCEPT [0:0]

:POSTROUTING ACCEPT [0:0]

:OUTPUT ACCEPT [0:0]

:WANPREROUTING - [0:0]

-A PREROUTING -d ip_zewnetrzne -j WANPREROUTING

-A PREROUTING -i vlan2 -d 10.1.1.1/255.255.255.0 -j DROP

-A PREROUTING -i vlan2 -d 192.168.1.202/255.255.255.0 -j DROP

-A WANPREROUTING -p icmp -j DNAT --to-destination 10.1.1.1

-A POSTROUTING  -o vlan2 -j MASQUERADE

-A POSTROUTING -o br0 -s 10.1.1.1/255.255.255.0 -d 10.1.1.1/255.255.255.0 -j SNAT --to-source 10.1.1.1

-A POSTROUTING -o br1 -s 192.168.1.202/255.255.255.0 -d 192.168.1.202/255.255.255.0 -j SNAT --to-source 192.168.1.202

COMMIT

*filter

:INPUT DROP [0:0]

:OUTPUT ACCEPT [0:0]

-A INPUT -m state --state INVALID -j DROP

-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

-N shlimit

-A shlimit -m recent --set --name shlimit

-A shlimit -m recent --update --hitcount 4 --seconds 60 --name shlimit -j DROP

-A INPUT -p tcp --dport 22 -m state --state NEW -j shlimit

-A INPUT -i lo -j ACCEPT

-A INPUT -i br0 -j ACCEPT

-A INPUT -i br1 -j ACCEPT

:FORWARD DROP [0:0]

-A FORWARD -m account --aaddr 10.1.1.0/255.255.255.0 --aname lan

-A FORWARD -m account --aaddr 192.168.1.0/255.255.255.0 --aname lan1

-A FORWARD -i br0 -o br0 -j ACCEPT

-A FORWARD -i br1 -o br1 -j ACCEPT

-A FORWARD -m state --state INVALID -j DROP

-A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

:wanin - [0:0]

:wanout - [0:0]

-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT

-A FORWARD -i br0 -o br1 -j DROP

-A FORWARD -i br1 -o br0 -j DROP

-A FORWARD -i vlan2 -j wanin

-A FORWARD -o vlan2 -j wanout

-A FORWARD -i br0 -j ACCEPT

-A FORWARD -i br1 -j ACCEPT

COMMIT




Kod Pobierz kod źródłowy  

# iptables -vL

Chain INPUT (policy DROP 41 packets, 10024 bytes)

 pkts bytes target     prot opt in     out     source               destination

    0     0 ACCEPT     all  --  tap11  any     anywhere             anywhere

    4   164 DROP       all  --  any    any     anywhere             anywhere            state INVALID

  715  231K ACCEPT     all  --  any    any     anywhere             anywhere            state RELATED,ESTABLISHED

    1    40 shlimit    tcp  --  any    any     anywhere             anywhere            tcp dpt:ssh state NEW

    0     0 ACCEPT     all  --  lo     any     anywhere             anywhere

   16  1802 ACCEPT     all  --  br0    any     anywhere             anywhere

   15  1445 ACCEPT     all  --  br1    any     anywhere             anywhere



Chain FORWARD (policy DROP 0 packets, 0 bytes)

 pkts bytes target     prot opt in     out     source               destination

    0     0 ACCEPT     all  --  tap11  any     anywhere             anywhere

  457 43716            all  --  any    any     anywhere             anywhere            account: network/netmask: 10.1.1.0/255.255.255.0 name: lan

    0     0            all  --  any    any     anywhere             anywhere            account: network/netmask: 192.168.1.0/255.255.255.0 name: lan1

    0     0 ACCEPT     all  --  br0    br0     anywhere             anywhere

    0     0 ACCEPT     all  --  br1    br1     anywhere             anywhere

    0     0 DROP       all  --  any    any     anywhere             anywhere            state INVALID

    0     0 TCPMSS     tcp  --  any    any     anywhere             anywhere            tcp flags:SYN,RST/SYN TCPMSS clamp to PMTU

  457 43716 ACCEPT     all  --  any    any     anywhere             anywhere            state RELATED,ESTABLISHED

    0     0 DROP       all  --  br0    br1     anywhere             anywhere

    0     0 DROP       all  --  br1    br0     anywhere             anywhere

    0     0 wanin      all  --  vlan2  any     anywhere             anywhere

    0     0 wanout     all  --  any    vlan2   anywhere             anywhere

    0     0 ACCEPT     all  --  br0    any     anywhere             anywhere

    0     0 ACCEPT     all  --  br1    any     anywhere             anywhere



Chain OUTPUT (policy ACCEPT 699 packets, 65309 bytes)

 pkts bytes target     prot opt in     out     source               destination



Chain shlimit (1 references)

 pkts bytes target     prot opt in     out     source               destination

    1    40            all  --  any    any     anywhere             anywhere            recent: SET name: shlimit side: source

    0     0 DROP       all  --  any    any     anywhere             anywhere            recent: UPDATE seconds: 60 hit_count: 4 name: shlimit side: source



Chain wanin (1 references)

 pkts bytes target     prot opt in     out     source               destination



Chain wanout (1 references)

 pkts bytes target     prot opt in     out     source               destination


1. Żadne nowe reguły wprowadzone do Administration->Scripts->Firewall nie działały bo w iptables była reguła
Kod Pobierz kod źródłowy  

-A INPUT -i br1 -j ACCEPT

i wpisanie czegokolwiek typu
Kod Pobierz kod źródłowy  

iptables -A INPUT -i br1 (cokolwiek_dozwolonego) DROP

nic nie dawało, bo nowo wpisana reguła znajdowała się poniżej pierwszej i wszystkie warunki zostały spełnione zanim analiza dotarła do tego miejsca.
Pomogło zapisanie jej w takiej postaci
Kod Pobierz kod źródłowy  

iptables -D INPUT -i br1 -j ACCEPT

iptables -A INPUT -i br1 (cokolwiek_dozwolonego) DROP

Z tego co wyczytałem pomogło by również zapisanie jej jako
Kod Pobierz kod źródłowy  

iptables -I INPUT -i br1 (cokolwiek_dozwolonego) DROP
i wówczas pojawiłaby się ona na początku.
Czy do tej pory poprawnie zrozumiałem zasady tworzenia reguł za pomocą Administration->Scripts->Firewall?

2. Po wpisaniu reguły do Administration->Scripts->Firewall, zapisaniu jej i zresetowania firewall'a wpisana reguła nie pojawiała się w /etc/iptables. Jaki jest mechanizm dodawania i analizowania reguł wpisanych w GUI Tomato? Czy wszystkie wczytują się po załadowaniu /etc/iptables i siedzą gdzieś w cache'u?

3. Czy Administration->Scripts->Firewall działa wg innych założeń niż Port Forwarding? Pytam, bo po zdefiniowaniu w GUI przekierowania portu, reguły przekierowania w /etc/iptables się znajdują w przeciwieństwie do Administration->Scripts->Firewall o czym pisałem w poprzednim punkcie.

4. Gdzie znajdują się, i w którym momencie są zaczytywane reguły dla openVPN, o których istnieniu można dowiedzieć się po wydaniu komendy
Kod Pobierz kod źródłowy  

iptables -vL


5. Pomimo usilnych starać nie udało mi się znaleźć parametru opisującego switchport routera, który można by użyć do stworzenia reguły blokującej dostęp do tunelu z poziomu fizycznego gniazda LAN w routerze i zezwolić na dostęp tylko konkretnemu MAC. Czy ktoś z Was zna jakąkolwiek możliwość stworzenia takiej reguły?
Takie było moje wstępne założenie, aby z tego poziomu zrobić filtrowanie dostępu.

6. Jeśli na powyższe pytanie odpowiedź brzmiała by NIE, to myślę, że w drugiej kolejności należało by wziąć pod uwagę br1 lub tap11 i za pomocą któregoś z nich zdefiniować regułę. Jakie byłyby różnice między nimi w tym przypadku, lub który będzie bardziej odpowiedni?

Połączony z 11 grudzień 2016 00:37:03:
Zastanawiam się, czy ktokolwiek to czyta...
Nic, spróbuję jeszcze raz.
Jeśli z łańcuchem INPUT nie było żadnych problemów i udało mi się zablokować ruch (ping) po tunelu, tak z FORWARD mam już problem. Jaką bym nie wpisał regułę w iptables, to i tak mogę pingować na wzajem maszyny po obu stronach tunelu.
W tej bezsilności starałem się usuwać i blokować wszystko co jest związane z br1 i tap11. W tym momencie wygląda to tak:

Kod Pobierz kod źródłowy  

# iptables -vL

Chain INPUT (policy DROP 2 packets, 358 bytes)

 pkts bytes target     prot opt in     out     source               destination

   15  1412 DROP       all  --  br1    any     anywhere             anywhere

    0     0 DROP       all  --  tap11  any     anywhere             anywhere

    6   244 DROP       all  --  any    any     anywhere             anywhere            state INVALID

 6365 1078K ACCEPT     all  --  any    any     anywhere             anywhere            state RELATED,ESTABLISHED

    1    40 shlimit    tcp  --  any    any     anywhere             anywhere            tcp dpt:ssh state NEW

    1    67 ACCEPT     all  --  lo     any     anywhere             anywhere

   23  2769 ACCEPT     all  --  br0    any     anywhere             anywhere



Chain FORWARD (policy DROP 0 packets, 0 bytes)

 pkts bytes target     prot opt in     out     source               destination

    0     0 DROP       all  --  tap11  br1     anywhere             anywhere

    0     0 DROP       all  --  br1    tap11   anywhere             anywhere

    0     0 DROP       all  --  any    tap11   anywhere             anywhere

    0     0 DROP       all  --  any    br1     anywhere             anywhere

    0     0 DROP       all  --  br1    any     anywhere             anywhere

    0     0 DROP       all  --  br1    br1     anywhere             anywhere

    0     0 DROP       all  --  tap11  any     anywhere             anywhere

  199 18332            all  --  any    any     anywhere             anywhere            account: network/netmask: 10.1.1.0/255.255.255.0 name: lan

    0     0            all  --  any    any     anywhere             anywhere            account: network/netmask: 192.168.126.0/255.255.255.0 name: lan1

    0     0 ACCEPT     all  --  br0    br0     anywhere             anywhere

    0     0 DROP       all  --  any    any     anywhere             anywhere            state INVALID

    0     0 TCPMSS     tcp  --  any    any     anywhere             anywhere            tcp flags:SYN,RST/SYN TCPMSS clamp to PMTU

  199 18332 ACCEPT     all  --  any    any     anywhere             anywhere            state RELATED,ESTABLISHED

    0     0 DROP       all  --  br0    br1     anywhere             anywhere

    0     0 DROP       all  --  br1    br0     anywhere             anywhere

    0     0 wanin      all  --  vlan2  any     anywhere             anywhere

    0     0 wanout     all  --  any    vlan2   anywhere             anywhere

    0     0 ACCEPT     all  --  br0    any     anywhere             anywhere



Chain OUTPUT (policy ACCEPT 369 packets, 48723 bytes)

 pkts bytes target     prot opt in     out     source               destination



Chain shlimit (1 references)

 pkts bytes target     prot opt in     out     source               destination

    1    40            all  --  any    any     anywhere             anywhere            recent: SET name: shlimit side: source

    0     0 DROP       all  --  any    any     anywhere             anywhere            recent: UPDATE seconds: 60 hit_count: 4 name: shlimit side: source



Chain wanin (1 references)

 pkts bytes target     prot opt in     out     source               destination



Chain wanout (1 references)

 pkts bytes target     prot opt in     out     source               destination

a i tak maszyny po obydwu stronach tunelu pingują się.
Co decyduje o tym, że ruch jest puszczany?
servee załączono następujące plik:
Nie masz uprawnień, by zobaczyć załączniki w tym wątku.
Edytowany przez servee dnia 11-12-2016 00:37
 
dar3k
Top  #4 Drukuj post
Dodano 11-12-2016 12:11
Nie mam na czym przetestować ale spróbuj tak może:
Kod Pobierz kod źródłowy  



iptables -I OUTPUT -o tap21 -j DROP

iptables -A OUTPUT -o tap21 -s 192.168.0.***/24 -j ACCEPT


Nie jestem pewien czy to coś pomoże ale w teorii powinno blokować cały ruch wychodzący na tap21, za wyjątkiem ruchu z podanego IP, chyba będziesz musiał tam dodać kilka IP lub ich rangę, i na DHCP routera przypisywać tak IP aby te co mają mieć dostęp zawsze miały IP z tej grupy, spróbuj. Niestety iptables nie jest moją najmocniejszą stroną.
ER-12 + 4x UAP-AC-PRO
 
servee
Top  #5 Drukuj post
Dodano 11-12-2016 14:23
Po zastosowaniu
Kod Pobierz kod źródłowy  

iptables -I OUTPUT -o tap21 -j DROP

dalej maszyny mogły się pingować po obydwu stronach tunelu. Myślę, że ta reguła by tego nie zablokowała, bo z tego co zrozumiałem zasady iptables, to łańcuch OUTPUT tyczy się ruchu wychodzącego z maszyny lokalnej.

"Wklepałem" również reguły
Kod Pobierz kod źródłowy  

iptables -F FORWARD

iptables -F OUTPUT

i nic. Następnie
Kod Pobierz kod źródłowy  

iptables -P OUTPUT DROP

iptables -P FORWARD DROP

i dalej nic... Dalej maszyny mogły się pingować wzajemnie. Testowałem pingi tak (schemat sieci poniżej):
z 192.168.1.3 [PC] pingowałem 192.168.1.51 [PC] - ping przechodził
z 192.168.1.51 [PC] pingowałem 192.168.1.2 [PC] - ping przechodził
z 10.1.1.1/br0 (ze stworzonym drugim bridge 192.168.1.202/br1) [router] pingowałem 192.168.1.3 [PC] - ping przechodził

Dopiero zastosowanie reguły
Kod Pobierz kod źródłowy  

iptables -F INPUT

odcięło cały ruch wchodzący i przechodzący przez router 10.1.1.1, no ale przez to straciłem także możliwość konfigurowania routera włącznie z GUI, więc ślepy zaułek... :/
Macie jakieś inne pomysły?

Może w tym tkwi problem:
"Od wersji Tomato v124 doszła opcja "Bridge TAP with...". Po stworzeniu nowego interfejsu LAN (w przykładzie był to br2), zaznaczamy opcję "Server is on the same subnet" i wybieramy nasz nowy interfejs LAN (br2)"
Jest to cytat z konfiguracji tunelu pod multiroom. Tak mam również zrobione u siebie, tylko że u mnie jest to br1.

Połączony z 11 grudzień 2016 19:36:28:
Ponieważ jestem samozwańczym adminem swojej prywatnej (na szczęście) sieci, to wielu zagadnień nie znam i nie rozumiem.
Poprawcie mnie jeśli się mylę, ale czy nie jest tak, że tunel TAP działa na warstwie drugiej, a iptables kieruje ruchem na warstwie trzeciej?
Wyjaśniało by to dlaczego żadne reguły nie blokowały pingu w obrębie tunelu.
A jeśli tak jest to w takim razie jak blokować MAC z tego poziomu?
servee załączono następujące plik:
Nie masz uprawnień, by zobaczyć załączniki w tym wątku.
Edytowany przez servee dnia 11-12-2016 19:36
 
dar3k
Top  #6 Drukuj post
Dodano 11-12-2016 20:42
Co do TAP to masz rację, ale jeżeli operujesz na sieci lokalnej to możesz przecież blokować ruch między danymi IP.
Jeżeli chcesz blokować w warstwie niższej to użyć musisz ebtables.
ER-12 + 4x UAP-AC-PRO
 
servee
Top  #7 Drukuj post
Dodano 12-12-2016 02:36
Nie zrozumiałem o co chodzi z blokowaniem jeśli operuję na sieci lokalnej. Czy mógłbyś mi przybliżyć zasady blokowania ruchu w takim przypadku?

Nie mniej jednak osiągnąłem zamierzony cel, ale za pomocą ebtables.
Reguły jakie wpisałem do firewall'a.

Kod Pobierz kod źródłowy  



ebtables -A FORWARD -s xx:xx:xx:xx:xx:xx -j ACCEPT

ebtables -A FORWARD -i vlan3 -j DROP

Wycina cały ruch oprócz zadeklarowanego MAC. Czy konstrukcja reguł jest poprawna, czy może powinny w swojej składni zawierać coś jeszcze?

Żeby nie było tak kolorowo, to znalazłem niewielki problem, który w sumie mi nie przeszkadza.
W konsoli reguły przedstawiają się tak:

Kod Pobierz kod źródłowy  

# ebtables -L

Bridge table: filter



Bridge chain: INPUT, entries: 0, policy: ACCEPT



Bridge chain: FORWARD, entries: 10, policy: ACCEPT

-s xx:xx:xx:xx:xx:xx -j ACCEPT

-i vlan3 -j DROP

-s xx:xx:xx:xx:xx:xx -j ACCEPT

-i vlan3 -j DROP

-s xx:xx:xx:xx:xx:xx -j ACCEPT

-i vlan3 -j DROP

-s xx:xx:xx:xx:xx:xx -j ACCEPT

-i vlan3 -j DROP

-s xx:xx:xx:xx:xx:xx -j ACCEPT

-i vlan3 -j DROP



Bridge chain: OUTPUT, entries: 0, policy: ACCEPT

Nie wiem dlaczego po restarcie routera zapisują się pięć razy.
Natomiast wydanie po kolei komend:

Kod Pobierz kod źródłowy  

# ebtables -F FORWARD

# service firewall restart

...........

Done.



# ebtables -L

Bridge table: filter



Bridge chain: INPUT, entries: 0, policy: ACCEPT



Bridge chain: FORWARD, entries: 2, policy: ACCEPT

-s xx:xx:xx:xx:xx:xx -j ACCEPT

-i vlan3 -j DROP



Bridge chain: OUTPUT, entries: 0, policy: ACCEPT

przywraca porządek.

@dar3k dzięki za pomoc.
Muszę jeszcze uporać się z bramą na co przepis podałeś mi w innym temacie, ale na razie nie miałem na to czasu.
 
Przejdź do forum
Zaloguj
Wprowadź adres e-mail lub nazwę użytkownika

Hasło



Nie masz jeszcze konta? Zarejestruj się.

Zapomniałeś/aś hasła?
Aktualnie online
· Gości online: 11

· Użytkowników online: 0

· Łącznie użytkowników: 24,117
· Najnowszy użytkownik: Ja
Czat
Musisz się zalogować, aby opublikować wiadomość.

tamtosiamto
31-03-2024 12:54
Wesolego jajka wszytskim forumowiczom Grin

tamtosiamto
28-03-2024 23:24
tak, tak zgadza sie, ale ja pytam o wykluczenie noda na guest network w first set, i to nie dziala

Adooni
24-03-2024 13:16
Guest network is currently designed to allow the first set of each band (2.4G, 5G, 5G-1) available to the AiMesh node

tamtosiamto
24-03-2024 03:03
ale w 1 jest opcja do wyboru - dla calej sieci albo rutera only i wlasnie o tym mowie, ze nie dziala

Adooni
23-03-2024 16:31
w dokumencie asusa jest ze wlasnie dla 1 ma dzialac na nodach tez

tamtosiamto
23-03-2024 15:39
tak, ale nie zmienia to faktu, ze w pierwszej nie dziala wylaczanie aimesh dla goscinnej( a powinno), czyli jest jakis bug. Mam start soft, bo to dsl-ac68 ktory nie jest juz updateowany

Adooni
22-03-2024 18:07
nie, 1 wsza bedzie wszedzie trzeba 2ga zrobic dla kazdego pasma te nie sa przenoszone

tamtosiamto
19-03-2024 19:57
czyli jak mam jedna siec goscinna to powinno dzialac separowanie gosci od noda -a nie dziala Smile

tamtosiamto
19-03-2024 19:50
@Adooni 'Only one set is available for 1 band' i tak mam-1 set dla 2.4ghz i 1 dla 5ghz-czy czegos nie rozumiemW drugiej sieci goscinnej nie ma opcji wyboru Ruter only/ All nodes

Adooni
19-03-2024 19:14
no to przeczytaj to 2 pod - 1 stet z kazdego pasma jest dopuszczony na nody. zrob 2 siec jako goscinna na danym pasmie i wtedy sprawdz
71,188,723 unikalnych wizyt
Copyright © OpenLinksys 2006-2021


Powered by PHPFusion Copyright © 2024 PHP Fusion Inc
Released as free software without warranties under GNU Affero GPL v3.