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ąć
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.
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?
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:
# 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
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
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
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:
# 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.
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ą.
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.
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ł
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.
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.
· Łącznie użytkowników: 24,115 · Najnowszy użytkownik: Ja
Czat
Musisz się zalogować, aby opublikować wiadomość.
Maniek91PL
06-11-2024 22:37
dzięki !
maxikaaz
29-10-2024 14:27
@Maniek91PL - Administration=> Admin Access, i tam masz "Allow Wireless Access" do zaznaczenia
Maniek91PL
26-10-2024 22:07
siemka! ktoś przypomni co się ustawiało jeśli nie mogę wejść od strony wifi do tomato? od lan działa
overflow2
04-10-2024 17:34
Kupowałem Asusy n10u albo n12d1 ale nie widzę ich, chyba już nie produkują, Chodzi o coś nowego i taniego. Transfery niewielkie.
maxikaaz
04-10-2024 09:38
@overflow2 patrząc po dostępności funkcji w nowych kompilacjach, to chyba nawet WRT54G/GL jeszcze ma OpenVPN, albo jakiś odpowiednik... zależy, na jakie transfery liczysz.
overflow2
30-09-2024 20:53
Jaki aktualnie najtańszy router do tomato do openvpn?
maxikaaz
27-07-2024 15:07
@servee - na początek router do rozebrania i obejrzenia, ciężko wróżyć tak tylko po objawach
maxikaaz
27-07-2024 14:55
@servee - cały kontroler nie pada tak sobie z powodu "zbiegu okoliczności", więc prawdopodobnie gdzieś przepięcie.
servee
25-07-2024 13:33
@maxikaaz: działało, aż pewnego pięknego dnia przestało działać. W tym dniu była też burza, ale to raczej zbieg okoliczności.
maxikaaz
25-07-2024 11:38
@servee - o ile problem jest w obrębie samych wyjść (dławiki, warystory), to naprawialne, ale jeśli w samym SoC - to nienaprawialne ze względu na koszta. A co było przyczyną?
' target='_blank'>Link
