Hirdetés

Új hozzászólás Aktív témák

  • csusza`

    senior tag

    Kezdem full hülyének érezni magam az egész témához.
    Most a másik problémámtól elvonatkoztatva (subnetek közti portnyitás) - megoldódott végre a ddns kérdés, Telekom hibabejelentőnél kapcsoltak egy technikus, aki közölte, hogy márpedig én nem vagyok NAT-olt hálózaton, de azért lefuttat egy újabb valamilyen-akármilyen tesztet... Utána érdekes mód jó lett. Ja, és még kioktatott azzal kapcsolatban is, hogy nem érti, hogy mi a gondom a ddns-el, az csak az IP-met fordítja be egy webcímre... Nem érti, hogy mi köze van az ő rendszerüknek ehhez. Mindegy is, mission completed, van DDNS.
    Na mondom, hogyha már egyszer van ebben egy csomó lehetőség, megcsinálom már magamnak is itthonra a mindenféle tuti eléréseket, VNC, VPN, FTP stb. Másnak már megy, kicsit elidőzök a saját rendszeremmel is, arra úgysincs soha időm. Aha, ja.
    Leakadtunk már a VNC portforwardolásnál, a következő dologgal: megcsinálom gyönyörűségessen', a dst-nat-ot, mivel PPPoE kapcsolatom van, emígy néz ki:

    chain=dstnat action=dst-nat to-addresses=192.168.1.101 to-ports=5900
    protocol=tcp in-interface=pppoe dst-port=55101 log=no log-prefix=""

    Oké, melóhelyre beVNC, onnan DDNS-en keresztül (és a Mikrotik Cloudon keresztül is) próba... Hát ez sajnos nem megy így... Oké, Google a barátom - csináljak tűzfalszabályt, ami a pppoe interface-n a new kapcsolatokat beforwardolja... Oké. Volt egy szép kis tűzfaltáblám - legalábbis egészen eddig azt gondoltam, hogy ez így jó. Ez a következőképp nézett ki:

    [admin@MikroTik] /ip firewall filter> print
    Flags: X - disabled, I - invalid, D - dynamic
    0 ;;; drop in invalid
    chain=input action=drop connection-state=invalid log=no log-prefix=""

    1 ;;; accept in new local
    chain=input action=accept connection-state=new in-interface=br-lanwlan
    log=no log-prefix=""

    2 ;;; accept in established
    chain=input action=accept connection-state=established log=no
    log-prefix=""

    3 ;;; accept in related
    chain=input action=accept connection-state=related log=no log-prefix=""

    4 ;;; accept in icmp
    chain=input action=accept protocol=icmp log=no log-prefix=""

    5 ;;; accept in winbox
    chain=input action=accept protocol=tcp dst-port=8291 log=no
    log-prefix="winbox"

    6 ;;; accept in webfig telnet local
    chain=input action=accept protocol=tcp in-interface=br-lanwlan
    dst-port=7080,23 log=no log-prefix=""

    7 ;;; drop in all
    chain=input action=drop log=no log-prefix="FW-drop"

    8 ;;; drop forward invalid
    chain=forward action=drop connection-state=invalid log=no log-prefix=""

    9 ;;; accept forward new local
    chain=forward action=accept connection-state=new in-interface=br-lanwlan
    log=no log-prefix=""

    10 ;;; accept forward established
    chain=forward action=accept connection-state=established log=no
    log-prefix=""

    11 ;;; accept forward related
    chain=forward action=accept connection-state=related log=no log-prefix=""

    12 ;;; drop forward all
    chain=forward action=drop log=no log-prefix=""

    Ehhez gondoltam hozzáadni a forward szakaszhoz az alábbi szabályt:

    ;;; VNC
    chain=forward action=accept connection-state=new protocol=tcp
    in-interface=pppoe dst-port=55101 log=no log-prefix=""

    Ez így ebben a formában még mindig nem ment, a dst-portot kiszedve egyből életre kelt.
    Na, most akkor erősítsetek meg: ha a portot kiszedem és úgy használom, az azt jelenti, hogy az új kapcsolatokat a pppoe interfészen keresztül simán beforwardolja, ergo semmi értelme az azt megelőző, egyébként tökéletesen működő forward szabályoknak, mert így gyakorlatilag mindent beenged.
    A másik gondom ezzel az, hogyha van mondjuk a hálózatban 100 gép, amit VNC-znem kéne, akkor mindegyikhez vegyek fel tűzfalszabályt (ha a portot meg akarom adni)?!

    Nemrég óta foglalkozom a Mikrotikkel, és azt hittem, vannak már olyan területek, amit megfelelően tudok kezelni, de mindig van valami, amibe belefutok...

Új hozzászólás Aktív témák