-
Fototrend
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
-
DjTomboy
csendes tag
válasz
Beniii06 #8088 üzenetére
MTU-ra egy ilyen van beállítva:
Most néztem a Sagem-ben 1492-re van állítva az MTU.
Próbáltam ezzel-enélkül de sehogy sem volt jó.
A csomagomban 1 Gbit/s letöltési, 1 Gbit/s feltöltési sebesség van.. Ez majdnem mindig meg is van a Sagem-mel. A házban összesen két lakásba van bekötve Telekom net, így ketten osztozunk az 1,25 Gbps-on.
Ha Speedtest-et csinálok, akkor mindig több különböző szerverrel szoktam mérni egymás után és a feladatkezelőben nézem a hálózati csati sebességet. Rakok majd fel képeket, csak most nem tudok mérni.
-
E.Kaufmann
veterán
Ez nem valami MTU vagy clam tcp to mss gond? Lehet darabolja feltöltésnél a csomagokat, ahelyett, hogy ICMP-n utasítaná a klienseket kisebb csomagméretre.
-
adika4444
addikt
válasz
vargalex #8094 üzenetére
DIGI gigás neten jelenleg is jön a 800/300. Szóval legalább 300-at bírnia kell neki.
Érdekes mindenesetre a hiba, nagyon meglepődnék, ha tényleg az lenne, hogy MAC alapján korlátozgatnak. De ugye a MAC-t a MikroTik-be lehet klónozni, a Sagem meg asszem kiírja a WAN fizikai címet. -
vargalex
félisten
válasz
adika4444 #8093 üzenetére
Ez csak egy ötlet volt. De akár userenként más módszert is használhat a Telekom... Csak ugye gyanús az a 200 Mbps. Én megnézném egy másik routerrel is (nem a SagemCom-al). Kétlem, hogy a hAP ac² csak 200 Mbps-t tudna felfelé irányban, miközben lefelé tudja a gigabitet.
-
adika4444
addikt
válasz
vargalex #8090 üzenetére
Nem csinál ilyet a Telekom. Beköttettük az 1000/200-at, amit még aznap felrakattunk giga/gigára. Először sagemen ment az 1000/200, utána a saját AC66U-n. Felváltás után az AC66U-n egy PPPoE reconnect után ment az új sebesség. Próbaképp megnéztem, a Sagemen is. Visszaraktam az ASUS-ra, és azóta is tökéletesen megy.
Egy hAP ac^2-re akarom cserélni majd, oda is vágna, ha nem vinné a giga/giga csomagot.
DjTomboy: Egy gépet köss rá a Sagem-re közvetlen, és azon csinálj PPPoE-t. Ha nem is hajtja ki a gigát, de ha már 200 fölé megy a felfelé irány, akkor lehet következtetni...
-
vargalex
félisten
válasz
jerry311 #8089 üzenetére
Pedig igaza van a kollégának, pont úgy viselkedik, mintha 1000/200-as csomag lenne beállítva. El tudom képzelni, hogy a PPPoE kapcsolatot felépítő eszköz MAC címe alapján más limiteket állítanak be. Esetleg nem pont ugyan ez a PPPoE usernév a SagemCom-ban, bár erre gondolom figyelt a kolléga.
-
Beniii06
addikt
válasz
DjTomboy #8084 üzenetére
Milyen csomagban vagy? Mert ha jól emlékszem a régebbi 1000-es csomag nem volt szimmetrikus és az a pontosan 200 Mbps központi korlátnak tűnik vagy leterhelt környék miatt lehet. Azért jó lett volna kb. pár speedtest eredményt is csatolni 3 különböző időpontban(reggel, délben,este) különböző magyar szerverekre(Telekom, antenna hun, stb.) és itt nem a speedtest eredmény a lényeg(sokat win10 appra esküsznek), hanem hogy elindítod a speedtestet és screenshotolod az interface listát!
PPPoE-nél MTU 1480 legyen!
-
uno20001
csendes újonc
válasz
DjTomboy #8084 üzenetére
Ha tényleg nem jó a dupla NAT, akkor esetleg csak simán AP-nak konfigurálhatnád a Mikrotiket. Tehát a Sagemcom ONT osztaná mindenkinek az IP-t DHCP segítségével, a hAP ac^2 pedig csak access point-ként működne. (Ez valóban nem oldja meg a PPPoE problémát a Mikrotiken, de kompromisszumos megoldásnak jó lehet.)
-
DjTomboy
csendes tag
Sziasztok!
Nemrég vettem egy Mikrotik hAP ac^2-t. Telekomos optikai internetem van.
Ha úgy állítom be, hogy a Sagemcom ONT csinálja a PPPoE kapcsolatot és a mikrotik a wan-nak beállított portján dhcp kliensként kap ip-t, akkor a mikrotikra kötött eszközökön rendben van az internet sebessége (~900 Mbit le, 980 Mbit fel). De ez így nekem nem jó, így dupla NAT-olás van...
Ha a mikrotik csinálja a PPPoE kapcsolatot, akkor a letöltési sebesség rendben van, viszont a feltöltési sebesség csak 200 Mbit.
Mit állítok be rosszul? Az alábbi képeken láthatóak a jelenlegi PPPoE-s beállításaim. Lereseteltem a routert úgy, hogy ne legyen alapból beállítva semmi, utána állítottam be ezeket. (a képek készítésekor nem volt bedugva a hálókábel, amin keresztül meg a pppoe kapcsolat). -
_kovi_
aktív tag
Sziasztok!
Tudtok adni útmutatót, hogy milyen szabályok ajánlatos a tűzfalnál és a nat-nál létrehozni?
MikroTik hAP ac2Köszi!
-
#42556672
törölt tag
-
ekkold
Topikgazda
válasz
adika4444 #8059 üzenetére
Valóban lehet erre scriptet is írni, de igazából amikor erre szükség van, akkor úgyis éppen otthon vagy, hiszen bentről kell elérned a külső címed.
Ha nem bízol a dyndns-ben arra is vannak jó megoldások, nekem pl. az a másodlagos megoldásom, hogy a weblapomon van egy PHP, aminek a router időnként elküldi néhány adatát. Így ha a dyndns nem működne, a weblapomon akkor is meg tudom nézni, hogy mi a routerem IP címe, mikor jelentkezett utoljára erről a címről a router, és mi a dyndns neve. Ez a PHP több router adatait is tudja fogadni, és szépen összerakja egy táblázatba az adatokat. -
adika4444
addikt
Igen, elvileg meg lehet oldani. Odáig már eljutottam, hogy ha 100-zal kezdődik az IP, akkor NAT, ha nem, akkor nem NAT. Csak ugye a NAT tartománya a 100.64.0.0/10 ami annyit tesz, hogy 100.64.0.0 és 100.127.255.255 közti lehet az IP. Tehát ha 100-zal kezdődik, akkor meg kell vizsgálni a második blokkot, és ha az >= 64 és <= 127, na akkor van NAT. A DIGI-nek elvileg nincsen publikus IP-je ami 100-zal kezdődik, tehát elméletileg elég a cím elejének vizsgálata, de igazából ha már lúd, legyen kövér alapon érdemes ellenőrizni ezt is.
-
adika4444
addikt
válasz
Gyurka6 #8061 üzenetére
No itt akkor egyben mindenkinek:
A WAN cím arra kell, hogy a routeren belül ne kelljen DDNS. Duckdns-t használok a home serveremen, az teljességgel kielégíti az igényeimet.
No de akkor jöjjön a gyakorlati rész.
A linkelt szkript hát bizonybizony hibás, a delay-jel kellett játszani, meg a parancsok sorrendjével. Így sem elegáns, mert ellenőrízhetné, hogy tényleg van-e kapcsolat mielőtt v6-ot kér, de jó ez most. A másik probléma, hogy bár a lease 00:10:00-ra van téve, még is valami bődület magasat oszt ki mindig a v6-os DHCP szerver, ami rohadtul nem kerek abban a formájában.
Na tehát akkor az én beállításaim. Lan tartományom 192.168.43.0/24, ether1 a bejövő portom.
#Beallitjuk a PPPoE-t (akinek be van, az csak set-tel lojje be a service name-t digi-re)
/interface pppoe-client
add add-default-route=yes disabled=no interface=ether1 keepalive-timeout=\
disabled name=pppoe-digi password=<ppp-login-pass> service-name=digi \
use-peer-dns=yes user=<mindenkinek_a_sajatja>
#Meghivjuk a szkriptemet, ami a PPPoE ujracsatlakozasnal ujrainditja az IPv6-ot, ill. a WAN cimlistat is beallitja.
/ppp profile
set *0 on-up=pppoe-digi-reconnect
#Felveszunk egy cimet, hogy legyen mit modositani a kov. ujracsatnal, amikor is a 0.0.0.0 a realis WAN cimunkre fog cserelodni
/ip firewall address-list
add address=0.0.0.0 list=wan
#Ekkold leirasaban volt, nelkule is mukodik a net, de ha mar van hat miert ne legyen beallitva
/ip firewall mangle
add action=change-mss chain=forward comment="PPPoE MTU" new-mss=1440 \
out-interface=pppoe-digi passthrough=yes protocol=tcp tcp-flags=syn \
tcp-mss=!0-1440
#NAT beallitasa, a masodik szabaly a kulso cim belso hasznalathoz kell
/ip firewall nat
add action=masquerade chain=srcnat out-interface=pppoe-digi src-address=\
192.168.43.0/24
add action=masquerade chain=srcnat dst-address=192.168.0.0/16 src-address=\
192.168.43.0/24
#IPv6
/ipv6 address
add address=::1 from-pool=digi interface=br-lan
/ipv6 dhcp-client
add add-default-route=yes interface=pppoe-digi pool-name=digi request=\
address,prefix
/ipv6 nd
add advertise-dns=yes interface=pppoe-digi ra-lifetime=none
/ipv6 route
add distance=1 gateway=pppoe-digi
#IPv6-os DHCP szerver. Lathato, hogy a lease 10 perc, csak ezt ignoralja a rendszer a gyakorlatban.
/ipv6 dhcp-server
add address-pool=digi interface=br-lan lease-time=10m name=dhcp-digi6
#vegul a szkript
/system script
add dont-require-permissions=no name=pppoe-digi-reconnect owner=admin policy=\
read,write,policy,test,sniff,sensitive,romon source=":execute {/ipv6 pool \
remove digi}\
\n:execute {/ipv6 dhcp-client disable [find interface=pppoe-digi]}\
\n \
\n:delay 3\
\n:execute {/ipv6 dhcp-client enable [find interface=pppoe-digi]}\
\n:delay 3\
\n:execute {/ipv6 dhcp-server disable [find name=dhcp-digi6]}\
\n:execute {/ipv6 dhcp-server enable [find name=dhcp-digi6]}\
\n\
\n:global ipaddress [/ip address get [find interface=\"pppoe-digi\"] addre\
ss ];\
\n:for i from=( [:len \$ipaddress] - 1) to=0 do={ \
\n\t:if ( [:pick \$ipaddress \$i] = \"/\") do={ \
\n\t\t:global newipaddress [:pick \$ipaddress 0 \$i]\
\n\t} \
\n}\
\n:execute {/ip firewall address-list set [find list=\"wan\"] address=\$ne\
wipaddress}"Egy kézi PPP reconect után pedig örömmel jelentem, hogy szépen az új prefixet osztogatja a v6-os DHCP szerver és frissült a címem a tűzfalon
Ami még fontos, hogy mivel a PPPoE interfész címét használja, ezért ha benatol a DIGI, akkor a NAT-olt cím lesz a listán (100.64.0.0/10)
Nem vagyok egy nagy mágus a témában, szerda óta MikroTik-ezek, szóval ha valami nem elég precíz, akkor javítsatok!
-
m0ski
aktív tag
DDNS problémára szerintem megoldás lehet, ha egy ingyenes (de 30 naponta levélben megerősítős) címet CNAME-el ráirányít a Mikrotik Cloud címére. Így nem kell megjegyezni a bonyolult címet, és fixen működik.
Van hozzá frissítős script, amit be lehet rakni pppoe on up-ra, és amikor megújul a cím, frissít NO-IP felé, de ha kell még e-mailben is elküldi az új IP-t.
-
adika4444
addikt
Köszi az ötletet, de a PPPoE miatt kérdéses az egész. Lehet marad a fapados módszer, kihúzom a kábelt aztán visszadugom
(#8058) Lenry:
Félreérthetőre sikeredett. Tehát a cél az annyi, hogy a szkript minden köztes megoldás nélkül nyerje ki a WAN címemet. Én már használok DDNS-t az eléréshez, csak a cél az, hogy ahol nem kell, ott ne használja, így ha például leáll, annak nincs kihatása a router ezen részére. -
válasz
adika4444 #8055 üzenetére
ez mind szuper, de ha nem vagy otthon, akkor honnan tudod hogy mi az új IP címed, és még fontosabb, hogy pl a böngésződ honnan tudja?
mert nyilván azért kell a hairpin NAT, hogy bentről is elérj valamilyen, alapvetően kintről elérhető szolgáltatást...
a DDNS erre megoldás, míg a szkripted - ha jól értem a működését - nem -
m0ski
aktív tag
Sziasztok!
Én ez alapján csináltam annak idején a Hairpin NAT-ot, és tökéletesen működik mindenféle address list piszkálás nélkül, DIGI-vel.
Egy NO-IP DDNS ugyan fel van húzva, de ez a működés szempontjából indifferens.Kiragadott részlet, de pl. a Transmission kliens sora így néz ki + masquerade:
/ip firewall nat
add action=masquerade chain=srcnat out-interface=pppoe-DIGI
add action=masquerade chain=srcnat comment="Hairpin NAT" dst-address=\
!192.168.0.1 src-address=192.168.0.0/24
add action=dst-nat chain=dstnat comment="Zyxel NAS" dst-address=\
!192.168.0.0/24 dst-address-type=local dst-port=\
51515 protocol=tcp to-addresses=192.168.0.2 -
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.
-
Kindar
tag
Jogos a felvetés, ennyi információval nem sok mindent lehet kezdeni. Mea culpa. Ámbár úgy fest rájöttem a hiba okára. Én voltam az.
valószínűleg véletlenül töröltem a szeparált wifi scrnat profilját. A fő hálózatnak címeire meg volt, de ennek nem. Létrehoztam és így már megy.
Köszönöm szépen a segítséget még egyszer!
-
ekkold
Topikgazda
válasz
vargalex #8052 üzenetére
Azért 192.168.0.0./16 mert nem csak 192.168.9.x hálózatom van (bár az az elsődleges), így viszont univerzális, mert minden 192.168. kezdetű célcímre működni fog. Tehát ha monmdjuk a 192.168.10.10 címen is fut egy szolgáltatás, amit a oruter forwardol, akkor azt is el lehet érni a 192.168.9.x hálózatból a külső IP-re hivatkozva.
-
vargalex
félisten
-
vargalex
félisten
Csak egy kérdés: ebben az esetben a használt hostname feloldása nem az address list-hez adáskor történik meg? Azaz valóban dinamikus WAN IP cím esetén (nem DHCP WAN kapcsolat) nem fog frissülni, ahhoz szerintem egy script is kellene, ami frissiti a hozzá tartozó IP-t.
-
-
ekkold
Topikgazda
válasz
Crowley #8041 üzenetére
Nagy vonalakban: mindkét szabad portnak amiket összekötsz, adsz egy-egy IP címet, (ami egyik LAN tartományában sincs benne), pl. 10.10.10.1/24 és 10.10.1.2/24. A routerekbe felveszel egy-egy routing szabályt ami a másik router LAN tartományának eléréséhez az ETH túlvégén levő IP rendeli gatewayként. Ekkor a két IP hálózat átjárható lesz, azaz látni fogják egymást a két hálózatban levő eszközök. Ezután megfelelő tűzfal szabályokkal beállítod, hogy ki és mihez férhet hozzá...
-
Crowley
csendes tag
Sziasztok!
Adott két hálózat más IP tartománnyal és saját internettel 1-1 mikrotik eszközön
Az egyik hálózaton van egy nyomatót és meg szeretném oldani, hogy erre a másik hálózatból is lehessen nyomtatni. Mindkettőn van szabad interface, gondoltam ezen összekötöm őket.
Ebben kérnék segítséget.
Köszönöm! -
ekkold
Topikgazda
válasz
jerry311 #8035 üzenetére
Alaphelyzetben ha olyan NAT szabályt (vagy akár tűzfal szabályt) akarsz létrehozni amiben a WAN oldali IP cím is szerepel, akkor azt az IP címet bele kellene írni a szabályba. Csakhogy ez az IP időnként változik, én viszont valamiért nem szeretném minden IP változáskor átírogatni a NAT szabályt
. Erre persze könnyedén lehetne írni mondjuk egy scriptet ami megteszi helyettem.
De... itt jön a képbe a dyndns, és az IP cím listák. IP listára fel lehet tenni domain neveket is, és a hozzájuk tartozó IP automatikusan frissül a listában. Tehát ha létrehozok egy wan elnevezésű IP listát, a router dyndns nevével, akkor az mindig az aktuális wan oldali IP-t fogja tartalmazni. IP listára pedig bármely NAT vagy tűzfal szabály tud hivatkozni, bármilyen script megírása nélkül is. Viszont ahhoz, hogy ez így működjön kell a dyndns, amit amúgy is használok másra, tehát adja magát a dolog.
Mint írtam van többféle más megoldás is, de ez így elég egyszerű, és jól is működik. -
Kindar
tag
Nálam van egy NAS, amin megy a Transmission és DLNA szerver. A transmissiont elértem külső és belső címről is. Amit nem bírtam felfogni, hogy miért nem érem el a gépre telepített Teamspeak szervert a gépről külső címmel. Belső címet megadva ment. Mondjuk azt nem próbáltam, hogy amikor a géppel próbáltam elérni külső címmel a gépen lévő szervert és nem működött, akkor ha külső hálózatról próbáltam volna ment volna e.
Egyébként tuti ennyi volt csak a baja, hogy ez a szabály kellett bele, ugyanis ahogy írtam addig tökéletesen működött ameddig a szolgáltató eszköze is routolt a mikrotik felett, de ahogy az át lett állítva AP módba onnantól halt meg minden. -
-
jerry311
nagyúr
Láma kérdés, de mi köze a címfordításnak a DDNS-hez?
-
ekkold
Topikgazda
válasz
adika4444 #8032 üzenetére
Rossz a kérdés, mert a gyakorlatban "forward szabály" = "kifordítás", egyetlen kivétel ha a mikrotik belső LAN címére forwardolsz, de akkor meg működni fog minden egyéb nélkül... tehát a korábbi forward szabály maga a kifordítás, csak nem a wan porthoz van rendelve a bejövő port, hanem a wan IP címhez. A forwardolás meg mindenképpen kell ha egy eszközt kívülről el akarsz érni - itt csak az a különbség, hogy nem mindegy hogyan..
A saját eddigi tapasztalatom szerint "a MikroTik féle DDNS" megbízhatóan működik.
Amúgy megoldható ddns nélkül is, (sokféle működőképes megoldás létezik) csak éppen így a legegyszerűbb szerintem.
-
adika4444
addikt
Olyat lehet DDNS nélkül, hogy mint egy sima ASUS, TP esetében elérjem a belül lévő eszközöket külső IP alapján? Tehát ne kelljen minden forward szabállyal eljátszani a kifordítást. Most tűnt fel, hogy külső címmel nekem sem megy a belső cuccok elérése, Telenor mobilneten minden jó. Az IPv6 miatt eddig fel sem tűnt, csak most, hogy IPv4 alapján próbálkozok
szerk: Ez a MikroTik féle DDNS mennyire jó a gyakorlatban? Hallottam olyasmit, hogy megbízhatatlan picit...
-
ekkold
Topikgazda
Na ez így sok lehet részekre szabdalva, foglaljuk össze:
# Mikrotik dyndns bekapcsolása
/ip cloud
set ddns-enabled=yes update-time=no
# wan oldali IP cím felrakása egy listára
# a dyndns név kimásolható az /ip cloud menüből
/ip firewall address-list
add address=gyariszam.sn.mynetname.net list=wan
# a szükséges portok kifordítása a külső ip címre
# itt nyilván több sor is lehet, a szükséges portoktól függően
/ip firewall nat
add action=dst-nat chain=dstnat comment="NAS DSM HTTPS kifordit" dst-address-list=wan dst-port=5000-5001 protocol=tcp to-addresses=192.168.9.120 to-ports=5000-5001
#ez csak ahoz kell hogy bentről is elérhetők legyenek a kifordított portok, a külső IP-re hivatkozva
/ip firewall nat
add action=masquerade chain=srcnat dst-address=192.168.0.0/16 src-address=192.168.9.0/24Így átlátható, ill. megérthető, hogy mi és miért van?
Annyi még furcsa lehet (de attól még működik) hogy az utolsó sor két LAN cím között NAT-ol, pedig egy külső IP-re hivatkozunk, de a mikrotik "észreveszi" hogy az a külső cím is a saját címe, és ezért működni fog a NAT-olás. -
ekkold
Topikgazda
Tehát a NAS elérése kintről:
/ip firewall nat
add action=dst-nat chain=dstnat comment="NAS DSM HTTPS kiford\EDt\E1sa" dst-address-list=wan dst-port=5000-5001 protocol=tcp to-addresses=192.168.9.120 to-ports=5000-5001A dst-addres-list esetében pedig a WAN oldalí címem benne van egy IP listában, valahogy így:
/ip firewall address-list
add address=9xxxxxxxxx2.sn.mynetname.net list=wan
Persze ehez be kell kapcoslni az ip cloud-ot.Ez kiegészítve a korábbival elérhetővé teszi kintről és bentről is a szervert.
-
ekkold
Topikgazda
Nekem egy NAS van a hálózatomon, ahhoz elég ennyi, hogy a belső hálóból, a külső IP-n elérjem.
Viszont, ez csak akkor megy, ha kintről amúgy egyébként elérhető az eszköz. Továbbá ha az eszközhöz való portfordítás (dst-nat) nincs leszűkítve a WAN portra, vagy ha a belső IP-re is van felvéve dst-nat.
Persze más lehetőség is van ami hasonló eredményt ad, pl. IP listát kell felvenni, és a listán levő címekre alkalmazni a dst-nat -ot, de ez az adott helyi hálózat felépítésétől is függ.
-
Kindar
tag
Amit a videó második felében csinál, akkor gyakorlatilag felesleges? Nekem ugye az volt a gondom, hogy TS szerverre nem tudtam csatlakozni külső címmel, azt ez oldotta meg. Próbáltam minden lépés után, hogy jó e már, de csak onnantól működött, hogy mindent megcsináltam ami a videóban is van
-
-
-
adika4444
addikt
válasz
adika4444 #8018 üzenetére
Nem tudom már szerkeszteni az előzőt
A két felső sor cseréje - elvileg - megoldotta, de most már nem csinálok újabb PPPoE reconnectet, a szkript futtatása látszólag remekül megy. Élesben majd holnap rápróbálok.szerk: Megadtam 0d 00:10:00-t a lease time-nek a DHCPv6 szervernél, de nem izgul rá, továbbra is magas a lejárati idő a Linuxos gépen.
-
Kindar
tag
Sziasztok,
Segítsetek kérlek, küzdök mint disznó a jégen már 3 napja.
Digi net (pppoe, nincs NAT-olva az IP-m ) - mikrotik router - TS3 szerver PC-n.
NAT beállítás a routerben:
ugyanezzel a beállítással csak értelem szerűen más portokkal és más belső IP-vel a transmission megy, külső hálózatról elérem. Az eszközök fix IP-n vannak LAN-on.
Az internet szerintem összes fellelhető variációját kipróbáltam már erre a problémára, de csak nem akar összejönni. Belső hálózaton lehet csatlakozni a TS szerverre.
Eddig a DIGI eszköze is router módban ment, de amióta átállíttattam AP-ra, azóta szenvedek, hogy újra beüzemeljem a TS szervert.
Elvesztem, nincs több ötletem, hogy hol lehet a hiba. -
ekkold
Topikgazda
válasz
adika4444 #8014 üzenetére
Nálam jelenleg 64nap 2óra az uptime, és 151348 a total write. Ez arányaiban kb. ugyanannyi mint nálad.
A backup amúgy FTP-vel is megy, ha van szervered, akkor pikk-pakk feltölti rá. A mikrotik a saját filesystemében nem biztos hogy szerencsés sokat írogatni. Az újabb tipusoknál /flash mappa megy a "diszkre" a gyökérkönyvtár a RAM-ban van (tehát trölődik ujrainduláskor), ha pendrájvot is bedugsz, akkor az a /disk1 mappában lesz elérhető (legalábbis az én routeremen így van). Ha helyi mentést akarsz csinálni, akkor célszerű valamilyen háttértárat kötni az USB-re, és arra írogatni. -
adika4444
addikt
válasz
bambano #8009 üzenetére
Windows-om van, OpenSSH-val. Megnézem, mit tudok tenni, hogy ide írja, de lehet, első körben az eszköz diszkjére rakom.
(#8010) ekkold:
Ezt a remek leírást használtam a router konfigjához - köszi, hogy elkészítetted!
A konfigmentős részt valamiért beállításnál átsiklottam, de ez lesz az! SMB-vel fogom lehúzni, a mail-lal nem akarok jelenleg szórakozni.Mennyire problémás, ha 1 nap uptime alatt 2500-nál jár a write-sect-total?
-
bambano
titán
"Ugye azért kezdtek anno dinamikus IP címeket kiosztani mert kevés az ipv4 cím.": nem. azért lett privát címtartomány meg a nat, mert kevés az ip cím. a dinamikus kiosztás ettől független történet. azért osztják dinamikus protokollon az ip címet, hogy címcsere esetén ne kelljen végigmenni többezer user gépén és átállítani.
a címcsere pedig azért van, hogy ne üzemeltess otthon szervert.
-
ekkold
Topikgazda
válasz
Watercolour #8000 üzenetére
".... IPv6 esetén nem szokás NAT-olni, éppen az a lényege, hogy tengernyi cím van, minden eszköznek lehet és lesz is publikus IPv6 címe. Azért kapsz a Digitől egy teljes /64 prefixet, hogy bőven jusson minden eszközödnek saját publikus IPv6 cím.
Ezért érdemes figyelni arra, hogy a routereden állíts be értelmes IPv6 tűzfalszabályokat, hiszen közvetlenül az internetről elérhetőek lesznek a gépeid. ...."
Ezzel kapcsolatban nem értek valamit. Ugye azért kezdtek anno dinamikus IP címeket kiosztani mert kevés az ipv4 cím. Oké, de ha ipv6 címből van bőven, akkor azt mi a fenének kell gyakran cserélgetni?? Ha a LAN minden eszköze kap publikus címet, akkor azért az elég nagy biztonsági kockázat is egyben, tehát jó tűzfal kell. De ha a LAN eszközök címe is állandóan változik akkor valamilyen névhozzárendelés alapján is lehet kezelni a tűzfalban az eszközöket? Vagy olyan tűzfalszabályok kellenek amik mondjuk MAC address alapján dolgoznak? (ilyesmit mintha tudna a mikrotik !?) -
ekkold
Topikgazda
válasz
adika4444 #8007 üzenetére
export file=mentesfileneve.rsc
/tool e-mail set address=smtp.smtpszerverneve.hu from=Mikrotik<feladómailcime@domain.hu> password=smtp-password user=smtp-username
/tool e-mail send to=cimzett@digikabel.hu subject="Backup $filename" \
body="Mikrotik backup\r\n" \
file="mentesfileneve.rsc"
Amúgy ITT írtam erről is kicsit bővebben, esetleg olvasd el. -
adika4444
addikt
válasz
Watercolour #8005 üzenetére
Köszi, ki fogom próbálni!
Felmerült közben egy újabb kérdésem. Ahol van export parancs, ott ugye SSH-n ki tudom íratni a parancsokat, amivel elérhetem az adott állapotot.
Hogy tudom ezt fájlba írni amit aztán lementek?"Ez inkább megkerülésnek mint megoldásnak tűnik nekem, bár az előző scriptet beállítva látszólag működik a dolog."
Mekkora bérleti idővel végül?"Ha van olyan tűzfalszabályod, amibe hardcode-oltál címeket, akkor valószínűleg igen."
Azt szeretném, hogy alapvetően csak a related,established kapcsolatok menjenek át, és csak egy eszközre lehessen kívülről új kapcsolatot nyitni (home server). Ide már esélyesen kelleni fog ez, meg a cím vége, amit kioszt az adott gépnek a router. -
Watercolour
aktív tag
válasz
adika4444 #8004 üzenetére
"Asszem a PPPoE csatlakozásnál lehet szkriptet futtatni..."
Valóban, ezzel a scripttel sikerült is megoldani az új prefix kérést PPPoE csatlakozáskor, persze az interfész és a pool nevét átírtam a sajátomra, illetve a delayt csökkentettem 3-ra."Ebben nincs semmi extra. A lease-t be kell állítani 600 secre (10 m azaz 10 perc), nekem a régi routerrel ennyi volt."
Ez inkább megkerülésnek mint megoldásnak tűnik nekem, bár az előző scriptet beállítva látszólag működik a dolog."IPv6-hoz is kell a fasttrack beállítása az extra sebességért?"
Kellene, de a RouterOS jelenleg nem támogatja az IPv6 fasttracket. Ha komolyabb sebességgel forgalmazok IPv6-on adatot, kicsit meg is ugrik a routerem CPU-ja:"Egyébként akkor már ugye a tűzfalat is frissíteni kell ha jön új prefix, bár ez talán ha az előző kettő megoldódik, simán össze lehet kötni."
Ha van olyan tűzfalszabályod, amibe hardcode-oltál címeket, akkor valószínűleg igen.(#8001) Gyurka6
Köszi a linket, hasznos volt! -
adika4444
addikt
válasz
Watercolour #8000 üzenetére
Köszi!
"- PPPoE reconnectkor kérjen új prefixet, ezt valószínűleg halál egyszerű megoldani, csak még nem foglalkoztam vele"
Asszem a PPPoE csatlakozásnál lehet szkriptet futtatni...
"- Új prefix kérése esetén valahogyan értesíteni és erőltetni a klienseket (saját gépeim), hogy ők is kérjenek új címet, mert jelenleg ha 7 naponta szakít a Digi, vagy nyomok egy kézi PPPoE reconnectet, a gépek nem tudnak IPv6-on kommunikálni, mert másik prefixet oszt ki a digi... Nyilván nagyon rövid lease time-mal meg lehetne oldani, de ez elég szar megoldásnak hangzik."
Ebben nincs semmi extra. A lease-t be kell állítani 600 secre (10 m azaz 10 perc), nekem a régi routerrel ennyi volt.
"IPv6 esetén nem szokás NAT-olni, éppen az a lényege, hogy tengernyi cím van, minden eszköznek lehet és lesz is publikus IPv6 címe. Azért kapsz a Digitől egy teljes /64 prefixet, hogy bőven jusson minden eszközödnek saját publikus IPv6 cím.
Ezért érdemes figyelni arra, hogy a routereden állíts be értelmes IPv6 tűzfalszabályokat, hiszen közvetlenül az internetről elérhetőek lesznek a gépeid."
IPv6-hoz is kell a fasttrack beállítása az extra sebességért? Egyébként akkor már ugye a tűzfalat is frissíteni kell ha jön új prefix, bár ez talán ha az előző kettő megoldódik, simán össze lehet kötni.(#8003) Watercolour:
Ha jutsz valamire, feltétlen számolj majd be róla, működőképesre kalapálnám én is. -
-
E.Kaufmann
veterán
válasz
Watercolour #8000 üzenetére
IPv6 esetén nem szokás NAT-olni csak éppen ahogy a Pista bácsi az antiszemitizmussal: igény volna rá
még ha simán a tűzfalazáshoz nem is kell, valamint a Prefix Translationnak nincs is olyan mellékhatása, mint az IPv4 esetén elterjedt NAT-NAPT megoldásnak.
Mondjuk gondolom a SIP-RTP ugyanúgy nem örül ha megbolygatják a prefix-et, mintha az egész címet változtatnák, de pl szolgáltatói támogatás nélkül multi WAN-hoz nem ártana valamilyen NAT megoldás, pláne ha terhelésmegosztást is szeretnénk.
Más kérdés, hogy a ROS 6 nem hogy NAT-olni nem tud IPv6 alatt, de ha jól rémlik a csomagokat se bírja jelölni. -
Gyurka6
őstag
válasz
Watercolour #8000 üzenetére
[Itt] nézd meg.
Új hozzászólás Aktív témák
- Teljes verziós játékok letöltése ingyen
- Mobil flották
- Epson nyomtatók
- Path of Exile (ARPG)
- Kazy Computers - Fehérvár - Megbízható?
- Yettel topik
- AMD Ryzen 9 / 7 / 5 7***(X) "Zen 4" (AM5)
- AMD Ryzen 9 / 7 / 5 9***(X) "Zen 5" (AM5)
- Diablo 3
- PROHARDVER! feedback: bugok, problémák, ötletek
- További aktív témák...
- RTX 4080 SUPER,16GB. Ryzen 7 7800X3D, 32 RAM Fury RGB! Garancia!
- Asztali PC , i7 9700K , RX 5700 XT , 32GB DDR4 , 500GB NVME , 1TB HDD
- Dell Inspiron 5406 2-in-1i5-1135G7 16GB DDR4 3200 512GB NVME 14" FHD Érintőkijelző W11Pro
- Eladó MacBook Pro 14" M1 Pro (2021) 16/512 99% akku Makulátlan állapotban!
- Újszeru GIGABYTE G5 - 15.6" FullHD 144Hz - i7-13620H - 48GB - 1TB - RTX 4050 - Win11 - 1,5 év gari
- Bomba ár! MacBook PRO 13" 2020 4TB3 - i5 I 16GB I 512SSD I OS X Sequoia I Cam I Gari!
- AKCIÓ! Gigabyte H610M i5 13600K 16GB DDR4 512GB SSD RTX 3060Ti 8GB Zalman S2 TG Seasonic 650W
- Samsung Galaxy A23 5G 128GB, Kártyafüggetlen, 1 Év Garanciával
- DELL Universal Dock D6000 dokkolók, RTX Legion Pro laptopok 4 év Lenovo garanciával, licencek
- Telefon felvásárlás!! Honor 90 Lite/Honor 90/Honor Magic5 Lite/Honor Magic6 Lite/Honor Magic5 Pro
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: PC Trade Systems Kft.
Város: Szeged