Fórumok
Sziasztok!
Mit kell beállítani, hogy pl. a 192.168.1.1-es címről be lehessen SSH-zni a routerbe?
LAN porton megy az SSH, a 192.168.1.1-et meg tudom pinget.
Csináltam tűzfal szabályt, ami az input-ban a legelső szabály és csak TCP+22-es port van beállítva accept-re, de nem
mozdul a számláló és nem megy az SSH.
Köszönöm!
Hozzászólások
Ismerni kellene az aktuális konfigot, mert pár helyen el tud csúszni a dolog.
Az IP/Firewall-os részt már megcsináltad. (Gondolom nem korlátoztál interfészre.)
Az IP/Services alatt az ssh-nál nincs lekorlátozva? (Available From)
És végül: a Mikrotik-ed milyen IP-t kap WAN oldalról? Ha 100.64.0.0/10-et (CGNAT), akkor kell egy telefon az ügyfélszolgálatnak, hogy publikus IP-t szeretnél.
Csináltam először erősen korlátozós FW szabályt, de most csak TCP/22 és accept az input-ra.
Az /IP/Services-t nem piszkáltam.
Tkom 2 PPPoE kapcsolatot ad, de nem ez volt a cél, hanem hogy a home gateway 192.168.1.1-ét (és pár másik teszt eszközt) elérjek, ill.
onnan lehessen SSH-zni. Tehát még nem lépnék ki a Netre sem!
A MikroTik-em kap valós IPv4-et és IPv6-ot is a pppoe-out1 interfészén.
Üdv:
Ruzsi
Most kavartál csak meg, tényleg látni kellene, hogy mit mivel és hogyan dugdostál össze, melyik interfészen milyen IP címek vannak.
Ez a home gateway a T eszköze? Vagy milyen eszközt értünk alatta?
MikroTik port 1 (ether1) -> Home gateway port1
Pi eth0 -> Home gateway port2
TP-Link AP WAN interész -> Home gateway port3
A Pi a 192.168.1.64-et kapja a HG-től DHCP-n.
A TP-Link a 192.168.1.65-öt szintén DHCP-n.
A MikroTik a 192.168.1.66-ot DHCP-n az ether1-én (port 1).
Üdv:
Ruzsi
Ha csak helyi hálóról akarsz belépni egyelőre, akkor csak az első két lépés kell: a tűzfalasat már megcsináltad, illetve a Services-nél lehet, hogy én bedobnék egy 192.168.1.0/24-et az "Available From"-hoz. Ezek után mondjuk a Pi-ről a 192.168.1.66-ra ssh-zva mennie kellene.
Defaultban nem figyel az SSH minden interfészén?
És így fog figyelni a LAN portján, ami a 192.168.8.0/24-ben van? Vagy akkor már külön azt is ki kell írni neki?
Üdv:
Ruzsi
Miért figyelne? Illetve attól függ... Például egy factory reset után kérhetsz bele default konfigot, de kérheted teljesen üresre is.
Kérdésedre visszatérve: Igen, minden olyan IP-t vagy tartományt meg kell itt adnod, ahonnan be akarod engedni az SSH-t a Mikrotik-re. Ha ez üres, akkor bárhonnan elfogadja az SSH-t, ha a tűzfal nem tiltja. De best practice, ha a nem használt szolgáltatásokat itt kikapcsolod és a bekapcsoltak elérhetőségét korlátozod.
Emellé a netmask se ártana, mert kétlem ugyan hogy /32-tőt kap, de nehogy ezen bukjon el.
192.168.1.0/24 a HG LAN oldala.
Üdv:
Ruzsi
Ha a 192.168.1.1 a HGW, akkor miért az a cél, hogy erről be lehessen SSH-zni a MT-be? Merthogy a HGW-ből tuti nem tudsz SSH-zni, mert annak nincs CLI-je...
Ha a HGW-re kötött többi eszközről akarsz SSH-zni a MT-re, akkor a tűzfal szabályban azoknak az IP címét vagy azt a komplett tartományt engedd be, ne a HGW címét...
Nem az 1.1.-ről akarok bemenni.
Kezdet bőven elég lenne pl. a 192.168.1.64 is, ami egy Pi.
De arról se akart. Alapvetően sehonnan, ami nem a LAN.
Ha kikapcsolom azt a default szabályt, ami mindent tilt a !LAN interfészről, akkor megy.
Az engedő szabályt felhúztam ez elé, de nem hatotta meg.
Üdv:
Ruzsi
Akkor rosszul îrtad meg a szabályt…
Bizony az meglehet:
#1 accept input 6(tcp) 22
és nincs letiltva.
Üdv:
Ruzsi
Ha ez router, akkor az eth1 nincs benne alapból a bridge-ben és a LAN csoportban sem. Nem lehet ez a gond?
p00t
Ez router.
Az ether1 csatlakozik a WAN-hoz. (dobozon is az a külön jelölt port, az 1-es)
Nincs benne a bridge-ben.
A bridge felől megy az SSH.
Sajnos nem tudom, mi lehet a gond.
Üdv:
Ruzsi
Végső kétségbeesésemben a tcpdumpot szoktam elővenni, MikroTik-en ez looking glass. Pl. hogy amikor megy, akkor honnét, hová. IP, IF, mifene.
Ez alapvetően nagyszerű ötlet, de a MikroTik-en, ahogy te is írtad, nem tcpdump van, hanem valami más és jelenleg nagyon nem értek még hozzá!
Kb. <1 hete van nálam a dobozka és ebből se tudtam vele nagyon sokat foglalkozni, így nem tudom, hogyan kell vele csomagokat nézegetni.
Látom, hogy nagyon sokat tud, nagyon tetszik a RouterOS, de egy magam fajta OpenWRT/Linuxosnak erősen pilóta vizsgás.
Eddig az IPv6-tal próbálkoztam, több-kevesebb sikerrel és működni látszik, de csak olyan "kimásolom-bemásolom" konfigurálással, aza nem igazán értem a mit-miért összefüggéseket, de azért nem alap hálózatba tettem, hogy lehessen jóóóó nagyokat szívni vele. :-)
Üdv:
Ruzsi
Az alap dolgok ugyanazok, mint az OpenWRT-ben. (Max. az elrendezés más.)
Oké, de mégse akar menni.
Majd idővel ...
Üdv:
Ruzsi
Nyomtam egy factory resetet az egyik kézközelben lévő Mikrotiken (7.x), csak a default konfigot kértem rá. Beállítottam ugyanazt a tűzfalszabályt, mint te (tcp/22) az input chain elejére. És ennyi, más nem kellett hozzá.
Csak egy ötlet: próbáld meg factory reset után. (A jelenlegi konfigot ki tudod dumpolni szöveges formátumban.)
Ötlet jó, de most, hogy valamennyire összekalapáltam a hálót és az IPv6 is menni látszik úgy, ahogy én akarom (semmi különös egyébként), nem bántanám ilyen durván.
Nekem csak 6.4x-es verzióm van.
Gyanítom, hogy nem ez lehet a baj és el tudom érni az MT-t más útvonalon (pl. most már IPv6-on is), így majd ha lesz újból indíttatásom, megpróbálom, mit rontok el, illetve, ha már tudni fogom, hogy "tcpdumpozzak" rajta. Mert gyanús, hogy el sem jut a túzfalig a csomag.
Próbáltam logoltatni az FW-t, de elég gyorsan elszaladnak a sorok, nagy a forgalom a WAN oldalon és mivel még nem tudok szűrni (se) a sniffer-rel, vagy mivel, így nem vagyok közelebb.
Egyébként is is úgy gondolnám, hogy az FW 1. szabálya esetén - ha egyéb trükk nincs - akkor engednie kellett volna az SSH kapcsolatot.
Üdv:
Ruzsi
Annak nem kéne gondot okoznia, hogy 6-os vagy 7-es. (Bár lehet, hogy érdemes megcsinálni a frissítést.)
Ez mit mond, ha terminalban vagy ssh-n kiadod?
/ip/firewall/filter/print chain=input
a looking glass helyett a torch szót kerested
Az! Tényleg.
Írnátok egy használható példát indulásnak pl. egy SSH csomag "tcpdumpolásához"? Pl. adott host-ról.
Köszi!
Üdv:
Ruzsi
Első tippre az interface list alatt fel kellene vinned az eth1-et mint LAN interface mert van olyan default tűzfal szabály ami eldob mindent ami nem a LAN-ról érkezik.
Nem jó, mert nem a LAN tartományomban van!
A LAN az a 192.168.8.0/24-ben. Ezért van kivéve a bridge-ből, bár ezen nem változtattam. Az ether1 a WAN tartományban van default-ban,
ha jól tudom, de majd a hozzáértők kijavítanak.
Ugye az 1-es port a WAN, a 2-5 a LAN-ban. Én ezt még szétszedtem és talán a 3-as egy különbe tettem, de ez most nem számíthatna!
Üdv:
Ruzsi
Akkor viszont a szabályban engedni kell a WAN felől az SSH-t és a második tipp a masquerade kikapcsolása (ugye a WAN fele mindent NAT-ol)
de lehet egyszerűbb lenne ha adsz egy config export
A masquerade itt nála nem játszik, ha jól értem. Elvileg a Mikrotik WAN-ja 192.168.1.0/24-en van és onnan szeretné elérni a 22-es portot a Mikrotiken. És ha jól értem, akkor a Mikrotik LAN oldalról (192.168.8.0/24) eléri SSH-n.
Igen, így van.
Megvagyok nélküle, csak mostmár érdekelne a megoldás ...
Üdv:
Ruzsi
Az egész konfig helyett valami relevánsabb rész nem lenne elég?
Üdv:
Ruzsi
Ez egy egészen rossz ötlet...
Inkább olyan szabályt kell felvinnie, ami explicit engedélyez az "internet" felől dolgokat (és tiltott minden más, ami nem engedélyezett).
Amennyiben felveszi a LAN alá az internet oldali interfészt, akkor később ezzel jól megszivathatja magát biztonság terén, ha elfelejti, hogy a LAN az valójában nem csak a lan, hanem az egész internet is egyben...
Nem feltétlen rossz ötlet, feltéve ha tudod, hogy mit csinálsz. :-) Nálam van olyan eszköz, ahol mind az 5 port LAN-ban van. De a fordítottja is előfordul: 2 port WAN-ban.
Lehet banálisat kérdezek, de "dst port 22" a szabály?
Ha a tiltó szabály előtt van, és jó, akkor a tiltó szabályig nem jut el a csomag vizsgálata. Amennyiben eljut, akkor az általad írt szabály nem illeszkedik rá, ergo nem jó a szabályban valami.
Legalább a tűzfal szabályok input chain-re vonatkozó részét másold be ide (/ip firewall filter export; és ebből az input chain sorai). Elég nehéz úgy segíteni, hogy előbb ki kell barkóbáznunk, most mi van az eszköz konfigjában...
Teljesen igazad van:
/ip firewall filter
add action=accept chain=input connection-limit=100,0 dst-port=22 protocol=tcp
add action=accept chain=input comment=\
"defconf: accept established,related,untracked" connection-state=\
established,related,untracked
add action=drop chain=input comment="defconf: drop invalid" connection-state=\
invalid
add action=accept chain=input comment="defconf: accept ICMP" protocol=icmp
add action=accept chain=input comment=\
"defconf: accept to local loopback (for CAPsMAN)" dst-address=127.0.0.1
add action=drop chain=input comment="defconf: drop all not coming from LAN" \
in-interface-list=!LAN
add action=accept chain=forward comment="defconf: accept in ipsec policy" \
ipsec-policy=in,ipsec
add action=accept chain=forward comment="defconf: accept out ipsec policy" \
ipsec-policy=out,ipsec
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" \
connection-state=established,related
add action=accept chain=forward comment=\
"defconf: accept established,related, untracked" connection-state=\
established,related,untracked
add action=drop chain=forward comment="defconf: drop invalid" \
connection-state=invalid
add action=drop chain=forward comment=\
"defconf: drop all from WAN not DSTNATed" connection-nat-state=!dstnat \
connection-state=new in-interface-list=WAN
add action=accept chain=input dst-port=22 protocol=tcp
/ip firewall nat
add action=masquerade chain=srcnat comment="defconf: masquerade" \
ipsec-policy=out,none out-interface-list=WAN
Üdv:
Ruzsi
Én elsőre kivenném a connection-limit kitételt (pláne, hogy ennek az alkamazását hivatalosan szűkíteni kellene még) mert csak bezavar a debug-ba, és megnézném, hogy az /ip services alatt engedélyezett-e az SSH, a 22-es porton van-e és nincs-e IP tartomány limit a szolgáltatáson.
Egyébkét ennek a szabálynak működnie kellene (még a connection-limit mellett is). Ha nem fut rá csomag, akkor azok a csomagok vagy nem érnek el a MT-ig, vagy a MT-en nincs a 22/tcp-n semmi szolgáltatás.
Azt mondja, hogy:
Ua. subnetben vannak. Az eszközök a HG (home gateway) LAN portjáta kapcsolódnak, onnan kapnak IP-t a 192.168.1.0/24-es tartományból. (HG osztja)
Route lehet ludas, de kicsi az esélye, lévén ua. subnetben vannak.
SSH fut, mert az MT LAN portjáról (lábairól, portjairól) el tudom érni SSH-n.
[rattila@DHMTr] /ip service> print
Flags: X - disabled, I - invalid
# NAME PORT ADDRESS CERTIFICATE
0 telnet 23
1 ftp 21
2 www 80
3 ssh 22
4 XI www-ssl 443 none
5 api 8728
6 winbox 8291
7 api-ssl 8729 none
Üdv:
Ruzsi
[rattila@DHMTr] /ip> address print
Flags: X - disabled, I - invalid, D - dynamic
# ADDRESS NETWORK INTERFACE
0 ;;; DHlan
192.168.8.1/24 192.168.8.0 bridge
1 D 192.168.1.66/24 192.168.1.0 ether1
2 D <my-IP>/32 <provider-net-IP> pppoe-out1
Üdv:
Ruzsi
Ebből tudsz adni print detail-t? De amúgy kellene az interface list, az ip firewall filter, az ip firewall nat és az ip route, mert így eléggé vakon van mindenki
Összeszedem hamarosan.
Üdv:
Ruzsi
[rattila@DHMTr] /interface> print
Flags: D - dynamic, X - disabled, R - running, S - slave
# NAME TYPE ACTUAL-MTU L2MTU MAX-L2MTU MAC-ADDRESS
0 R ether1 ether 1500 1596 2026
1 RS ether2 ether 1500 1596 2026
2 ether3 ether 1500 1596 2026
3 RS ether4 ether 1500 1596 2026
4 RS ether5 ether 1500 1596 2026
5 R ;;; defconf
bridge bridge 1500 1596
6 R pppoe-out1 pppoe-out 1480
[rattila@DHMTr] /interface>
[rattila@DHMTr] /ip firewall filter> print
Flags: X - disabled, I - invalid, D - dynamic
0 D ;;; special dummy rule to show fasttrack counters
chain=forward action=passthrough
1 chain=input action=accept connection-limit=100,0 protocol=tcp dst-port=22 log=no log-prefix=""
2 ;;; defconf: accept established,related,untracked
chain=input action=accept connection-state=established,related,untracked
3 ;;; defconf: drop invalid
chain=input action=drop connection-state=invalid
4 ;;; defconf: accept ICMP
5 ;;; defconf: accept to local loopback (for CAPsMAN)
chain=input action=accept dst-address=127.0.0.1
6 ;;; defconf: drop all not coming from LAN
chain=input action=drop in-interface-list=!LAN log=no log-prefix=""
7 ;;; defconf: accept in ipsec policy
chain=forward action=accept ipsec-policy=in,ipsec
8 ;;; defconf: accept out ipsec policy
chain=forward action=accept ipsec-policy=out,ipsec
9 ;;; defconf: fasttrack
chain=forward action=fasttrack-connection connection-state=established,related
10 ;;; defconf: accept established,related, untracked
chain=forward action=accept connection-state=established,related,untracked
11 ;;; defconf: drop invalid
chain=forward action=drop connection-state=invalid
12 ;;; defconf: drop all from WAN not DSTNATed
chain=forward action=drop connection-state=new connection-nat-state=!dstnat in-interface-list=WAN
13 chain=input action=accept protocol=tcp dst-port=22 log=no log-prefix=""
[rattila@DHMTr] /ip firewall filter>
[rattila@DHMTr] /ip firewall nat> print
Flags: X - disabled, I - invalid, D - dynamic
0 ;;; defconf: masquerade
chain=srcnat action=masquerade out-interface-list=WAN ipsec-policy=out,none
[rattila@DHMTr] /ip firewall nat>
[rattila@DHMTr] /ip route> print
Flags: X - disabled, A - active, D - dynamic, C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme, B - blackhole, U - unreachable, P - prohibit
# DST-ADDRESS PREF-SRC GATEWAY DISTANCE
0 ADS 0.0.0.0/0 pppoe-out1 1
1 DS 0.0.0.0/0 192.168.1.1 1
2 ADC <pub_IP1>/32 <pub_IP2> pppoe-out1 0
3 ADC 192.168.1.0/24 192.168.1.66 ether1 0
4 ADC 192.168.8.0/24 192.168.8.1 bridge 0
Üdv:
Ruzsi
Egykérdés:
Hogyan lehet pl. egy route bejegyzés egyszerre dynamic és static? (DS fentebb a 192.168.1.1-en)
Üdv:
Ruzsi
Ha jól értem, akkor a HGW-n be van kapcsolva a PPPoE passthrough, és a MT épít magának PPPoE linket az internet felé az ether1-en (ez utóbbi csak tipp, de mi máson építene).
Ezen felül a HGW-től kap DHCP-vel címet szintén az ether1-en, amin az ominózus SSH elérésnek működnie kellene a HGW-re kötött többi eszköz felől.
Namost azt nem tudom, hogy a HGW annak ellenére, hogy ad címet a PPPoE-t használó MT-nek, ténylegesen hajlandó-e ebben a konfigurációban IP alapú forgalmat oda küldeni a többi portról vagy nem. Érdemes lenne elsőre úgy tesztelni, hogy nincs PPPoE passthroung és nincs PPPoE kliens a MT-en. Ha új viszont jó, akkor ez a HGW korlátja.
Azt meg nem értem, hogy miért kell a HGW-re kötni a többi saját berendezésedet, ha ott az MT, közvetlen internet eléréssel? A HGW-t vagy passthrough-ban vagy router-ként használja általában mindenki. Akkor szokták meghagyni a HGW-n is a PPPoE kapcsolódást (a passthrough mellett) és közvetlen rádugni valamit, ha az IPTV boxokat nem sikerül életre kelteni a saját router mögött, és emiatt azokat közvetlen a HGW-re kötik.
Jól érted.
Igen, így van.
Ha a Pi-ről tudom pingetni az MT és vica-verza, az azt jelenti, hogy működik a switch a HG-ben? ;-)
IPTV nincs.
Játék a 2. PPPoE sessionnal, ha már engedi a T! ;-)
Amolyan mentő kötél, ha elrontom az első session eszközét.
(Megsúgom, hogy a LAN portokon is van ilyen tartalék összeköttetés, bár most éppen nem használom, de fel tudom konfigurálni, ha mégis szükség lenne rá.)
Szóval miért nem tudok beSSH-zni az MT-be a Pi-ről, ha megy a ping kettőjük között? (... és tegyük fel, hogy a HG nem partizánkodik bele a kapcsolatba. Elég sok galádságra képes ez a Sagem, de ezt nem tapasztaltam a LAN lábai között. :-D
Üdv:
Ruzsi
Fordítsd meg! Próbálj a MT-ről SSH-zni a Pi-re... Akkor kizárod a MT nagyjából minden korlátozó lehetőségét (hacsak nem tettél az output chain-re szabályokat).
Ha a Pi-re sem ér el a MT-ről az SSH (Pi-n tcpdump-pal kényelmesen tudod nézni), akkor valami mégiscsak lesz a HGW-vel. Ha a MT->Pi viszonylatban működik az SSH, akkor meg csak a MT-en fogja meg valami (ez esetben nem tudom mi, mert a tűzfal szabályod jó).
De nekem rettentő fura, hogy a tűzfal szabályra nem fut rá a csomag. Ha ténylegesen internet felől próbálod a publikus címen (a PPPoE kapcsolaton keresztül) az SSH-t, az működik? Ezzel a szabállyal onnan is be kellene engedjen.
Megy az MT -> Pi SSH!
[rattila@DHMTr] /system> ssh 192.168.1.64
password:
Linux opk-mh 5.10.103-v7+ #1529 SMP Tue Mar 8 12:21:37 GMT 2022 armv7l
...
Last login: Sun Feb 18 21:18:10 2024 from 192.168.1.66
Wi-Fi is currently blocked by rfkill.
Use raspi-config to set the country before use.
rattila@opk-mh:~ $
Üdv:
Ruzsi
Interface list kellene (https://help.mikrotik.com/docs/display/ROS/Interface+Lists), nem a sima interface + a bridge config is. De az már most gyanús hogy 2 default route van…
A 2 default ellenére azért még a bejövő csomag csak fennakadhatna a firewall szűrőn, nem?
Mert a számláló a TCP/22-nél fixen 0,0.
És ha a ping megy, akkor a dupla default se lehet olyan nagy baj, szerintem.
De este valamikor külsöm a többi konfig kivonatot és újra megnézem, hogy biztosan megy-e a ping mindkettőből.
És +1: ha jól emlékszem, van explicit route a 192.168.1.0/24-re, ami arra az ether1-re van, ahol a Pi és a HG van....
Üdv:
Ruzsi
Szerintem nem jut el a kapcsolat a Mikrotikig de rendkívül fura ez a setup. A gép ahonnan kapcsolódni próbálsz a HGW-n keresztül az milyen hálózaton van?
A gép - Pi - a HGW másik LAN portján figyel.
Ha jól tudom 4+1 LAN portja van a HGW-nek: 4 sárga (1Gbps) és 1 kék (2,5Gbps).
A sárgákba van dugva a Pi, az MT és egy routerAP WAN portok (Pi - eth0, MT - ether1, AP - eth0).
A routerAP jelenleg nem routol, csak van IP-je a 192.168.1.0/24-ből, egyébként a br-lan egyik portja megy az MT bridge egyik portjára, tehát tényleg AP már csak.
Én pedig a notebook-ommal az AP-re csatlakozom WiFi-vel.
Időnként a GCP-n futó felhős gépről próbálok bejönni a PPPoE interfészen ...
Üdv:
Ruzsi
[rattila@DHMTr] /interface list> print
Flags: * - builtin, D - dynamic
# NAME INCLUDE EXCLUDE
0 * ;;; contains all interfaces
all
1 * ;;; contains no interfaces
none
2 * ;;; contains dynamic interfaces
dynamic
3 * ;;; contains static interfaces
static
4 ;;; defconf
WAN
5 ;;; defconf
LAN
[rattila@DHMTr] /interface list>
[rattila@DHMTr] /interface bridge> print
Flags: X - disabled, R - running
0 R ;;; defconf
name="bridge" mtu=auto actual-mtu=1500 l2mtu=1596 arp=enabled
arp-timeout=auto mac-address=78:9A:18:3C:7B:4A protocol-mode=rstp
fast-forward=yes igmp-snooping=no auto-mac=no
admin-mac=78:9A:18:3C:7B:4A ageing-time=5m priority=0x8000
max-message-age=20s forward-delay=15s transmit-hold-count=6
vlan-filtering=no dhcp-snooping=no
[rattila@DHMTr] /interface bridge>
[rattila@DHMTr] /interface> print
Flags: D - dynamic, X - disabled, R - running, S - slave
# NAME TYPE ACTUAL-MTU L2MTU
0 R ether1 ether 1500 1596
1 RS ether2 ether 1500 1596
2 ether3 ether 1500 1596
3 RS ether4 ether 1500 1596
4 RS ether5 ether 1500 1596
5 R ;;; defconf
bridge bridge 1500 1596
6 R pppoe-out1 pppoe-out 1480
[rattila@DHMTr] /interface>
Üdv:
Ruzsi
Nem voltam gep elott, sry, interface list member es interface bridge port kellene (es ha lehet akkor print detail, nem sima print). A pppoe-out az ether1-en van ugye?
De amugy a legjobb a /export lenne (ha kell akkor az ip/mac cimeket kicserelheted benne, a jelszavakat meg nem is rakja bele csak ha megadod a show-sensitive parametert).
A homegw ping teszt mukodott?
A pppoe-out1 az ether1-en van, igen.
A HG ping megy.
A mellékelt konfig kimenet kevés?
Üdv:
Ruzsi
Igen sajnos. Eleve printeket adtál print detail helyett és egy csomó olyan terület van ahol ez lyukra tud futni és nehéz mindet felsorolni. De amúgy ha remote elérés a cél akkor lehet jobban jársz ha frissítesz 7-re mert azon pont most csináltak egy ilyet: https://help.mikrotik.com/docs/display/ROS/Back+To+Home
Hát tudtam én, hogy van ilyen, hogy print detail??? :)
Kezdő vagyok, ezért nem rohanok frissíteni se, bár van már 1-2-3 olyan jellemző, ami akár hiányozhat is (pl. WireGuard és amit most küldtél, bár még nem olvastam)
De az interfészek tekintetében semmi különös, kivéve, hogy az ether3-at kivettem a bridge-ből.
Azért se rohanok az új verzióval, mert nem szeretek tesztelni a cégeknek. Sokat csináltam, sokat szívtam, így mostmár inkább biztonsági játékos vagyok.
A másik: szeretném látni, hogy az IPv6-tal sokkal jobban elbír, mint a most leváltás alatt lévő routerAP, ami OWRT 15.0-ával küzdött ezzel a feladattal. Látszólag jobb, de van egy-két dolog, ami gyanús (pl. lassú IPv6 cím "kapása").
Üdv:
Ruzsi
A 7-essel már rég nem tesztelsz, 7.13-nál járnak. Egyébként a 6->7 átállás meglepően fájdalommentes.
Loadbalance&Failover esetén azért lehet meglepcsi, de legtöbbször tényleg nincs gond (kivéve mikor van :D) de ha le van mentve a konfig, nem visszafordíthatatlan.
A 7-esben sokat javult a v6 támogatás mert végre nem 3.3-as kernel van mögötte hanem 5.6-os.
FLAME ON
legegyszerűbb módja: dobd ki a picsába a mikrotiket és vegyél bármi ubiquiti-t helyette, ahol kb klick-klick next-next
~ubuntu, raspbian, os x~
Nem tenném.
Már így is OpenWRT-s router-AP-t cserélek le.
Üdv:
Ruzsi
Rosszul tetted. Wifi legyen OpenWRT router meg Mikrotik.
...aztán, ha bármi komolyabbat szeretnél, ami a SoHo default "NAT to Internet"-en túlmutat, akkor meg klikkelgethetsz, meg szívhatsz napokig :-D
"Probléma esetén nyomják meg a piros gombot és nyugodjanak békében!"
Na, ezért kár volt billentyűzetet ragadnod.