Elektroda.pl
Elektroda.pl
X

Search our partners

Find the latest content on electronic components. Datasheets.com
Elektroda.pl
Please add exception to AdBlock for elektroda.pl.
If you watch the ads, you support portal and users.

MikroTik Routerboard - Kierowanie ruchem pakietów między interfejsami

15 Oct 2015 06:10 1836 4
  • Level 36  
    W celach ćwiczebnych uruchomiłem wolnego mikrotika. Skonfigurowałem 3 podsieci.

    Ether1 - DHCP client
    Ether2 - DHCP server 192.168.131.X
    Ether3 - DHCP server 192.168.133.X

    Na obu interfejsach Ether2 i Ether3 dostępny jest internet.

    Do Ether2 podłączyłem kamerę, która dostała adres 192.168.131.253

    Z poziomu komputera wpiętego do Ether3, który dostał adres 192.168.133.254
    bez problemu wbijam na panel i podgląd video kamery na interfejsie Ether2 (192.168.131.253).

    W celach ćwiczebnych z zakresu iptables wprowadziłem reguły, które z interfejsu Ether3 nie pozwolą wejść na urządzenia w sieci Ether2:

    MikroTik Routerboard - Kierowanie ruchem pakietów między interfejsami

    Działa wybornie.

    Następnie dodałem dwie reguły, które sprawiają, że z sieci Ether3 można wbić na kamerę w sieci Ether2 (i tylko na tę kamerę).
    W taki sam sposób komputerom z sieci Ether3 będę mógł w sposób kontrolowany umożliwić ruch do (i z) wybranych maszyn (np. do serwera WWW).

    MikroTik Routerboard - Kierowanie ruchem pakietów między interfejsami

    Również działa. Dostęp do kamery jest możliwy (i tylko do tej kamery).


    Teraz tak. Załóżmy, że w sieci Ether2 znajduje się urządzenie klienta. Niech ma adres 192.168.131.254.
    Ja z sieci na Ether3 (192.168.133.254) chcę mieć dostęp do wszystkich urządzeń w sieci Ether2 (panele urządzeń klienckich), ale nie chcę by jakiekolwiek urządzenie klienckie z Ether2 miało dostęp do sieci Ether3 (mojej prywatnej).

    Bym mógł mieć dostęp do paneli ruch musi iść w obie strony (ode mnie do urządzenia klienckiego, i z urządzenia klienckiego do mnie), inaczej nici z transmisji. Tylko jak to zrobić (tak wiem, raczkuję, każdy kiedyś raczkował). Jak tu zrobić, żeby urządzenie klienckie odpowiadało na moje żądanie, ale z drugiej strony, żeby klient znajdujący się za tym urządzeniem klienckim (za NAT-em) nie miał do mnie dostępu. Niby chcę, by komunikacja z urządzenia klienckiego ze mną była możliwa, tudzież niby tego nie chcę (nie chcę by klient za urządzeniem klienckim mógł nieproszony wysłać do mnie jakieś pakiety, tak samo jak nie chcę, by moja sieć Ether3 cokolwiek na te pakiety odpowiadała). I jak tu z tego wybrnąć?

    Innymi słowy, chciałbym w sieci Ether3 odbierać pakiety pochodzące od samego urządzenia klienckiego, a jednocześnie odrzucać pakiety, w które klient coś zapakował (odrzucać pakiety zza NAT, czyli pochodzące z interfejsu LAN klienta).
  • Level 43  
    new connection eth2=>eth3 DROP
    new connection eth3=>* ALLOW
  • Level 36  
    Dodam, że gdyby urządzeniem klienckim był inny Mikrotik, nie byłoby problemu. Niestety u klientów stoją AirLive 5640v2. Więc konfiguracja możliwa tylko na bazowym mikrotiku.

    Da się przyjmować pakiety od urządzenia klienckiego 192.168.131.254 (uzyskiwanie dostępu do panelu, konfiguracja urządzenia) ale jednocześnie odrzucać te pakiety, które przychodzą od tego urządzenia, ale pochodzą z interfejsu LAN klienta?

    Accept dla:
    Ether3 (ja: 192.168.133.254) <- Ether2 (WISP: 192.168.131.254)

    Deny dla:
    Ether3 (ja: 192.168.133.254) <- Ether2 (WISP WAN: 192.168.131.254) <- NAT <- (WISP LAN: 192.168.1.10)

    ?


    Da się w ogóle rozpoznać, które pakiety pochodzą "czysto" od 192.168.131.254, od tych, które wychodzą z WAN ale pochodzą z interfejsu LAN tego urządzenia ?

    Innymi słowy, czy da się rozróżnić pakiety klienta od pakietów "nie klienta" w strumieniu przychodzącym od WAN urządzenia klienckiego ?
  • Level 43  
    MES Mariusz wrote:
    Da się przyjmować pakiety od urządzenia klienckiego 192.168.131.254 (uzyskiwanie dostępu do panelu, konfiguracja urządzenia) ale jednocześnie odrzucać te pakiety, które przychodzą od tego urządzenia, ale pochodzą z interfejsu LAN klienta?


    powinno się dać ale za mało info

    wrzuć schemat, podaj IP adresy lan/wan,

    Dodano po 1 [minuty]:

    MES Mariusz wrote:
    Accept dla:
    Ether3 (ja: 192.168.133.254) <- Ether2 (WISP: 192.168.131.254)

    Deny dla:
    Ether3 (ja: 192.168.133.254) <- Ether2 (WISP WAN: 192.168.131.254) <- NAT <- (WISP LAN: 192.168.1.10)


    tak sie nie daj,
    po porcie nie dasz tego przefiltrować ? tzn dst-port=333 => accept, inaczej deny
  • Level 36  
    Wiedząc na jakim porcie pracuje urządzenie klienckie wiem, na jaki port będą szły pakiety wysyłane przeze mnie (np. próbuję dostać się do panelu). Ale bo ja wiem, na jaki port będzie wysyłana odpowiedź z urządzenia klienckiego do mnie? Tego nie jestem pewien. Pewności, że klient nie będzie chciał udawać urządzenia klienckiego i wbijać na otwarty port mojego komputera - pewności też mieć nie mogę.

    Ruch pakietów musi odbywać się w dwie strony.

    ja <===> urządzenie klienckie


    Urządzenie klienckie musi odpowiedzieć na moją próbę zalogowania się.
    Na jaki port będą szły pakiety od urządzenia klienckiego w moją stronę - tego nie jestem pewien.

    Temat jak odróżniać pakiety od klienta (i je blokować) w strumieniu jaki przychodzi od urządzenia klienckiego pozostaje zagadką.

    Jedyna opcja, w jaki sposób mogę odgrodzić się od klientów a jednocześnie zachować dostęp do paneli urządzeń klienckich jest generalnie prosty. Każde urządzenie klienckie to WISP (a więc AP client z NAT-em). Więc urządzenia klienta (to co ma po stronie LAN) są domyślnie bronione przede mną.

    Wystarczy teraz, że postawię również nat przed swoją prywatną siecią LAN. Wtedy zarówno ja jak i klienci będziemy mieli dostęp do WAN (z punktu widzenia urządzeń klienckich) a więc do wszystkich paneli urządzeń klienckich.

    Ponieważ urządzenia klienckie łączą się z jednym radiem, bardzo prosto można klientów od siebie izolować za pomocą tej funkcji:

    MikroTik Routerboard - Kierowanie ruchem pakietów między interfejsami

    Dzięki czemu, każdy z klientów będzie miał dostęp wyłącznie do WAN własnego urządzenia klienckiego. Więc teoretycznie może wbić na panel, ale tylko swojego urządzenia. Hasła i tak nie ma, ma je dostawca (ja).

    Ja natomiast ze swojego prywatnego LAN (ponieważ nie jestem połączony przez radio, więc nie jestem izolowany) mam dostęp do paneli wszystkich urządzeń klienckich.

    Więc na pewno jedną z możliwości jest podłączenie się do sieci przez NAT (czyli poniekąd) stanie się jednym z klientów.

    ja <-> NAT <-> WAN <-> NAT <-> klient

    Zaglądanie sobie do lanów pomiędzy klientem a mną nie jest w tej konfiguracji możliwe. Jesteśmy od siebie w pełni chronieni.

    Wada tego rozwiązania jest taka, że patrząc od strony internetu (mojego ISP) jestem wtedy za dwoma NAT-ami.

    Ether1 = WAN(ISP) <----> NAT1 <----> Ether2 = LAN "publiczne"

    i do tego LAN "publicznego" wpinane są urządzenia klienckie (NAT-y).

    LAN "publiczne" staje się wtedy WAN-em moim i klientów.

    ja: WAN(LAN "publiczne") <----> NAT2 <----> LAN(moje prywatne)
    klient: WAN(LAN "publiczne") <----> NAT3 <----> LAN(klienta)

    Jeśli teraz będę chciał wystawić jakąś maszynę z prywatnego lan do internetu, będę misiał ustawić dwa przekierowania portów. Jedno na urządzeniu bazowym (NAT1), drugie na moim urządzeniu klienckim (NAT2). Mało wygodne rozwiązanie.

    Między innymi z tego powodu chciałbym się izolować od klientów jakimiś sprytnymi regułkami, niekoniecznie kolejnym NAT-em (prawdopodobnie dodatkowe urządzenie sprzętowe).