MikroTik SSH a WAN oldalról

Hálózatok általános

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!

( E-Medve v | 2024. 02. 18., v – 15:48 )

Szerkesztve: 2024. 02. 18., v – 15:58

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

( rattila | 2024. 02. 18., v – 16:46 )

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.

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.

( ggallo | 2024. 02. 18., v – 17:37 )

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

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

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

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

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...

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

[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

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.

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).

Jól érted.

 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.

Igen, így van. 

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.

Ha a Pi-ről tudom pingetni az MT és vica-verza, az azt jelenti, hogy működik a switch a HG-ben? ;-)

 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?

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

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

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?

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

( kbalint v | 2024. 02. 19., h – 15:12 )

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~