Hálózatok általános

Routolás több eszközzel otthonról Tkom felé

Sziasztok!

Tegnap jól elszórakoztam a MikroTik hEX routeremmel és a hálózattal.

Egészen addig, hogy a MikroTik rövid időn belül (0,5-1,5h) le tudja akasztani a Tkom HGW-jét (Sagem F@st 5670).

A jelenség: elmegy a Net, mert az Internet zöld LED-je kialszik, a telefon LED piros lesz, a többi LED marad zöld.
Ilyenkor még igazán switch-ként se működik a HGW. Egyetlen lehetőség: ki-bekapcs. Nem túl előnyös, ha azt
hiszem, hogy a Net egy infrastruktúra, mint pl. a villany és "sosem" áll le.

Előfordult ez máskor is, MikroTik nélkül, de lényegesen ritkábban. Nincs a szívem csücskében ez a HGW, bár nagyon
sokat tud, de az sw.-je ...

A Tkomnál addig rinyáltam minden féle formában, hogy szedjenek ki a CG-NAT mögül ÉS kapjak szűretlen IPv6-ot,
hogy beállították a modemet "valamibe". Elvileg bridzsbe, mert előtte router volt. Ez most nem egyértelmű, mert
most is van a HGW szerint PPP kapcsolat, de nem az előfizetési adataimmal. A HGW-ből tudom pingetni a saját
CG-nat-os (100.96) IP-met és a Tkom DNS1 és 2-es szerverét. Mindezt a HGW-ből. A default gw-t, ami 10.5 valami,
azt viszont nem.

Már itt nem értem az egészet, de nem ez a lényeg!

PPPoE passthrough be van kapcsolva.
Elvileg kapok 2 sessiont a Tkomtól. Igaz, hogy ez mellé felzárkózik most 3.-nak ez a fenti PPP-s kapcsolat, hogy
Tovább bonyolódjon a helyzet.

PPPoE session 1: a MikroTik terminálná. Ez az, ami vélhetően leakasztja a HGW-t.
PPPoE session 2: egy normál WiFi router, szintén egy PPPoE terminálással. Ez most működk kb. 1h-ja ...

A HGW-nek 1+4 portja van: 2,5G-s kék és 4 db. 1G-s sárga.
A kékbe lenne dugva a MikroTik ether1-es portja a bejövő Nethez. (jelenleg kihúzva)

A továbbiak:
WiFi router
RPi egyik interfésze.

A HGW LAN-ja a 192.168.1.1/24-et kapja defaulton hagyva. Ez a 192.168.1.0/24 amolyan DMZ LAN lenne, de
Nem a biztonság miatt, hanem köztes hálózat, ha vissza kell bontani mindent, hogy legyen Net, ha megmakacsolja
magát a HGW.
A MikroTik a 192.168.1.2
A WiFi router 192.168.1.3
Az RPi 192.168.1.4
Továbbiak 5-től jönnek, ha a HGW-hez WiFi-vel, vagy a maradék vezetékesen csatlakozik valami.

A WiFi router OWRT 15.0-ás, régi, gyári sw-vel, némileg felturbózva a gyártó dolgaival, de teljesen elérhető az
OWRT, csak nem friss!
A WiFi router az AP a hálóban (alapban), de nem ő DHCP szerver, hanem a Mikrotik.

Amivel igazán most bajban vagyok az a HGW leakadása (nem ez most a feladat igazán, bár érdekes, hogy
egész éjjel PPP(oE) baja volt, aztán a reggeli ki-bekapcsolás óta ez most elmúlt ...), hanem a default route!

Alapban a MikroTik lenne a default gw, hiszen ő terminálja a PPPoE-t.
De ha most a WiFi terminál, akkor neki kell lennie!
Kézzel meg tudom oldani a dolgot, de az összes eszközön nem!

Be kell vetni a dinamikus routolást? RIP, OSPF?

Lehet, hogy nem mindent írtam le, de ugye az én fejemben megvan a  topológia.

Pl. jó lenne, ha lehetne állítani route-okat a HGW-n, ha másért nem, hogy ne kellejen az ő 192.168.1.0-ás
hálójába csatlakozni, ha el akarom érni, hogy állítgassam.

Köszönöm az együttgondolkozást!

Telekom MESH

Kaptam a telekre internetet két MESH dobozzal. A felszereléskor a technikus egy viszonylag rövid madzaggal közötte rá az első MESH dobozt a routerre és kikapcsolta a routeren a WiFit. Azt mondta, hogy az első MESH doboz legyen közel, akkor fölösleges a WiFi a routeren.

Később rájöttem,hogy jobb lenne az első doboz a konyhában (kb. 10 méterre a routertől), mert akkor egy második dobozzal le tudom fedni az egész udvart is. Hogy a router közelében is legyen internet, bekapcsoltam a router saját wifijét. Gondoltam a router WiFi és a két doboz elég, igaz így két SSID van a három elérési ponthoz, de majd az okos eszköz válogat, ha egyszerre többet lát.

Sajnos úgy tűnik a technikusnak igaza van. Ha router WiFi-je bekapcsolt állapotban van, akkor a MESH-en akadozik az internet. (A csatornák nem ütköznek, szépen egymás mellett látszanak az SSID-k.) Ez valami eszközspecifikus dolog, vagy a MESH sajátossága,hogy nem megy együtt a router WiFijével?

MikroTik USB mobilnet

Sziasztok!

Van egy MikroTik hEX routerboard. Továbbá egy ős időkből származó (kb. min. 10 év) Pannon GSM (Huawei) USB stick egy Yettel feltöltős kártyával.

Az USB-s stick Ubuntu 22.04 alatt működik, ha feltöltöm a kártyát.

Az láttam a egy itthoni mikrotikes videóban, hogy lehet lte interfészt "csinálni", ha van USB portom. Hát én bedugtam az egyetlen portba egy
4 portos mini HUB-ot, abba a stick-et, egy Qilive pen drive-ot és egy TP-Link mini WiFi adaptert.
A stick-en a zöld egyetlen LED periódikusan villan egyet-egyet. A WiFi-n nem láttam semmit. Talán a pen-t látja.

Viszont nincs lte1 interfészem! Van LTE fül a WEB config interfész oldalon, de ennyi!

Mit lehet tudni a MikroTik belsejéről, hogy látja-e az USB-s cuccokat?

Alkérdés: ebbe az USB portba dughatok WiFi adaptert és tudok csinálni belőle AP-t is?

Köszönöm!

Synology NAS netről való elérése Vodafone net alatt

Sziasztok,

Adott az alábbi felállás: Vodafone Docsis 3.1 router-re dugott TP-Link AX50, amin lóg egy Synology DS218 NAS.

Szeretném netről elérhetővé tenni a NAS-t, ami Telekom alatt még működött, Vodára való váltás óta viszont nem.

Telekom alatt úgy működött, hogy T-Com routerben a TP-Linket tettem DMZ-be, a NAS-t pedig a TP-Link alatt tettem DMZ-be.

Most viszont a Voda routerben nincs DMZ funkció, így netről meghívva a gkaroly.synology.me -t, az alábbi üzenet fogad:

A webhely nem érhető elA(z) gkaroly.synology.me túl hosszú ideje nem válaszol.
Próbálja ki a következőket:

A kapcsolat ellenőrzése
A proxy és a tűzfal ellenőrzése
A Windows Hálózati diagnosztika futtatása
ERR_CONNECTION_TIMED_OUT

Ha tudnátok segíteni, mi a megoldás, nagyon hálás lennék, mivel ez a funkció nekem nagyon fontos lenne.

Tudom, ott a Quickconnect.to, azzal működik is, de az most nem releváns számomra.

Köszönöm előre is!

MikroTik IPv4 nem működik

Sziasztok!

Mi van olyankor, amikor a pppoe-out1-esnek van valós IPv4 címe, de nem működik?
(se bentről, se kintről! a kinti címér tudom pingetni kintről)

Ráadásul az IPv6-on keresztül simán mennek a mögötte lévő IPv6-os cuccok!

Gyanítom, hogy IP cím váltás volt a napokban és ebbe gabalyodott bele a kis dobozka.
Hogyan tudom rávenni, hogy újra kapcsolódjon IPv4-en, de az IPv6-ot ne bántsa?

Eddig az IPv4 volt ami ment stabilan, de mosz az IPv6 húzhat ki a csávából.

Köszönöm!

NIS2 információ kérés

Sziasztok!

 Az idei évben bevezetésre fog kerülni a tárgyban szereplő rendszer. Érdeklődnék, valaki foglalkozott-e már vele? Röviden a kérdésem lényege : mindenhol azt írják, hogy először is utána kell járni, hogy az adott cég a hatálya alá esik-e az adott törvénynek, DE én sehol nem találtam, hogy hol is lehetne ezt megnézni konkrétan (nem az általános leírásra gondolok).

 Amíg ki nem derítem, hogy egyáltalán kell-e vele foglalkozni, nem szívesen keresnék meg erre szakosodott cégeket (vagy mindenképp kell, mert csak ők tudják megmondani??).

Segítségeket előre is köszönöm!

Linux routing kérdés

Nem megy a routing úgy ahogy szeretném, és nem jövök rá, hogy miért.

Az alap felállás a következő:

* van egy test01 szerver (docker host), amin létrehoztam egy docker internal network-öt, 10.241.32.0/24
* van egy test02 szerver (docker host), amin létrehoztam egy másik docker internal network-öt, 10.241.33.0/24
* mindkét szerveren elindítottam egy-egy konténert "gateway" néven, amin beállítottam wireguard-ot. ezeknek a címei az internal hálózatokon 10.241.32.11 és 10.241.33.11, plusz ezek a bridge hálózatban is benne vannak (elérik az internetet)
* ezen felül a test01 szerveren elindítottam egy busybox01-et is, 10.241.32.12 címmel, illetve a test02 szerver is, ott 10.241.33.12 címmel. Ők csak az internal hálózatokon vannak rajta.
* Elvileg mindenhol beállítottam a route-okat, de a két busybox nem látja egymást, illetve a busybox-ok nem érik a távoli gatweway-eket se.

Móricka rajz:

busybox01 <--> 10.241.32.0/24 <--> gateway01  <--> wireguard <--> gateway02 <--> busybox02

A végső cél az lenne, hogy a test01 és test02 gépeken indítsak különféle konténereket az internal hálózatokon, és ez a konténerek elérjék egymást a gateway-eken keresztül.

A gateway01 és gateway02 ezekkel a beállításokkal van indítva:

    -v /lib/modules:/lib/modules \
    --sysctl="net.ipv4.conf.all.src_valid_mark=1" \
    --sysctl="net.ipv4.ip_forward=1" \
    --cap-add=NET_ADMIN

Amennyire én tudom, ennek elégnek kellene lennie ahhoz, hogy gateway-ként működjön.

Ami már működik: a gateway01 és a gateway02 -őn működik a wireguard kapcsolat, és ők látják egymást.

0ba58a4b5cfc:/config# ip a | grep 10.241
    inet 10.241.32.11/24 brd 10.241.32.255 scope global eth0
0ba58a4b5cfc:/config# ping -c 1 10.241.33.11
PING 10.241.33.11 (10.241.33.11) 56(84) bytes of data.
64 bytes from 10.241.33.11: icmp_seq=1 ttl=64 time=22.2 ms

--- 10.241.33.11 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 22.161/22.161/22.161/0.000 ms
0ba58a4b5cfc:/config# 
2bc76d2071c6:/config# ip a | grep 10.241
    inet 10.241.33.11/24 brd 10.241.33.255 scope global eth0
2bc76d2071c6:/config# ping -c 1 10.241.32.11
PING 10.241.32.11 (10.241.32.11) 56(84) bytes of data.
64 bytes from 10.241.32.11: icmp_seq=1 ttl=64 time=22.3 ms

--- 10.241.32.11 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 22.337/22.337/22.337/0.000 ms
2bc76d2071c6:/config# 

A wireguard így néz ki rajtuk (a nyilvános címeket lecseréltem x.y.z.w -re):

0ba58a4b5cfc:/config# wg show
interface: grimdam
  public key: aICWm8W3nJfE7Y/y3ghGHp1GEkBEoCuc0ymodNUh6EA=
  private key: (hidden)
  listening port: 51820

peer: z9XEpgLuNPOfP+0VmubixYd3sqiadpZwfa9ui1Gf8Vk=
  endpoint: x.y.z.w:51820
  allowed ips: 10.241.33.0/24
  latest handshake: 1 minute, 30 seconds ago
  transfer: 4.63 KiB received, 4.38 KiB sent
  persistent keepalive: every 5 seconds
0ba58a4b5cfc:/config# 
2bc76d2071c6:/config# wg show
interface: grimdam
  public key: z9XEpgLuNPOfP+0VmubixYd3sqiadpZwfa9ui1Gf8Vk=
  private key: (hidden)
  listening port: 51820

peer: aICWm8W3nJfE7Y/y3ghGHp1GEkBEoCuc0ymodNUh6EA=
  endpoint: x.y.z.w:51820
  allowed ips: 10.241.32.0/24
  latest handshake: 1 minute, 33 seconds ago
  transfer: 4.26 KiB received, 4.66 KiB sent
  persistent keepalive: every 5 seconds
2bc76d2071c6:/config# 

Hogy kizárjam a tűzfal beállítási hibalehetőségeket, egy forward accept all rule-t adtam hozzá mindkét oldalon. Alább látható a két konténer iptables-save kimenetei. A nat részt nem én adtam hozzá, hanem a docker magától, amit én adtam hozzá az a -A FORWARD -j ACCEPT.

# Generated by iptables-save v1.8.10 (nf_tables) on Sun Feb 25 19:26:57 2024
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A FORWARD -p icmp -j ACCEPT
-A FORWARD -j ACCEPT
COMMIT
# Completed on Sun Feb 25 19:26:57 2024
# Generated by iptables-save v1.8.10 (nf_tables) on Sun Feb 25 19:26:57 2024
*nat
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
:DOCKER_OUTPUT - [0:0]
:DOCKER_POSTROUTING - [0:0]
-A OUTPUT -d 127.0.0.11/32 -j DOCKER_OUTPUT
-A POSTROUTING -d 127.0.0.11/32 -j DOCKER_POSTROUTING
-A DOCKER_OUTPUT -d 127.0.0.11/32 -p tcp -m tcp --dport 53 -j DNAT --to-destination 127.0.0.11:43875
-A DOCKER_OUTPUT -d 127.0.0.11/32 -p udp -m udp --dport 53 -j DNAT --to-destination 127.0.0.11:44004
-A DOCKER_POSTROUTING -s 127.0.0.11/32 -p tcp -m tcp --sport 43875 -j SNAT --to-source :53
-A DOCKER_POSTROUTING -s 127.0.0.11/32 -p udp -m udp --sport 44004 -j SNAT --to-source :53
COMMIT
# Completed on Sun Feb 25 19:26:57 2024
# Generated by iptables-save v1.8.10 (nf_tables) on Sun Feb 25 19:27:02 2024
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A FORWARD -p icmp -j ACCEPT
-A FORWARD -j ACCEPT
COMMIT
# Completed on Sun Feb 25 19:27:02 2024
# Generated by iptables-save v1.8.10 (nf_tables) on Sun Feb 25 19:27:02 2024
*nat
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
:DOCKER_OUTPUT - [0:0]
:DOCKER_POSTROUTING - [0:0]
-A OUTPUT -d 127.0.0.11/32 -j DOCKER_OUTPUT
-A POSTROUTING -d 127.0.0.11/32 -j DOCKER_POSTROUTING
-A DOCKER_OUTPUT -d 127.0.0.11/32 -p tcp -m tcp --dport 53 -j DNAT --to-destination 127.0.0.11:36441
-A DOCKER_OUTPUT -d 127.0.0.11/32 -p udp -m udp --dport 53 -j DNAT --to-destination 127.0.0.11:42835
-A DOCKER_POSTROUTING -s 127.0.0.11/32 -p tcp -m tcp --sport 36441 -j SNAT --to-source :53
-A DOCKER_POSTROUTING -s 127.0.0.11/32 -p udp -m udp --sport 42835 -j SNAT --to-source :53
COMMIT
# Completed on Sun Feb 25 19:27:02 2024

A route-ok a következők:

0ba58a4b5cfc:/config# ip route
default via 172.17.0.1 dev eth1 
10.241.32.0/24 dev eth0 proto kernel scope link src 10.241.32.11 
10.241.33.0/24 dev grimdam scope link src 10.241.32.11 
172.17.0.0/16 dev eth1 proto kernel scope link src 172.17.0.2 
2bc76d2071c6:/config# ip route
default via 172.17.0.1 dev eth1 
10.241.32.0/24 dev grimdam scope link src 10.241.33.11 
10.241.33.0/24 dev eth0 proto kernel scope link src 10.241.33.11 
172.17.0.0/16 dev eth1 proto kernel scope link src 172.17.0.2 

A wireguard interface neve mindkét oldalon "grimdam", és a két gateway erre route-olja a másol oldal privát hálózatát.

Eddig minden szép és jó. Ezek után elindítok egy busybox-ot a test01 (docker host) gépen úgy, hogy a címe 10.241.32.12, és a gateway01-el azonos internal docker hálózaton van, és hozzáadom a következő static route-ot:

ip route add 10.241.32.0/20 via 10.241.32.11

Ezután próbálom elérni a vele azonos gépen levő gateway-t (10.241.32.11) és a távoli oldalon levőt is (10.241.33.11), és a következőt látom:

/ # ip route
10.241.32.0/24 dev eth0 scope link  src 10.241.32.12 
10.241.32.0/20 via 10.241.32.11 dev eth0 
/ # ping -c 1 10.241.32.11
PING 10.241.32.11 (10.241.32.11): 56 data bytes
64 bytes from 10.241.32.11: seq=0 ttl=64 time=0.182 ms

--- 10.241.32.11 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 0.182/0.182/0.182 ms
/ # ping -c 1 10.241.33.11
PING 10.241.33.11 (10.241.33.11): 56 data bytes
^C
--- 10.241.33.11 ping statistics ---
1 packets transmitted, 0 packets received, 100% packet loss
/ # 

Tehát a "közeli" gateway01-el van kapcsolat, és a gateway01-nek is van kapcsolata a gateway02-vel. Viszont a busybox01-nek nincs kapcsolata a gateway02-vel.

Ha traceroute-ot próbálok, akkor a gateway01 nem küld vissza ICMP-t:

/ # traceroute 10.241.33.11
traceroute to 10.241.33.11 (10.241.33.11), 30 hops max, 46 byte packets
 1  *  *  *
 2  *  *  *

Mivel a gateway01 nem jelenik meg a traceroute-ban, ezért azt sejtem, hogy a gateway-nél rontottam el valamit, de nem jövök rá, hogy mit.

Mit rontottam el? A route-ok a rosszak, vagy a tűzfal szabályok, vagy valamilyen sysctl-t felejtettem el?

Köszönöm!