Hirdetés

  2. Fórumok
  3. Hálózat, szolgáltatók
  4. Mikrotik routerek
  • Téma összefoglaló
    Utoljára frissítve: 2025-08-03 17:27

    PROHARDVER!

    Mikrotik routerekkel foglalkozó téma. Mikrotik router típusok, hardverek, router beállítások, programozás (scriptek írása), frissítés, és minden Mikrotik routerrel kapcsolatos beszélgetés helye.

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

  • #8055 adika4444 addikt
    Új Válasz #8055
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    adika4444

    addikt

    Hali!

    A korábbi NAT fordítgatásra:

    Nos, én nem szeretek külső elem(ek)től függni, márpedig ez a MikroTik DDNS tipikusan ilyen, nem nálam fut, nem én felügyelem, szóval nem egy főnyeremény véleményem szerint.

    Az alapötletet tehát kissé átdolgoztam, íme.

    Ekold leírása alapján felvettem az alábbi szabályt, és a tényleges portátirányítást:

    add action=masquerade chain=srcnat dst-address=192.168.0.0/16 src-address=192.168.43.0/24 comment="required to use the public IP in LAN same as WAN"
    add action=dst-nat chain=dstnat dst-address-list=wan dst-port=1194 protocol=udp to-addresses=192.168.43.6 comment="openvpn"

    Utána létrehoztam a /ip firewall address-list helyen a WAN listát, egy elemmel, ami a publikus WAN címem.

    Na ehhez csináltam egy olyat, hogy PPPoE on_up esetén lefuttat egy szkriptet, ami a PPPoE interfész címével felülírja a korábbi WAN címet az address_list esetében. Így gyakorlatilag ha van net, nincs olyan eset, hogy ne működne a szabály belső hálóról WAN címre.

    Ha kiadok egy /interface pppoe-client majd disable 0 enable 0 sort, az ekvivalens a PPPoE szakadással? Az a baj, hogy a 168 óra leteltével nem leszek a router közelében, tehát ha meggárgyul, elég nehezen tudom helyrerakni, szóval valahogy kéne tesztelni. DIGI a szolgáltatóm.

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