Invitech DC14 hova lett?
Sziasztok,
nem tud valaki valamit az Invitech DC14-rol, nem elerheto...?
- Tovább (Invitech DC14 hova lett?)
- 200 megtekintés
Sziasztok,
nem tud valaki valamit az Invitech DC14-rol, nem elerheto...?
Sziasztok!
Hogyan kell beállítani, hogy automatikusan legyen DST csere?
Manual time zone-nál csak fix dátumot lehet megadni???
Ha nem állítottam be semmit, akkor nincs DST állítás, azaz pont 1 órát késik!
Nem tudja a "last" dátum paramétert?
Köszönöm!
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!
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?
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!
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!
Sziasztok
Nekem tegnap este óta kieset a hálózat. Van valakinek most ilyen problémája, vagy csak nálam van gond?
downdetector.hu is bejelzett, de semmi hírt nem látok róla.
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!
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!
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!