- Honor Magic V5 - méret a kamera mögött
- Samsung Galaxy Z Fold7 - ezt vártuk, de…
- Samsung Galaxy A54 - türelemjáték
- Samsung Galaxy Watch (Tizen és Wear OS) ingyenes számlapok, kupon kódok
- Milyen okostelefont vegyek?
- Samsung Galaxy Watch6 Classic - tekerd!
- Samsung Galaxy S25 Ultra - titán keret, acélos teljesítmény
- Poco F3 - a mindenes, de nem mindenkinek
- Yettel topik
- Samsung Galaxy A52s 5G - jó S-tehetség
-
Mobilarena
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
-
yodee_
őstag
válasz
yodee_
#17040
üzenetére
Közben megtaláltam a "hiba" okát. Mivel pxelinux.0-át használok, így boot-oláskor ez a folyamat:
"...
As an example, if the boot file name is
/mybootdir/pxelinux.0,
the UUID is b8945908-d6a6-41a9-611d-74a6ab80b83d
the Ethernet MAC address is 88:99:AA:BB:CC:DD
and the IP address 192.0.2.91,it will try:
/mybootdir/pxelinux.cfg/b8945908-d6a6-41a9-611d-74a6ab80b83d
/mybootdir/pxelinux.cfg/01-88-99-aa-bb-cc-dd
/mybootdir/pxelinux.cfg/C000025B
/mybootdir/pxelinux.cfg/C000025
/mybootdir/pxelinux.cfg/C00002
/mybootdir/pxelinux.cfg/C0000
/mybootdir/pxelinux.cfg/C000
/mybootdir/pxelinux.cfg/C00
/mybootdir/pxelinux.cfg/C0
/mybootdir/pxelinux.cfg/C
/mybootdir/pxelinux.cfg/default... in that order... "
Szóval a logban látható hiba kód amikor UUID, és MAC alapján szeretné lehívni a konfigot. Ha készítek UUID alapú konfig fájlt akkor csak egy darab hiba jön az meg annyi hogy ERROR: CODE 0. Mivel mindent betölt, megtanulok együtt élni vele.
-
Lenry
félisten
válasz
yodee_
#16909
üzenetére
pedig érdemes.
a 13.x.x.x nem helyi hálózati IP címtartomány és ezek szabványok, nem ajánlások és nem véletlenül lettek létrehozva.
ha egy webszolgáltatás, szerver ezen a címen működik azt te most egyáltalán nem tudod elérni.amúgy meg nem akkora truváj.
tűzfalszabályokat, az Addressest, a DHCP-t és a Route-okat kell átírni és kb meg is vagy.ha nagyon biztosra akarsz menni akkor exportálod az egész konfigot, egy másolatban átírogatod az IP-ket és visszatöltöd.
-
bacus
őstag
válasz
yodee_
#16893
üzenetére
Azért vesztél el, mert fogalmad nincs mit jelent a /30.
- allowed address: 13.0.4.0/24; 13.255.255.3/30
IP -> Addresses:
13.255.255.1/30 | 13.255.255.0 | wireguard1
13.255.255.1/30 | 13.255.255.0 | wireguard2Ezt te írtad ! Ekkold már megírta, hogy két if-nek adtál azonos ip címet. Egy hiba, a másik, hogy a /30 -as hálóban 4 ip cím van, amiből az első és az utolsó NEM használható, mert az a network és broadcast address, erre te mit csinálsz? ott van feljebb, hogy 13.255.255.3/30
Ezt persze oda adod a kliensnek is !Egy /30 as hálózatban (most írjuk le neked 3x .ra) 2 db ip cím kommunikál egymással.
A te esetedben a 13.255.255.1 - 13.255.255.2 -vel tud kommunikálni. A 13.255.255.3 az az előbbi broadcast addresse. A következő /30-as háló 13.255.255.4-13.255.255.7, amiben a két ip cím ami kommunikálni tud, az a 13.255.255.5-13.255.255.6-al. Most olvasd újra az előző hsz-em, mert ott csak az utolsó számot írtam ki az ip címekhez..Ne keverd már ide a 14.x.x.x es címeket is..., inkább használd a 8.8.8.x-t
, az legalább elég hamar problémát okozna.
Erre kérdeztem, ha az összes routeren azok a címek amik 13.x.x.x -esek, lecseréled 10.x.x.x-re az akkora fájdalom? Nem értem ezt a ragaszkodást a 13-as számhoz vagy egyszerűen csak mert megteheted?
Vagy pénteken konfigoltad? -
bacus
őstag
válasz
yodee_
#16891
üzenetére
"minden működik szóval miért ne"
Teljesen igazad van. Az autód gumijait leereszted 1 barral, minden működik ugyanúgy, akkor miért ne?!/30 -as hálóban négy cím van, te használod a 0,1,2,3 -t (ugye a 2 középső a hasznos), csak találsz még ilyet 255-ig..., de azért nem egymás után lévő 4 címet kell válassz, hanem sorban... tehát jó a 4,5,6,7 jó a 8,9,10,11 és így tovább.. és nem jó 18,19,20,21
Egyébként mennyire fájna a 13-t 10-re cserélni azokban az ip címekben?
-
ekkold
Topikgazda
válasz
yodee_
#16869
üzenetére
Wireguard kapcsolat: az egyik amit használok fix IP-re csatlakozik, ez szinte soha nem szokott megszakadni. Egy másik egy NAT mögött levő eszköz, ráadásul gyakran elmegy a tápja... Erre kellett netwatch script - 5 percenként pingel, ha megszakadt a kapcsolat, akkor letiltja az interfészt, vár 3 másodpercet, majd visszakapcsolja. Ez megoldotta problémát. Itt van párhuzamosan PPTP kapcsolat is, ami stabil, csak nincs oda irányítva semmilyen adatforgalom, de szükség esetén bármikor használatba vehető.
-
ekkold
Topikgazda
válasz
yodee_
#16869
üzenetére
Am i így elsőre feltűnik, hogy miért adsz azonos címet két különböző interfésznek:???
IP -> Addresses:
13.255.255.1/30 | 13.255.255.0 | wireguard1
13.255.255.1/30 | 13.255.255.0 | wireguard2
Aztán később ez szerepel:
IP -> Addresses
- 13.255.255.2/30 | wireguard1
Egy /30-as tartományban két használható IP lehet, a szerver és a kliens címe (a maradék kettő a broadcast, és a hálózati cím).
Tehát a két interfész nem is lehetne közös tartományban, ugyanolyan IP-je meg pláne nem lehetne. Ha meg egy interfészre menne több kliens akkor nem /30-as címtartomány kellene.
Ezen kívül már páran írták neked, és most én is:
A 13 kezdetű címek nem lokális [LAN] címek, normális hálózatban nem illik ilyet használni még akkor sem, ha egyébklént működik.
Tehát vagy a leírásod hibádzik valahol, és nem fedi a tényleges beállításokat, vagy ha mégis ilyen akkor nem csoda ha nem jól működik. -
amargo
addikt
válasz
yodee_
#16776
üzenetére
Ez egy szolgáltató, azaz valamilyen olyan email címet, aminek a postaládáját eléred. Nekem gmail-es van és gmail-es céges is.
Az előre le írom, ahhoz, hogy verificálni tud majd a kilétedet, ahhoz pl kell egy domain. Nálam pl úgy van megcsinálni, hogy a céges info-s cím nevében küldöm ki innen a leveleket (ehhez persze verification kell). -
amargo
addikt
válasz
yodee_
#16774
üzenetére
Mármint? Céges adatokat kell megadni. Nekem egy account-om még azure-on keresztül van, de van egy private is, amihez végül is szintén céges adatokat adtam meg.
A sendgrid tömeges email küldésre van, nem mondom, hogy ez a legjobb megoldás erre a problémára (van pár maradi ISP (pl.: freemail), akik "blokkolják/spam-nak jelölik meg" azt pedig csak a fizetős csomagban tudod kivédeni), de én évek óta használom erre a célra is.. -
ekkold
Topikgazda
válasz
yodee_
#16747
üzenetére
Némelyik kapcsolat esetében meghagytam a PPTP vagy L2TP kapcsolatot is tartaléknak, a wireguard mellett. Egyszerűen a régi, erre vonatkozó routing szabályokat letiltottam, és felvettem újakat, amelyek már a wireguard kapcsolaton át tolják az adatokat. Így bármikor át tudok kapcsolni a régi VPN megoldás, és a wireguard között oda-vissza. A két router között pedig mindkét kapcsolat él, persze más IP címekkel - így ha az egyik kapcsolat megszakadna, a két router akkor is látja egymást.
-
ekkold
Topikgazda
válasz
yodee_
#16713
üzenetére
Szerintem, a mikrotik nem kezeli külön a fájl és a mappaneveket, vagy valójában nincsenek is mappák, csak a névben vannak per jelek. Az RB5009-en én is egy pendrájvra küldöm a backupot, és onnan megy az email. Az eredmény hasonló mint nálad... annyi eltéréssel, hogy a fájlnév per jelekkel érkezik meg a levelező programba, és a programból már kötőjelekkel lehet menteni a csatolt fájlt. Szerintem nálad is, a levelezést kezelő program cseréli le alulvonás jelre.
Még annyit, hogy azokon a routereken, ahol van /flash almappa, a gyökérkönyvtár valójában RAMdiszk, ebben az esetben nyugdodtan mehet a backup a gyökérkönyvtárba. Az email küldése után törlendő, de ez nem fogja a flash-t "koptatni". Nem emlékszem hirtelen, de mintha a hAPac2 is ilyen lenne.
-
Lenry
félisten
válasz
yodee_
#16713
üzenetére
gondolom teljes elérési úttal küldi el, tehát /disk3/backup/xxx.rsc-ként , de egy fájlnév nem tartalmazhat
/jelet, ezért lesz belőle az, ami.egyszer mintha olvastam volna valami olyasmit, hogy a Mikrotik nem kezel rendesen mappaszerkezeteket, hanem a fájlnévből csinál ilyen pszeudo-elérési utat, tehát /backup/ kezdetű fájlneveket úgy mutatja, mintha egy backup nevű mappában volnának.
de elég homályosan emlékszem erre, szóval lehet, hogy hülyeséget beszélek -
Beniii06
addikt
válasz
yodee_
#16655
üzenetére
A VPN kliensnek kellene egy IP-t adni a 4G router tartományában, pl 192.168.8.3/24 az address listben, a 4G eszköz DHCP tartományán kívül mindenképpen. Tippre Huawei eszközöd van, azok a 8.100-tól kezdik a DHCP címeket osztani általában.
A VPN szerveren pedig szerencsésebb lenne megadni a vpn kapcsolatot átjárónak, az ip cím helyett, bár elvileg ugyanaz a kettő, nekem így stabilan működik.
+ Az ip --> firewallban nézd meg, hogy van-e a NAT résznél létrehozva masquerade szabály, srcnat, a 192.168.8.0/24 re aminek kimenő interfésze a vpn kapcsolat.
-
ekkold
Topikgazda
válasz
yodee_
#16428
üzenetére
Azt hiszem a sebességen kívül (egyébként: igen, valószínűleg több is menne) elég sok további indok le lett itt írva.
Ha a fehérlistára felveszel engedélyező szabályt, akkor minden további drop-olható. Vagy akár egy sima drop szabályba is betehető kivételként a fehérlista. Több megoldás is van.
-
ekkold
Topikgazda
válasz
yodee_
#16416
üzenetére
Miért lenne értelme váltanom wireguard-ra?
- Pl. nem kellene ilyen tűzfal scriptekkel bajlódni, mint amit beraktál.
- Az egész fixportos ipsec-es megoldást ki lehetne hajítani, és akkor nem is lenne mit hackelni...
- Az l2tp/ipsec által használt portokra érkező csomagok forráscíme kapásból mehetne a feketelistára, minden különösebb trükközést mellőzve.
- Van fehérlistád: elegendő a fehérlista számára kinyitni a megfelelő portot. Az alkalmi elérésekhez meg lehetne pl. kopogtatással a fehérlistára felkerülni. (Ez mondjuk most is feleslegessé tenné a scriptes megoldást.) -
ekkold
Topikgazda
válasz
yodee_
#16413
üzenetére
Biztos, hogy érdemes azonnal tiltani? Néha látok olyat a logban, hogy egy barátom hAPac^2 routere csak másodszorra tud valamiért kapcsolódni hozzám - ilyen esetben pedig feketelistára kerülne...
Mondjuk ha majd frissít 7-es routerOs-re, akkor kihajítom az L2TP-t, és amit csak lehet wireguard-ra cserélek. -
Statikus
senior tag
válasz
yodee_
#16374
üzenetére
Én azt nem értem, mi köze a windowsnak egy BIOS által vezérelt hálózati kártyára érkező jel feldolgozásában, a gép elindításában, bootolás előtt? Szerintem semmi... De ha rosszul gondolom, ha a windows bármit is vezérel egy kikapcsolt gép indításában, akkor légyszi osszátok meg velem.
-
Lenry
félisten
válasz
yodee_
#16331
üzenetére
látszik, hogy egyetlen találat sincs arra a szabályra, mert valószínűleg rég kiértékelésre kerülnek azok a kapcsolatok, el se jut odáig a listában.
tedd valahova a lista elejére.a drop szabályokat egyébként is érdemes előre tenni, hogy mielőbb végezzen a router a kiértékeléssel és aztán ne kelljen rájuk erőforrást pazarolni.
-
Lenry
félisten
válasz
yodee_
#16108
üzenetére
1280 a WAN bridge (ezt nem is tudom állítani)
1200-ra vettem le a WG-étannyit még hozzá kell tenni, hogy külön interface-t csináltam végül ennek a kapcsolatnak, tehát most a két WireGuard kapcsolat két külön WG interface-en fut.
(nem tudom, hogy ez befolyásol-e bármit, de gondoltam leírom) -
Audience
aktív tag
válasz
yodee_
#16086
üzenetére
Én csináltam egy bridge-et hozzá raktam egy portot és összekötöttem még egy kábellel a HGW-t és a router-t, a TV-nél lévő Mikrotikre is tettem egy plus bridge-et, két portot hozzá adtam és a két bridge-et EoIP tunel-lel összekötöttem. így ha ott a megfelelő portra csatlakozom látom a HGW-t, a másik porton a set top box lóg.
-
Audience
aktív tag
válasz
yodee_
#16081
üzenetére
Nekem a Cloud szolgáltató miatt is le kellett vennem az MTU-t, Hollandiai adatközpontot használok, ebből ennyi jön ki. Néha felmegy 200Mbps-ig de az a plafon. Ha nagyobb VM-re áttenném a CHR-t lehet, hogy lehetne még faragni de amire használom arra már így is bőven jó.
-
ekkold
Topikgazda
válasz
yodee_
#15981
üzenetére
Mobilneten a szolgáltatók valamiért szeretik blokkolni a VPN-ek működését. Természetesen letagadják. Ezért jobb olyan VPN-t használni, amelyik nem fix portokat használ, hanem tetszés szerint állítható, ugyanis ezeket emiatt nehéz blokkolni... itt jön a képbe az openvpn mert az ilyen, csak éppen sokkal lassúbb mint a PPTP / L2TP / ipsec (ezek viszont csak adott porton működnek). Viszont a RouterOs7-be bekerült a wireguard, ami szintén bármelyik porton működhet, és gyors
Gyakran előfordult, hogy olyan helyen interneteztem ahonnan sem PPTP-t sem L2TP-t nem tudtam használni, és így nehezebben értem el pl. az otthoni NAS-t. A wireguard-al viszont működik. -
pzoli888
kezdő
-
ekkold
Topikgazda
válasz
yodee_
#15958
üzenetére
Nálam ehhez hasonló bejegyzés erre kell:
- Van több különféle port kifordítva, pl. egy webszerver, ami a router WAN oldaláról elérhető (skori.spacetechnology.net)
- Hogyha egy LAN címről (mondjuk asztali PC) el akarom érni a webszervert, de úgy hogy nem a belső LAN oldali címére hivatkozok, hanem pl. az előbbi domain névre - ami ugye a WAN oldali címre fordul, akkor a PC a routerhez fog fordulni a kéréssel, hiszen nem lokális címet akar elérni. A router viszont "észreveszi", hogy az a cím (is) a saját címe, és ezért az említett NAT szabály alapján, annak ellenére kiszolgálja a kérést, hogy az eredetileg a WAN oldali címre vonatkozott.
Magyarán, a LAN-on belül is kiszolgálja a NAT kéréseket. Sokak szerint ez így nem működhet, és valóban kicsit fura a dolog logikája, de a gyakorlatban viszont mégis működik a dolog. A Te esetedben, ha mégis meg akarnád tartani ezt a szabályt, akkor úgy kellene módosítani, hogy a VPN címekre ne vonatkozhasson ez a szabály, ha viszont nincs ilyesmire szükséged, akkor nyugodtan törölheted. -
ekkold
Topikgazda
válasz
yodee_
#15950
üzenetére
Nekem hAPac^2-n a PPTP VPN volt a leggyorsabb, az tudott talán 100Mbit körül, az L2TP+IPsec már jóval lassúbb volt, IPsec nélkül meg csak kicsit volt lassúbb a PPTP-nél. A wireguard gyorsabb volt mindegyiknél (nem emlékszem pontosan mekkora sebességet tudott, de biztosan többet mint 100Mbit/s). IPIP + Ipsec és az EOIP+IPsec sem volt igazán jobb sebességben a fentieknél - bár ezekkel nem túl sokat kísérleteztem. Szóval azért nem kell csodát várni ettől a kis routertől, szerintem a gyakorlatban az a 100Mbit körüli VPN sebesség reális. Ha nagyobb sebesség kell akkor vagy a PC-n kell futtatni valamilyen VPN-t, vagy jóval erősebb router kell. Gyanítom, hogy pl. a Wireguard PC-n futtatva, simán tudna közel gigabitet, de ezt nincs módom tesztelni.
-
ekkold
Topikgazda
-
ekkold
Topikgazda
válasz
yodee_
#15892
üzenetére
A közpotni routerbe vegyél fel olyan szabályt ami:
- forward action=log, a forráscím ez egyik másodlagos eszköz, a célcím a másik másodlagos eszköz. A szabályt vidd előre a sorban a drop szabályok elé.
Ebből látszani fog eljut-e a csomag a központi routerbe aminek továbbítania kellene..
-ugyanilyen szabályt vegyél fel fordított irányra is.
Ebből látszani fog eljut-e a válasz csomag a központi routerbe aminek továbbítania kellene..
Ha a szabályokat leszűkíted pl. ICMP protokollra akkor már csak pingelni kell, és nézni, hogy mit logol.A két másodlagos eszközbe pedig hasonló szabályt vehetsz fel ami nem forward, hanem input.
Ezután egy ping szépen lekövethető, hogy hol akad el. -
pzoli888
kezdő
-
ekkold
Topikgazda
válasz
yodee_
#15834
üzenetére
Azért javasoltam, mert nekem csinált olyat a 7.1, hogy hiába vettem fel a routing szabályt, az nem működött. Újraindítás után viszont magától megjavult. A 7.1.1-nél nem tapasztaltam ilyet.
Amúgy meg naplózni kellene, hogy meddig jutnak el a csomagok, akár naplózó tűzfalszabályokat felvenni erre a célra. Csak kiderül, hogy hol akad el.
-
pzoli888
kezdő
válasz
yodee_
#15815
üzenetére
lehet mind a három router tűzfal szabályaiban, ahol az action =drop és a chain= forward vagy input szerepel ott be kellene kapcsolni a log-ot (akár log prefix is legyen: külön prefix input-ra és külön prefix forward szabályra), és megint traceroute-olni a rossz irányt, majd ezek után megnézni, hogy vmilyik router logjában látsz-e vmit, és ha látsz vmilyen logot ezekkel kapcsolatban, akkor tűzfal gond lesz a hiba.
-
ekkold
Topikgazda
válasz
yodee_
#15794
üzenetére
Igen ilyesmi kellene. Gyakorlatilag 4db különböző IP tartománynak kell lennie:
- Fő router
- 1. külső router
- 2. külső router
- VPN címtartománya
(ha wireguard-al oldanád meg akkor 5db IP tartomány kellene, mert a wireguard interfészek tapasztalatom szerint nem működnek jól, ha közös IP tartományban vannak)
- Mindhárom routeren két static routing-ot kell felvenni, (a másik két eszköz felé).
- A VPN címtartományára elvileg létrejön dinamikus routing szabály (de ha nem, vagy ha nem megfelelően akkor az is kell)- A 13.0.0.0/24 IP tartományok szerintem sem célszerűek belső IP céljára.
-
-
pzoli888
kezdő
válasz
yodee_
#15791
üzenetére
a két külső router ip/routes részében fel kell venni a másik külső routernél található hálózatot és beállítani a l2tp interface-t a gatewaynek.
1. külső router:
ip route add dst-address=<a 2. külső router hálózata. pl. 192.168.12.0/24> gateway=<lt2p interface neve a főrouter felé>
2. külső router
ip route add dst-address=<az 1. külső router hálózata. pl. 192.168.33.0/24> gateway=<lt2p interface neve a főrouter felé> -
#15529
E.Kaufmann
veterán
yodee_
#15528
E.Kaufmann
veterán
válasz
yodee_
#15528
üzenetére
Úgy, hogy IPv6 esetén a szolgáltatók nem csak a routerek adnak egy IPv6 címet, hanem jobb esetben akár egy /56-os vagy /48-as tartományt (ezek továbboszthatóak több /64-es netmaszku) alhálóra, de legrosszabb esetben is kapsz egy /64-est, ami egy alhálót lefed, bár elvileg mintha ez is továbbosztható lenne, de egyes címkiosztó metódusokat ellehetetleníti és nagy macera, ha lehetséges a dolog.
Ha portforward nem is kell, de azért tűzfalat még nyitni kellhet. Valamint ami nekem egy szimpi opció, már ha a router tudja (igazából én is csak olvastam róla) a Network Prefix Translation, mikor csak a hálózat cím részt cserélik, az àllomás azonosítója (gondolom az általunk kiosztott alhálózat azonosítóval együtt) megmarad, így nem kell portszámokat jegyzetelnie a routerek belülről kezdeményezett kapcsolat áll sem, valamint a multiWAN-t is megkönnyíti. -
adika4444
addikt
válasz
yodee_
#15525
üzenetére
Perpill szerintem konkrét szükség nincs rá, én azért szeretem, mert sokszor eltérő - jellemzően kevésbé terhelt - routing útvonalakat használ, mint az IPv4.
Meg amúgy is. Ha már van, és elérhető, ki akarom használniMegoldódott amúgy, valamiért automatikusan az add-default-route ellenére kézzel kellett felvenni a route-t, azóta teljesen jó.
-
-
ekkold
Topikgazda
válasz
yodee_
#13823
üzenetére
Ha csinálsz külön profilt a PPPOE kapcsolathoz, ott is meg lehet adni scriptet, amit lefuttat, a kapcsolat felépülésekor, illetve a kapcsolat bontásakor egy másikat. Ide lehet betenni pl.
:delay 30
/system script run dyndnsupdate.rsc
Igazából ilyenkor az időzített futtatásra sincs feltétlenül szükség.Amúgy a freedns-t nagyon régóta használom, a mikrotik frissíti az IP-t, és eddig teljesen megbízható, nem kellett adott időnként bejelntkezni sem az oldalra. Ezen kívül a mikrotik IP cloud-ja is jól működik. Amíg van ingyen ilyesmi addig miért fizetnék érte.
Pl. a https://skori.spacetechnology.net/ címemre simán tudtam a szerverre ingyenes (let's encrypt) https tanusítványt is kérni, így a böngészők is biztonságosnak ítélik az oldalt, a dinamikus IP cím ellenére. -
ekkold
Topikgazda
válasz
yodee_
#13817
üzenetére
PPPOE esetén be kell tenni az OnUp scriptbe, így akkor fut le amikor felépül a PPPOE kapcsolat. Sima DHCP-s kapcsolat esetén, a DHCP kliensnél lehet hasonlóképpen scriptet betenni. A script elejébe érdemes betenni egy kis delay-t, hogy várjon amíg a kapcsolat használható lesz.
-
Lenry
félisten
válasz
yodee_
#13812
üzenetére
az intervalt leveszed 00:00:00-ra
de ekkor csak újrainduláskor fog lefutni. ha azt is szeretnéd, hogy óránként lefusson, akkor vegyél fel egy második schedule-t, ami meg óránként frissít, annak a Start Time-ja ne Startup legyen, hanem valami tetszőleges időpont
vagy használd a Mikrotik saját dyndns szolgáltatását: IP -> Cloud
-
bacus
őstag
válasz
yodee_
#13597
üzenetére
tools - netwatch
hozzáadod a figyelni kívánt ip címet, amikor él akkor up statuszban lesz, ebből következik, hogy a a down fülre megy a scriptez addig fog renew-t csinálni, amíg nem elérhető a figyelt ip, a timeout ne legyen kicsi, legyen idő helyreállni a kapcsolatnak, azaz 5-10 mp alá ne menj.
-
ekkold
Topikgazda
válasz
yodee_
#13591
üzenetére
Nem biztos, hogy elegendő a script neve.
Ha a scriptek között van tárolva akkor pl.:
/system script run dyndnsscript.rsc
vagy ha a fájl tárolóban van a script akkor pl.:
import file-name=flash/dyndnsscript.rscHa több DHCP kliens is be van állítva az eszközön akkor a nulla helyén az adott interfészre vonatkozó DHCP kliens listában elfoglalt helyének a sorszáma kell.
/ip dhcp-client renew 0Persze az is kérdés, hogy a renew egyáltalán megoldja-e a problémát. De ha kipróbálod akkor kiderül.... Elképzelhető olyan megoldás is, hogy mondjuk minden éjfélkor letiltod az ETH1 interfészt mondjuk 10 másodpercre, majd újra engedélyezed.
, az legalább elég hamar problémát okozna.
Vagy pénteken konfigoltad? 
Új hozzászólás Aktív témák
Hirdetés
ekkold- Luck Dragon: Asszociációs játék. :)
- Amlogic S905, S912 processzoros készülékek
- Telekom otthoni szolgáltatások (TV, internet, telefon)
- NVIDIA GeForce RTX 5080 / 5090 (GB203 / 202)
- sziku69: Fűzzük össze a szavakat :)
- Revolut
- Audi, Cupra, Seat, Skoda, Volkswagen topik
- Milyen asztali (teljes vagy fél-) gépet vegyek?
- Gaming notebook topik
- Filmvilág
- További aktív témák...
- Thermaltake Toughpower SFX Platinum 1000W
- Gigabyte B650M Aorus Elite AX ICE + 3 év garancia
- Sony DSC-HX300 digitális fényképező + 3 extra akksi + 8GB memóriakártya + Hama Star 700 állvány
- BESZÁMÍTÁS! LENOVO LOQ 15APH8 15 notebook - R7 7840HS 16GB DDR5 1TB SSD RTX 4060 6GB WIN11
- BESZÁMÍTÁS! ASUS TUF A15 FA507NV 15 notebook - R7 7735HS 32GB DDR5 512GB SSD 1TB SSD RTX 4060 6GB W
- ÚJ Dell Latitude 15 5550 - 15.6"FullHD IPS - Ultra 5 135U - 16GB - 512GB SSD - Win11 - 2,5+ év gari
- Asus ROG Zephyrus G14 GA401IV - 14" FHD 120Hz - Ryzen 9 - 4900HS - 16GB - 2TB - RTX 2060 - Win11
- Targus - USB-C Dual HDMI 4K HUB - 2 x HDMI (120Hz)
- BESZÁMÍTÁS! Asus Maximus VIII Hero i7 6700K 16GB DDR4 512GB SSD RX 5700 XT 8GB Zalman i3 NEO 700W
- Gamer PC-Számítógép! Csere-Beszámítás! R5 5600X / RX 7600 / 32GB DDR4 / 1TB M.2 SSD
Állásajánlatok
Cég: FOTC
Város: Budapest