Hálózatok általános

IKEv2 macOS 15.2 alatt 8 percenként leszakad [MEGOLDVA]

Használ valaki IKEv2 VPN-t macOS nativ kliensekkel? Valamiért 8 percenként leszakad és a Mikrotik logok alapján nem világos hogy miért (elvileg valami rekey történne itt, de csak azt látom hogy leszakad). IOS kliensekkel nincs ilyen probléma, illetve wireguardnál sincs, csak macOS-nél jelentkezik. Alább a phase1-2 konfig:

name="ike2" hash-algorithm=sha256 enc-algorithm=aes-256
     dh-group=x25519,ecp256,ecp384,ecp521,modp8192,modp6144,modp4096,modp3072,
         modp2048
     lifetime=1d proposal-check=obey nat-traversal=yes
     dpd-interval=disable-dpd

name="ike2-proposal" auth-algorithms=sha512,sha256
      enc-algorithms=chacha20poly1305,aes-256-cbc,aes-256-ctr,aes-256-gcm
      lifetime=30m pfs-group=modp2048

Ha valakinek működik 8 percen túl akkor be tudná rakni ide légyszi a phase1-2 algoritmusokat?

Hálózati vizsgáló - logoló szoftver desktopra

A rendszerünk használ egy 3rd party video streaming szolgáltatást. A felhasználók néha jelzik, hogy akadozik a lejátszás. Jó lenne biztosan, logok alapján tudni, hogy a hálózat akadozik-e, ahogy sejtjük.

Kellene nekünk valami desktop szoftver (Win és Mac), amit odaadnánk pár ügyesebb felhasználónak, hogy futtassa a gépén a háttérben és utána küldje el a logot. Valami olyasmire gondoltam, hogy egy programot elindítanak, majd minimalizálják és az meg 5-10 másodpercenként megnézne néhány általunk beállított DNS lekérdezést, pinget pár IP-re és TCP-n kapcsolódna pár szerver 443-as portjára és lejegyezné, hogy sikeresek voltak-e ezek.

Nyilván tudunk írni egy ilyen szoftvert, de gondolom, hogy másnál is felmerült már ilyen igény... Lehetőleg ne olyanokat ajánljatok, mint Zabbix, Nagios vagy Icinga. Ezeknek a telepítése egy felhasználó gépére nem életszerű. Ideális lenne ha egy binárisból és egy konfigból állna vagy valami kicsi és egyszerűen telepíthető cucc. Van valakinek ötlete?

IP watchdog relé modul működése

Üdv!

Napok óta képtelen vagyok felfogni egy IP watchdog modul működését, ebben kérnék segítséget. Talán icmp protokollal kapcsolatban hiányosak az ismereteim.

A célom:
Vannak pár nehezen megközelíthető helyszínen 4G routereim. Mögöttük 1, max 2 kamera streamel folyamatosan. A mobilnet sávszélessége elegendő a streamekhez, streamelés közben router WAN-jának a pingideje 30-50ms. Sajnos előfordul néha, hogy a rendelkezésre álló sávszélesség egyik pillanatról a másikra lecsökken, kevesebb lesz mint amennyi kellene a stream továbbításhoz. Ilyenkor a pingidő értelemszerűen megnő 1000ms fölé és a problémát 1 vagy néhány router újraindítás oldja meg. Ezt az újraindítást szeretném automatizálni.

Ebből az IP relé modulból rendeltem párat: https://www.aliexpress.com/item/1005001729638858.html

Azt szeretném, hogy egy megadott IP-t pingeljen 5 másodpercenként, és ha az utolsó 10 ping idő több, mint 1000ms, akkor a relével indítsa újra a routert. (elveszi tőle áramot pár mp-re)

Bár semmi doksi sincs, de elég egyértelműnek tűnik, hogyan kell ezt beállítani. A alábbi ábrán látható "ping interval"=5, "timeout"=1, "Retry times"=10 beállításokkal szerintem pontosan ezt kellene csinálnia.

watchdog01

A beállított Watch IP (62.100.224.141) egy teszt VPS-em, amin magas ping időket tudok szimulálni. Jelenleg a 2000ms késletetése van, azaz minimum 2000ms a pingideje. Az eszköz szerint viszont ONLINE van, pedig 1sec a ping timeout, azaz OFFLINE kéne lennie.

Össze-vissza játszottam a beállításokkal, de egyszerűen nem jöttem rá, hogy mi a működési logika. 2 napja chatelek az állítólagos fejlesztővel de nem jutok vele semmire, mintha nem egy bolygón élnénk.

Végül az alábbi kérdést tettem fel neki:
Az alábbi beállítások esetén:
- ping interval=2 
- timeout=1 
- retry time=3
Az IP OFFLINE, ha az IP tényleges ping ideje 2000ms. De az IP ONLINE, ha az IP tényleges ping ideje 1500ms.

Ezt a választ kaptam, amit bevallom nem értek:

the first "ping->interval" >= "ping->timeout"
if "ping->interval" time get right flag response, "ping->timeout" is ignore

 

Tök jó lenne ha ezt valaki értené és el tudná magyarázni, hogy mi történik itt :)

Köszönöm szépen!

UPDATE:

További magyarázatok a kínaitól, amik szintén "kínai" nekem:

when ping the packet with flag , so the ping only receve right flag, the prev flag is ignore

example: interval=2, timeout=2, ping response=1500ms, retry times=3
ping1 with flag=1,  response with in 1500ms, "retry times" clear to 0, ----> "online"
ping2 with flag=2,  response with in 2500ms, "retry times" add 1 ----> "online"("retry times"=1 < 3)
ping2 with flag=3,  response with in 1500ms, "retry times" clear to 0, ----> "online"

example: interval=1, timeout=2, ping response=1500ms, retry times=3, this config is not ok(interval < timeout)
ping1 with flag=1,  response with in 1500ms(but ping2 with flag=2 is start), "retry times" add 1 ----> "online" ("retry times"=1 < 3)
ping2 with flag=2,  response with in 1500ms(but ping3 with flag=3 is start), "retry times" add 1 ----> "online" ("retry times"=2 < 3)
ping3 with flag=3,  response with in 1500ms(but ping4 with flag=4 is start),  if "retry times" >= 3 ----> "offline"
ping4 with flag=4,  response with in 1500ms(but ping5 with flag=5 is start), wait device restart

i think strict "ping->timeout" check is not a good idea in an Internet

what is "right flag response" ?
ping send data with flag to check last packet

example;
ping times1, flag is 1, reponse check if not "flag 1" means lost packet
ping times2, flag is 2, reponse check if not "flag 2" means lost packet
ping times3, flag is 3, reponse check if not "flag 3" means lost packet


"ping->interval" min is 1 second
if  "ping->interval"=1, then ping times interval with 1 second, 
if  "ping->interval"=2, then ping times interval with 2 second, 
...

example "ping->interval"=2, "ping->timeout"=1
"ping->interval  start"|------2-------|
"ping->timeout start"|--1---|
relay toggle only when "online" -> "offline"

Skandináv hálózati infrastruktúra elleni támadások műszaki vonatkozásai

Történt ez a két incidens:

Megszakadt a Finnországot és Németországot összekötő távközlési vezeték
A Litvániát és Svédországot összekötő távközlési vezeték is elszakadt

Politikai vonatkozású ok- és következménykeresést félretéve, örvendetes, hogy műszakilag egész jól vannak megtervezve ezek a nemzetközi hálózatok. A Hetznernél van jónéhány szerverünk, egy részük a finnországi adatközpontban, és amit láttunk az egészből, az egy rövid kiesés, illetve a belső VLAN-on a DE-FI válaszidő megemelkedése 22 ms-ről ~37-re. 

Outage at backbone connection between Frankfurt - Helsinki

Több CNI plugin Kubernetessel

Sziasztok, rögtön az elején tisztáznám, nem production rendszerről van szó, laptopomon futó Minikube klaszterrel dolgozok, tanulás és kísérletezés a cél.

Kind és Minikube több "alap" CNI plugint is támogat, pl. Calico, Flannel, Cilium, stb. Flannel ha jól látom lightweightebb, másik kettő sok funkciót implementál. Amit szeretnék, hogy transzparens módon egy saját CNI plugint futtassak AZ UTÁN, hogy az "alap" CNI plugin végzett a teendőivel. Ez a saját plugin pár dolgot beállítana az interfészeken, egy futtatható fájl az egész, ha kézzel futtatom a konténereken akkor megcsinálja amit kell. Ha jól értem, az alapműködés az, hogy DaemonSet-ként fut az alap CNI plugin, vannak saját image-i, mikor készül egy pod akkor a CNI plugin init konténere lefut, az image-ben ott vannak a configok és binárisok (/etc/cni/net.d/*.conflist és /opt/cni/bin/) amiket lefuttat, aztán jön a pod saját initje.

Kérdés: hogyan lehetne kiterjeszteni ezzel a saját pluginnal az "alap" CNI plugint anélkül, hogy azok image-ébe belenyúlok?

NAS DNS probléma - 2. felvonás

Sziasztok!

A történet folytatódik annyi különbséggel, hogy időközben egyéb okok miatt is routert cseréltem, így a TP-Link Archer AX50 cserélődött egy Asus RT-AX58U -ra.

Volt egy halvány reményem, hogy megoldódik a router cserével a probléma, de sajnos nem.

Szóval az IP felosztás ugyanaz: DS923+: 192.168.2.200 és a VDSM: 192.168.2.201 .

DS923+:

root@ds923plus:~# ping 8.8.8.8

PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.


^C

--- 8.8.8.8 ping statistics ---

3 packets transmitted, 0 received, 100% packet loss, time 2ms


root@ds923plus:~# nslookup 8.8.8.8

;; connection timed out; no servers could be reached

VDSM:

root@VDSM:~# ping 8.8.8.8

PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.

64 bytes from 8.8.8.8: icmp_seq=1 ttl=58 time=14.6 ms

64 bytes from 8.8.8.8: icmp_seq=2 ttl=58 time=10.6 ms

64 bytes from 8.8.8.8: icmp_seq=3 ttl=58 time=13.4 ms

64 bytes from 8.8.8.8: icmp_seq=4 ttl=58 time=10.5 ms

64 bytes from 8.8.8.8: icmp_seq=5 ttl=58 time=10.3 ms

^C

--- 8.8.8.8 ping statistics ---

5 packets transmitted, 5 received, 0% packet loss, time 20ms

rtt min/avg/max/mdev = 10.321/12.652/16.684/2.370 ms

root@VDSM:~# nslookup 8.8.8.8

;; connection timed out; no servers could be reached

A DS923+- -on továbbra se tudok belépni a Synology fiókomba, mert ha látszólag meg is csinálja a műveletet, ugyanúgy nem jelzi a +5 év kiterjesztett garanciát, sem az email címemet.

A Quickconnect.to -ról már nem is merek álmodni. Totál megállt a tudomány. :(

DDOS - miért nincs állami fellépés ellene

Sziasztok!

Laikusként nem értem, hogy miért nem értesítik azokat a géptulajdonosokat/hálózat üzemeltetőket/előfizetőket, akiknek a készüléke részt vesz DDOS támadásban? Evvel jelentősen lehetne csökkenteni a fertőzött/fertőzhető gépek számát.

Van erre logikus válasz?

Üdv és kösz:

Lippi

NAS DNS probléma

Sziasztok,

A történet szereplője egy Synology DS923+ NAS (IP: 192.168.2.200), amin fut egy VDSM (2.201) és egy TP-Link Archer AX50 router. A zinternet: Vodafone 1Gbit-es csomag, ami 99%-ban hozza a névleges sebességet speedmeter szerint. A NAS eddig (2.200) eddig DMZ-ben működött, tűzfal beállítva kellőképpen, uPnP aktív, a konfiguráció Synology DS218 óta ezzel. a konfiggal működött kifogástalanul, egészen tegnapelőttig.

A NAS kezelőfelülete a 8000 és 8001 porton figyel az alapértelmezett 5000, 5001 helyett. Eddig minden ment pöc-röff: QuickConnect.to is. Utóbbi elérhetősége fontos lenne a VDSM felől is, ami elvileg nem ütközik semmivel, de a cucc inaktív. Oké, mondom kapcsoljuk be és jó lesz… Hát nem, mert az alábbi üzenet fogad:

A tartománynév feloldása sikertelen volt. Módosítsa a következőre a DNS-szerver címét: 8.8.8.8 (114.114.114.114 kínai régióban), majd próbálja újra.

Halkan megjegyzem, hogy mindig is a 8.8.8.8 párti voltam, tehát ez volt a DNS.

Aztán egy Windows-os gépre szerettem volna telepíteni a Synology Drive-ot, ami közölte, hogy nincs is ilyen azonosító…

A vezérlőpultba lépve A Synology fiók láthatóan nincs bejelentkezve. Oké, nyomjunk rá… Hát vagy ugyanaz az üzenet fogad, vagy nem történik semmi: látszólag megcsinálja, de a pipa inaktív. Mindez igaz a host-ra és a VDSM-re is.

Számomra ez X-akta. Amúgy asztali gép, laptop, telefon (wifin) jól működik, nem dobál DNS hibákat, teszik a dolgukat.

Kínomban már csináltam egy hülyeséget is: egy alapos backup után kinyomtam a NAS szemét, és elkezdtem felépíteni nulláról úgy, mintha most vettem volna ki a dobozból, de a hiba nem oldódott meg.

Bárkinek bármi ötlete, ha van, azt nagyon megköszönöm, mert így jelenleg csak lokálban tudom használni a gépet, ami nem lenne nagy dráma, viszont így nem megy a csoportos munka.

Köszönöm a segítséget előre is!