A diagnózis: Miért ölte meg a VPN-t a 4G?
A kiindulási alap egy tipikus ipari környezet volt, ahol a térerő gyenge volt, a torony pedig túlterhelt. Csak a Teltonika RUTX11-es router Cat6-os LTE modeme tudott egyáltalán kapcsolatot teremteni a külvilággal. A nyers sávszélesség-tesztek 15-20 Mbps letöltést mutattak, ami papíron elég lett volna.
De a valóságban a terhelt ping 500 ms felett járt. A legnagyobb ellenségünk nem a térerőhiány volt, hanem a Bufferbloat. Az adatcsomagok torlódtak a szolgáltató túlterhelt hálózatán és a router belső memóriájában, ami megölte a valós idejű kommunikációt.
Gyakran szoktuk mondani, hogy irányítsátok a készüléket az adótorony felé.
Ok, de merre vannak az adótornyok?
A toronyhelyzet elemzéséhez a CellMapper nevű kiváló közösségi eszközt hívtuk segítségül, amivel pontosan azonosítottuk a kiszolgáló cellát és annak a fizikai paramétereit. Bár a fizikai jelszinteken sokat nem tudtunk javítani, a diagnózis egyértelmű volt: szoftveresen kell megvédenünk a hálózatot a saját maga által generált dugótól.
Dávid és Góliát: A modern mobilok illúziója
Itt térjünk ki a leggyakoribb ügyfél-szituációra: „Miért szenvedünk az ipari routerrel, ha az iPhone 14-em 180 Mbps-ot tud ugyanott?” Ez a Dávid és Góliát klasszikus esete, ahol a látszat csal.
A zsebedben lévő modern telefon egy sprinter. Cat18/20-as modemmel, 4x4 MIMO antennával és 4-5 frekvencia egyidejű összefogásával (Carrier Aggregation) képes egy másodpercre brutális sebességet elérni, hogy letöltsön egy weboldalt.
A RUTX11 viszont egy maratonfutó. Cat6-os modemmel és ipari antennákkal „csak” két frekvenciát használ, de azt hónapokon keresztül, folyamatosan és megbízhatóan fogja biztosítani. Ipari VPN-eknél pedig a betonstabil, kiszámítható 20 Mbps mindig többet ér, mint az ingadozó, ugráló 180 Mbps-os sprinter illúzió.
A megoldás 1. rész: A puffer megfékezése a RUTX11-en
A RUTX11-en a Smart Queue Management (SQM) algoritmust hívtuk segítségül.
Lépés 1: A hardveres gyorsítás (HW NAT / Flow Offloading) KIKAPCSOLÁSA.
Ez a lépés fájdalmas, de szükséges. A hardveres gyorsítósáv „vak” az SQM számára. Ha be van kapcsolva, az SQM nem lát rá a csomagokra, és nem tudja sorba rendezni őket.
Lépés 2: Az SQM finomhangolása.
A RUTX11 processzora Offloading nélkül nagyjából 50 Mbps-ig képes szoftveresen kezelni az SQM-et (piece_of_cake). Mi a ~20 Mbps-os valós 4G sávszélesség alá lőttük be a korlátot (pl. 18000 / 4000 kbit/s).
Az eredmény azonnali volt: a ping a korábbi 500 ms-ról betonstabil 30-40 ms-ra esett vissza terhelés alatt is. Ezzel a VPN alagút válaszideje kisimult.
Hogy vizuálisan is megértsd a különbséget a „dugó” és a „stabil válaszidő” között, készítettünk egy interaktív szimulátort, ami megmutatja a csomagok torlódását.
Interaktív Bufferbloat Szimulátor
Próbáld ki az interaktív szimulátort! Húzdd a csúszkát, majd kapcsold be az SQM kapcsolót.
Mit jelent a „100% feletti” terhelés a szimulátorban? (A Tölcsér-effektus)
Amikor a szimulátorban feltolod a csúszkát 100% fölé, jogosan merül fel a kérdés: Hogyan lehet a hálózatot jobban terhelni, mint amekkora a maximális kapacitása?
Képzelj el egy műanyag tölcsért!
A tölcsér szűk, alsó csöve jelenti a szolgáltatódtól kapott maximális internetsebességet (mondjuk 100 Mbps). Fizikailag ennyi adat tud átfolyni rajta másodpercenként. Nincs mese, ez a cső átmérője.
Amikor azonban elindítasz egy hatalmas letöltést, vagy több gép is elkezd egyszerre adatot forgalmazni, a belső hálózatod nem finomkodik: szó szerint egy egész vödörnyi vizet (mondjuk 150 Mbps-nyi adatot) zúdít rá a tölcsérre egyszerre. Ez a 100% feletti terhelés. Több adatot akarsz átpréselni, mint ami kifér.
De mi történik ilyenkor?
A Puffer (Buffer): Ahelyett, hogy a hálózat azonnal eldobná a felesleges vizet, a szolgáltatói modem memóriája (a tölcsér táguló, felső része) elkezdi összegyűjteni és tárolni az adatcsomagokat.
A Ping elszáll: Ahogy a vízszint egyre feljebb ér a tölcsérben, a legújabb vízcseppnek (egy új adatcsomagnak) egyre többet kell várakoznia a sorban, mire egyáltalán lejut a csőbe. Ez a várakozási idő az, amit mi megemelkedett Pingként (500+ ms) láttunk. Ezt hívjuk Bufferbloatnak.
A Túlcsordulás: Ha a tölcsér teljesen megtelik, a víz egyszerűen kifolyik a szélén. A hálózatban ez a csomagvesztés (szakadás), amikor megszakad a hangod a Teams hívásban.
Mit csinál az SQM?
Amikor bekapcsolod az SQM-et (Smart Queue Management), lényegében egy okos forgalomirányítót állítasz a tölcsér fölé. Ez a szoftveres rendőr még azelőtt megállítja a „vödörnyi vizet”, mielőtt az beleömlene a tölcsérbe. Pontosan akkora tempóval (cseppenként) engedi csak be az adatot, amekkora biztosan, azonnal átfér az alsó szűk csövön.
Az eredmény? A tölcsér sosem telik meg, így egyetlen adatcsomagnak sem kell várakoznia. A letöltésed folyamatos marad, a Pinged (válaszidőd) pedig betonstabil lesz!
A megoldás 2. rész: A Központ Megmentése (Gigabites Aszimmetria)
A hálózat túloldalán egy kábeles gigabites kapcsolat volt (1000/50 Mbps), egy Teltonika RUTX10 routerrel. Amikor a központban az eszközök elkezdtek letölteni a 1000 Mbps-os ágon, a háttérben ezek a gépek másodpercenként ezer visszaigazoló csomagot küldtek fel a szűk, 50 Mbps-os feltöltési csövön. Az 50 Mbps bedugult, Bufferbloatot okozott, és a VPN alagút összeomlott.
Mérnöki Csapda: Ha a RUTX10-en kikapcsoljuk az Offloadingot, a processzor szoftveresen legfeljebb 300-350 Mbps-ig tudja kezelni a letöltést, és a gigabites net a harmadára esik.
Az „Aszimmetrikus SQM” trükk
Csaltunk, de mérnöki precizitással. Visszakapcsoltuk a RUTX10-en a hardveres gyorsítást (HW NAT - ON), hogy a gigabites letöltés hasítson a router expressz sávján, és ne terhelje a processzort.
De... az SQM beállításokban a letöltést (Download) 0-án (korlátlanul) hagytuk, a feltöltést viszont manuálisan korlátoztuk 45 Mbps-ra (piece_of_cake).
Az eredmény:
- ✔ A számítógép hasított ~860 Mbps-mal (hála a HW NAT-nak).
- ✔ A RUTX10 processzora nevetve lekezelte (Offloading miatt).
És a legfontosabb: Az SQM megvédte a 50 Mbps feltöltést a dugulástól. A visszaigazoló csomagok kényelmesen kifértek, és a VPN alagút válaszideje ezen a végen is betonstabil, 15-20 ms maradt!
Összegzés: A stabilitás a legfontosabb sávszélesség
Ez a projekt bebizonyította, hogy egy modern hálózatépítésnél a sávszélesség (Mbps) csak egy illúzió. Ipari VPN-ek és valós idejű alkalmazások (NAS elérés, kamerák) esetében a stabil, puffermentes válaszidő (Ping) mindennél többet ér.
Sikerült egy reménytelen, 4G-s környezetből egy betonstabil kapcsolatot kihozni a Teltonika RUTX sorozatával, de ehhez szükség volt:
- ✔ A CellMapper-es diagnózisra.
- ✔ A Dávid és Góliát illúzió elengedésére.
- ✔ Az SQM és a HW Offloading intelligens, aszimmetrikus kombinálására a hálózat két végén.
