A blokkolás, mint segélykiáltás – amikor anya elmegy, a gyerek pedig falat húz

Amikor egy gyerek úgy dönt, hogy letiltja az édesanyját egy üzenetküldő alkalmazásban, az első reakció általában a döbbenet: „Hogy teheti ezt? Hogy mer engem letiltani?” A felszínről nézve ez dacos, tiszteletlen, „rossz” viselkedésnek tűnhet. Ha azonban mögé nézünk – különösen egy olyan helyzetben, ahol az anya elköltözött, új párkapcsolatban él, és már nem alszik otthon – egészen más kép rajzolódik ki. A gyerek blokkolása ilyenkor nem egyszerű hiszti, hanem egy kétségbeesett kísérlet arra, hogy valami minimális kontrollt szerezzen egy széthulló világ fölött.

A beszélgetés, ami már az elején feszül

A történet egy látszólag hétköznapi WhatsApp‑beszélgetéssel indul. Az anya reggel üzen: „All good sis???”, „Milan is awake?”, „Eat some breakfast”, majd jönnek a mosolygós, puszis emojik: „Good girly”. Első ránézésre minden rendben: érdeklődés, gondoskodás, szeretet. A gyerek válaszol is, rövid, de egyértelmű „Yes”-ekkel. Mégis, valami feszültség már itt érezhető a sorok között.

Aztán megjelenik egy fontos mondat: „I am NOT typing yes when I am trying to type something else.” A helyzet magyarázata egyszerű és nagyon gyerekes: a kisöccs is írogat a telefonról, belenyúl az üzenetekbe, viccelődik. De ennek a mondatnak szimbolikus súlya is van. A kislány úgy érzi: nem ő irányít. Nem azt küldi, amit szeretne. Nem teljesen az ő kezében van, mi jelenik meg a másik oldalon.

Ez a „nem én írok” élmény sokkal tágabb értelemben is igaz az életére: nem ő döntött arról, hogy anya elmegy, nem ő választotta az új kapcsolatot, nem ő akarta, hogy az éjszakai biztonság – „anya itthon alszik” – megszűnjön. A chatben csak egy mondat, a lelke szintjén viszont pontos leírása annak, ami történik vele: mások „írják” az ő életét.

A mondat, ami nagyon tud fájni

A beszélgetés következő fontos pontja, amikor a gyerek megijed, hívja az anyját, de az anya nem veszi fel a telefont – dolgozik, siet, zavarják a hívások. Majd érkezik az üzenet:

„Please only message me if there is a problem.”

Ez egy felnőtt, leterhelt agy számára azt jelenti: „Most munka közben vagyok, ne írj apróságok miatt, majd beszélünk, ha fontos.” Egy gyerek, aki épp most élte át, hogy az anyja elköltözött, új párja van, már nem alszik otthon, ezt egészen máshogy tudja lefordítani magában:

  • „Csak akkor kellek, ha baj van.”
  • „A mindennapi dolgaim, örömeim, apróságaim nem fontosak.”
  • „Nem akar velem beszélgetni, csak ha muszáj.”

Ez a mondat önmagában talán nem tragikus, de egy ilyen élethelyzetben könnyen a jéghegy csúcsává válik. A gyerek szívében ott van a kimondatlan kérdés: „Még mindig fontos vagyok neki?” Amikor erre a kérdésre ilyen félreérthető üzenet érkezik, a fájdalom pillanatok alatt átválthat dühbe.

A blokkolás logikája: fáj, ezért bezárok

A következő lépés a blokkolás. Külső szemmel nézve ez drasztikus. Mintha a gyerek azt mondaná: „Nem akarlak az életemben.” De a valóság ennél sokkal összetettebb.

A gyerek nem tud felnőtt módon vitázni, érvelni, határt húzni. Nem mondja azt: „Anya, amikor azt írod, hogy csak akkor írjak, ha baj van, nagyon rosszul esik, mert úgy érzem, hogy már nem érdekelnek a mindennapjaim.” Ehelyett olyan eszközt használ, amit ismer és kezelni tud: a gombot. A blokkgombot.

A blokkolás egyszerre három dolog:

  1. Düh kifejezése
    „Ha te nem akarsz velem beszélni, akkor én sem akarok veled beszélni.” Ez egy gyerekes, de érthető tükrözés: visszaadja ugyanazt az elutasítást, amit megél.
  2. Fájdalom védelme
    „Ha fáj, amit írsz, akkor inkább ne is lásd, hogy itt vagyok, ne is érj el.” A gyerek ezzel a lépéssel próbálja megállítani azt a csatornát, amin keresztül most a legtöbb sebet kapja.
  3. Kontroll visszaszerzése
    Az élet nagy dolgai felett nincs befolyása – de azt eldöntheti, ki tud neki írni WhatsAppon. Ez egy pici, mesterséges, de számára nagyon is valós kontrollélmény: végre ő dönt.

A blokkolás így nem az anya iránti szeretet megszűnését jelenti, hanem azt, hogy a szeretet mellé olyan mennyiségű fájdalom és zavarodottság társult, amit már nem bír el.

Apa szerepe: stabilitás a viharban

Ebben a történetben az apa az a szereplő, aki otthon maradt a gyerekekkel. Ő az, aki látja a képernyőn a beszélgetést, hallja a háttérben az éjszakai sírásokat, érzi a feszült csendeket. És ő az, aki a legkönnyebben sodródhat bele abba a csapdába, hogy – a saját sértettségétől hajtva – a gyerek blokkolását igazolásként használja: „Látod, anyád milyen? Jól tetted, hogy letiltottad.”

Ez érthető, emberi kísértés, de hosszú távon a gyereknek árt.

Apa feladata most sokkal nehezebb, de sokkal fontosabb is: stabil, érzelmileg biztonságos bázisnak lenni. Olyan felnőttnek, akinél szabad egyszerre szeretni és utálni anyát. Akinél kimondható, hogy „hiányzik is, de közben haragszom rá, mert elment.” Aki azt mondja:

  • „Értem, hogy nagyon bánt, ami történik.”
  • „Nem csoda, ha dühös vagy rá azért, hogy nem alszik itthon.”
  • „Az is érthető, hogy ezért letiltottad.”

És közben hozzáteszi:

  • „Akármi történik, én itt leszek veled.”
  • „Nem kell választanod anya és köztem. Szeretheted mindkettőnket, akkor is, ha most haragszol rá.”

Az apa ezzel leveszi a gyerekről a lojalitás terhét. Nem kell „oldalt választania”. Nem kell úgy védenie az egyiket, hogy közben elárulja a másikat. Lehet egyszerre szomorú, dühös és szeretettel teli – mert a gyerek szíve így működik.

Mit lehet tenni a blokkolás után?

A blokkolás pillanatában sokszor az a kérdés: „Mit tegyek? Követeljem, hogy oldja fel? Tiltsam meg? Vegyem el a telefonját?” Ezek mind érthető reflexek, de elsősorban a felszínt kezelik, nem az okot.

Érdemes inkább kérdésekkel közelíteni:

  • „Mi fájt a legjobban abból, amit anya írt?”
  • „Mit éreztél, amikor nem vette fel a telefont?”
  • „Mit szerettél volna, mit csináljon helyette?”
  • „Miért döntöttél úgy, hogy letiltod?”

Nem az a cél, hogy a gyerek „bevallja, hogy rosszat csinált”. A cél az, hogy megértse a saját érzéseit, és lassan-lassan szavakká tudja formálni azt, amit most gombokkal fejez ki.

Később – ha csendesebbek az indulatok – lehet arról is beszélni, hogy:

  • vészhelyzetben miért fontos, hogy el tudják érni egymást,
  • hogyan lehet úgy határt húzni, hogy közben nem zárja be az összes ajtót,
  • ha egyszer szeretné, hogyan tudná elmondani az anyjának, mi bántotta.

Az anya új kapcsolata: a gyerek szemszögéből

A történet egy különösen érzékeny eleme, hogy az anya egy azonos nemű partnerrel kezd új kapcsolatot. A gyerek számára azonban nem ez az elsődleges probléma. Nem az a kérdés, hogy a párja férfi vagy nő, hanem az, hogy:

  • elment,
  • máshol alszik,
  • valaki (valami) más körül szerveződik most az élete.

A gyerek fejében ez így jelenik meg: „Van valaki, aki fontosabb lett nálunk.” Hogy ez a valaki férfi vagy nő, az ebből a szempontból másodlagos. Ami igazán számít, az az érzelmi üzenet: „Én hol vagyok most az ő szívében?”

Ha a szülők képesek világosan kimondani:

  • „Ami köztünk, felnőttek közt történik, nem a te hibád.”
  • „Az, hogy anya új kapcsolatban él, nem jelenti azt, hogy kevésbé szeret téged.”
  • „A családunk formája változik, de te nem lettél kevésbé fontos.”

– akkor sokat tesznek azért, hogy a gyerek ezt az időszakot ne mély sebként, hanem egy nehéz, de feldolgozható élethelyzetként élje meg.

Záró gondolat: mit jelent a blokkolás valójában?

Ebben a történetben a „You blocked this person” nem egy gonosz gyerek tette. Sokkal inkább egy mondat, amit nem tudott másképp kimondani:

  • „Fáj, amit csinálsz.”
  • „Hiányzol, de közben haragszom rád.”
  • „Nem értem, miért választottad ezt az utat.”
  • „Szeretném, ha látnád, mennyire bánt.”

A blokkolás egy gyerek nyelvén megfogalmazott segélykiáltás és határ. Lehet rajta dühösnek lenni, de sokkal többet ér, ha meghalljuk mögötte azt, amit valójában mondani próbál.

Apaként a legnagyobb ajándék, amit ilyenkor adhatsz, az az, hogy nem a gombot nézed, hanem a szívet, ami megnyomta. És hogy miközben te is sérült vagy, mégis képes vagy számára az a stabil pont lenni, akiről biztosan tudja: nem tiltja le, nem költözik el, érzelmileg elérhető marad – akkor is, ha odakint éppen vihar van.

Egyirányú hang mobilnetről – hogyan győztem le a CGNAT‑ot Groundwire + Asterisk alatt

Az utóbbi időben egy idegesítő hibával küzdöttem: iPhone + Groundwire softphone mobilnetről simán felépítette a hívást a saját Asterisk/Issabel PBX-emre, a túloldal hallott engem, de a telefon felé nem jött be hang. Klasszikus „egyirányú hang” tünet, minden VoIP‑os rémálma.

A helyzetet bonyolította, hogy mobilneten, dupla NAT/CGNAT mögött vagyok, így elsőre mindenki NAT‑ra mutogat. De a konkrét ok végül nem a Groundwire‑ben, hanem a PBX NAT/média beállításában volt.

Tünetek: minden jelzés oké, csak a hang hiányzik

A hívások jelzés szinten hibátlanul működtek:

  • REGISTER / INVITE / 200 OK / ACK szépen lement.
  • A hívás felépült, a túloldal rendesen hallott.
  • A Groundwire oldalon viszont néma volt a bejövő hang.

A Groundwire debug logjaiban látszott, hogy:

  • a kliens folyamatosan küldi az RTP csomagokat a PBX felé (Sent Audio RTP packet…),
  • viszont bejövő RTP‑ről semmi nyom, és a hívás közben „AudioIoaudioDataReadAccumulate Not Enough Data” üzenetek jelentek meg.

Vagyis: uplink van, downlink nincs – ez szinte mindig NAT/média irányú probléma.

Első nyomok: mit mond az SDP?

Megnéztem az INVITE/200 OK SDP‑ket.

A PBX (pintyo‑s rendszer) így hirdette a médiát:

v=0
o=root 1233995227 1233995227 IN IP4 84.224.109.185
s=Asterisk PBX 18.19.0
c=IN IP4 84.224.109.185
t=0 0
m=audio 18314 RTP/AVP 8 0 3 107 101
a=rtpmap:8 PCMA/8000
...
a=sendrecv

A Groundwire erre az alábbi saját SDP‑vel válaszolt:

c=IN IP4 192.168.11.91
m=audio 60330 RTP/AVP 8 101
...
a=sendrecv

A kliens tehát a 192.168.11.91:60330‑ról küldi az RTP-t kifelé. Mobilnet + Wi‑Fi‑s környezetben ez a cím valójában egy belső IP, ami CGNAT után egy teljesen más publikus IP/portra fordul át. A PBX viszont nem azt a címet használta vissziránynak, ahonnan ténylegesen érkezett az RTP, hanem a saját NAT‑logikáját követte.

Kulcs: mit tud a chan_sip peer NAT‑ról?

A következő lépés az volt, hogy megnézzem a 201-es mellék státuszát Asteriskben:

asterisk -rx "sip show peer 201"

A fontos részek:

Force rport  : No
Symmetric RTP: No
DirectMedia  : No
Addr->IP     : 167.99.119.203:31645
Reg. Contact : sip:201@10.65.11.2:31645;rinstance=...

A DirectMedia (canreinvite) szerencsére már eleve ki volt kapcsolva, viszont:

  • Force rport: No
  • Symmetric RTP: No

Tehát a chan_sip peer gyakorlatilag nem használta azt a forrás IP/port párost, ahonnan a kliens valójában jött, hanem az SDP‑ben megadott címre próbált visszaküldeni. Ez LAN‑on még elmegy, de CGNAT mögött biztos bukás.

Ezzel tulajdonképpen meg is volt a diagnózis:
nem a Groundwire, hanem a chan_sip NAT/média logikája volt alkalmatlan CGNAT‑os kliensekhez.

A megoldás: NAT a PBX oldalán, nem a kliensben

A fix három lépésből állt.

1. Globális NAT beállítás chan_sip-hez

Először a globális SIP NAT‑ot tettem rendbe:

; /etc/asterisk/sip_general_custom.conf

externip = 84.224.109.185
localnet = 192.168.0.0/16
nat = force_rport,comedia
  • externip – a PBX publikus IP‑je.
  • localnet – a belső háló(k).
  • nat = force_rport,comedia – ez adja meg a kívánt NAT‑viselkedést (rport + comedia).

Ez biztosítja, hogy a PBX tudja, mikor van NAT mögött, és hogyan kezelje a kliens címét.

2. NAT és DirectMedia kikapcsolása a 201-es melléken

Mivel a mellékeket az Issabel GUI kezeli, a per‑peer NAT‑ot a webes felületen állítottam:

  • A 201-es melléknél a NAT mezőt Yes-re tettem.
  • A Direct Media (canreinvite) alapból No, de ha látszik ilyen mező, akkor mindenképp No legyen.

A háttérben ez a konfiguráció jött létre:

[201]
host=dynamic
type=friend
context=from-internal
secret=...
nat=force_rport,comedia
directmedia=no
...

Reload után újra megnéztem:

asterisk -rx "sip show peer 201"

És végre ez fogadott:

Force rport  : Yes
Symmetric RTP: Yes
DirectMedia  : No

Vagyis:

  • rport használat: bekapcsolva
  • symmetric RTP: bekapcsolva
  • direct media / canreinvite: kikapcsolva

Pont ez kell CGNAT mögötti kliensekhez.

3. Újratesztelés Groundwire-rel

Ugyanabból a mobilnetes környezetből indítottam újra a hívást a 201-es mellékre Groundwire-rel.

Eredmény:

  • A hívás jelzés szinten ugyanúgy felépült.
  • A túloldal továbbra is hallotta a mobilt.
  • És végre a Groundwire‑en is megjelent a bejövő hang – kétirányú, stabil be

Hogyan integráltam az UptimeRobotot a Synology tűzfallal úgy, hogy a biztonság is megmaradjon

Régi problémám volt, hogy a Synology NAS-okon szigorú, ország alapú (GeoIP) tűzfalat használok, miközben az UptimeRobotnak is el kell érnie a DSM webfelületét és pingelnie kell a szervert. Ez elsőre ellentmondásnak tűnik: hogyan engedjek be egy rakás külföldi IP-t úgy, hogy közben a tűzfal továbbra is mindent tiltson, ami nem kell?

Ebben a bejegyzésben leírom, hogyan oldottam meg ezt két Synology NAS-on (köztük egy DS220+ készüléken), úgy, hogy:

  • az UptimeRobot minden monitorja stabilan zöld marad,
  • a DSM tűzfal továbbra is csak Magyarországról (és adott esetben még néhány országból) enged be forgalmat,
  • a megoldás reboot-álló, azaz újraindítás után automatikusan visszaállnak a szabályok.

Kiindulási helyzet: DSM tűzfal, GeoIP és UptimeRobot

A DSM beépített tűzfala alapból jól használható, de két fontos korlátja van:

  • Nem kezel IP-listákat dinamikusan (pl. UptimeRobot IP-k hosszú listája).
  • Reboot vagy Docker indulása után a belső iptables struktúrák változhatnak, ezért ha kézzel piszkáljuk, az nem tartós.

A saját NAS-aimon a tűzfal úgy néz ki, hogy az egyedi láncok (INPUT_FIREWALLFORWARD_FIREWALL) végén van egy olyan szabály, ami csak bizonyos országkódokat enged (pl. GB,HU), utána pedig egy végső DROP. Ez szuper biztonságos, de az UptimeRobot szerverei jellemzően több országból, különböző IP-tartományokból érkeznek.

A cél tehát az volt, hogy:

  • Az UptimeRobot IP-k kapjanak RETURN szabályt a lánc elején (icmp + TCP 5000/5001),
  • Minden más csak a GeoIP-szabályon keresztül mehessen,
  • Ezeket a plusz szabályokat automatikusan visszatöltsük minden reboot után.

1. UptimeRobot IP-k beépítése a mentett iptables szabályokba

Először kellett egy stabil, „referencia” iptables konfiguráció, amibe bele lehet injektálni az UptimeRobot IP-ket.

A lépések nagy vonalakban:

  1. Készítettem egy mentést a jelenlegi iptables szabályokról egy fájlba (fw-before-uptimerobot.rules).
  2. Ebbe a fájlba, a *filter táblán belül, az INPUT_FIREWALL és FORWARD_FIREWALL lánc végénél beszúrtam az UptimeRobot kommenteket és a hozzájuk tartozó szabályokat, például:bash# UptimeRobot – 3.12.251.153 -A INPUT_FIREWALL -s 3.12.251.153/32 -p icmp -j RETURN -A INPUT_FIREWALL -s 3.12.251.153/32 -p tcp -m multiport --dports 5000,5001 -j RETURN -A FORWARD_FIREWALL -s 3.12.251.153/32 -p icmp -j RETURN -A FORWARD_FIREWALL -s 3.12.251.153/32 -p tcp -m multiport --dports 5000,5001 -j RETURN Ugyanez a minta ismétlődik végig az összes UptimeRobot IP-re.
  3. Ügyeltem rá, hogy ezek a szabályok a GeoIP RETURN és a DROP elé kerüljenek, hogy az UptimeRobot sose essen bele a tiltásba.

Ezzel lett egy „golden” rules fájlom (fw-uptimerobot-stable.rules), amiben a filter tábla már tartalmazza az UptimeRobot számára szükséges engedélyeket.


2. Csak a filter tábla kivágása: fw-uptimerobot-filter.rules

Nem akartam az egész iptables állapotot visszatölteni, csak a filter táblát, azon belül is a saját láncokat érintő részeket. Ehhez egy egyszerű awk parancsot használtam, amivel a *filter és a hozzá tartozó COMMIT közötti rész került egy külön fájlba:

bashawk '
  $0 ~ /^\*filter/ {p=1; print; next}
  $0 ~ /^COMMIT/ && p==1 {print; exit}
  p==1 {print}
' /root/fw-uptimerobot-stable.rules > /root/fw-uptimerobot-filter.rules

Ellenőrzésként egy head és egy tail:

bashhead -n 20 /root/fw-uptimerobot-filter.rules
tail -n 20 /root/fw-uptimerobot-filter.rules

A végeredményben:

  • fent látszanak a láncdefiníciók (:INPUT_FIREWALL - [0:0], stb.),
  • lent a sok # UptimeRobot – ... komment és a hozzájuk tartozó -A INPUT_FIREWALL / -A FORWARD_FIREWALL sorok,
  • végén a GeoIP szabály és a DROP.

3. restore-iptables.sh: a varázsscript, ami mindent visszaállít

A kulcs a tartóssághoz egy kis shell script lett, amelyet a NAS bootolás után automatikusan futtatok. A script feladata:

  • várni egy kicsit, amíg DSM és Docker teljesen feláll;
  • kiüríteni az INPUT_FIREWALL és FORWARD_FIREWALL láncokat;
  • soronként visszatölteni csak azokat a szabályokat, amelyek ezekre a láncokra vonatkoznak (beleértve az UptimeRobot IP-ket).

A script tartalma:

bash#!/bin/sh

# 120 mp várakozás, hogy DSM + Docker felálljon
sleep 120

RULES_FILE="/root/fw-uptimerobot-filter.rules"

if [ -f "$RULES_FILE" ]; then
    # 1) Kiürítjük a saját láncokat az élő táblában
    /sbin/iptables -F INPUT_FIREWALL
    /sbin/iptables -F FORWARD_FIREWALL

    # 2) Csak az INPUT_FIREWALL / FORWARD_FIREWALL sorokat adjuk hozzá soronként a mentett rules-ból
    grep '^-A INPUT_FIREWALL '   "$RULES_FILE" | while read line; do /sbin/iptables $line; done
    grep '^-A FORWARD_FIREWALL ' "$RULES_FILE" | while read line; do /sbin/iptables $line; done
fi

exit 0

A scriptet elmentettem ide:

bash/usr/local/bin/restore-iptables.sh
chmod +x /usr/local/bin/restore-iptables.sh

Kézi teszthez csak futtatni kell:

bash/usr/local/bin/restore-iptables.sh &

sleep 120 miatt kell egy kis türelem, de utána az iptables -L INPUT_FIREWALL -n -v | head és az iptables -L FORWARD_FIREWALL -n -v | head már szépen mutatja az UptimeRobot IP-ket a láncok elején.


4. Automatizálás: DSM Feladatütemező

Hogy rebootok után is minden magától helyreálljon, a DSM Feladatütemezőben hoztam létre egy új feladatot:

  • Típus: Felhasználó által megadott script.
  • Futó felhasználó: root.
  • Ütemezés: Indításkor (system boot után).
  • Parancs:bash/usr/local/bin/restore-iptables.sh

Nem kötelező a &, mert a scriptben benne van a sleep 120, ettől függetlenül a rendszer ettől nem „akad meg”, a feladat simán lefut a háttérben.

Ezt a megoldást több NAS-on is ugyanazzal a logikával alkalmaztam (köztük egy DS220+), így mindenhol egységes:

  • UptimeRobot gond nélkül éri el a NAS-t pinggel és a DSM portokon,
  • a GeoIP-alapú ország szűrés és a többi tűzfalszabály változatlanul éles,
  • reboot után sem kell kézzel „igazítani” az iptables beállításokon.

Összegzés

Ez a megoldás egy praktikus kompromisszum a monitorozhatóság és a biztonság között:

  • A DSM saját tűzfalát használja, nem „tapossa szét” a Synology logikáját.
  • Az UptimeRobot IP-k külön, átlátható blokkban vannak, könnyen frissíthetők.
  • restore-iptables.sh és a Feladatütemező gondoskodik arról, hogy az egész konfiguráció tartós legyen.

Ha te is erősen szűrt, GeoIP-alapú tűzfalat használsz Synology NAS-on, és közben szeretnéd UptimeRobottal monitorozni a DSM-et (ping + webfelület), ez a módszer bevált, stabil és viszonylag egyszerűen karbantartható.