Fórumok
Sziasztok,
nem igazán találtam érdemi választ a fórumok között, ezért nyitok új témát.
Adott egy Linux, ami egy irodaház internetforgalmát szabályozza. Két kapcsolat van: egy T-com ADSL és egy UPC koax.
A T-com az elsődleges, a másik kvázi csak tartalék.
A cél a hiba esetén az automatikus átállás.
Elég sok leírást van a neten - talán már egy kicsit több is a kelleténél :).
Van-e valakinek valamilyen bevált megoldása, scriptje, akármije, amivel ezt meg tudom oldani. A visszaállás nem feltétlen kell automatikusan (gondolok itt olyanra, hogy ha megszakad az ADSL, akkor a PPP egy idő után leáll, és azt nem akarom élesztgetni, hogy vajon van-e már kapcsolat).
Köszi.
Hozzászólások
en az openwrt mwan3 csomagjat hasznalom
neked aztan fura humorod van...
Mármint ezt Linuxon? Tehát nem openwrt-n, hanem valami egyéb amd64/x86 architektúrán, valami disztribúción?
A forrásfa elég sok csomagot tartalmaz, ezt le tudom fordítani egy 64 bites Debian-on?
openwrt-n hasznalom
ha neked mas linuxon kell nezd meg hogy mukodik, ugy remlik scriptek
neked aztan fura humorod van...
ha csak ennyi, akkor beállítod a PPPoE kliens-t, hogy szakadás után ne csatoljon fel újra, a másik net kapcsolathoz pedig magasabb route distance-t állítasz be.
A PPP le fog kapcsolni szakadás esetén pár(tíz) másodperc alatt, a forgalom átáll UPC-re, amikor probléma esetén javítasz, akkor "pon ISP" parancsot kiadva újra Ő lesz az elsődleges.
Hella,
igen, ez igaz - viszont olyan is van néha, hogy van PPP, de nincs net (legalábbis a T-nél már futottunk bele ilyenbe). Szal' kellene valami referencia, amit figyel, és ha az az IP nem él, akkor failover.
Mikrotik-en erre van a check-gateway opció (ami sajnos linuxban nincs implementálva, csak script-elni tudod) - ha nem a gateway hasalt el, hanem a szolgálató szakadt le a netről, akkor azt még bonyolultabb ide bevonni.
Igen, a problémák bonyolultságát sikerült megtapasztalni az elmúlt pár évben :)
pfSense
Khmm... izé:
pfSense is a firewall/router computer software distribution based on FreeBSD.
Viszont az egyik peremfeltétel:
Adott egy Linux, ami egy irodaház internetforgalmát szabályozza.
Vagy nem látok valamit, és ezt már portolták Linuxra is?
Jobban jársz egy tűzfal disztribúcióval. pfSense alatt ez a mutatvány 3 kattintás és tökéletesen működik. Ha jól értem a Linuxot csak router-ként használjátok, akkor meg cserélhető. fyi: https://community.ui.com/questions/WAN-Load-Balance-Auto-Failover/5812a…
Nem, van pár más funkciója is: egyelőre kétféle VPN, van rajta egy Squid (aminek amúgy egyre kevesebb értelme van, mivel már minden HTTPS...). Gondolom még ezek is beleférnének egy pfSense-be, de egyrészt eddig sikerült megtartani a homogén környezetet (Debian minden, ami Linux, pontosabban ami nem Windows), így aki nem expert, annak sem okoz gondot alap dolgok megoldása. Másrészt azért maradtunk a PC mellett, mert ha jön egy ötlet, hogy "hú de jó lenne ha...", akkor szerintem így a legkényelmesebb megoldani, és eddig ez is meghálálta magát.
Amúgy ha pfSense-ben megoldották, akkor gondolom egy mezei Linuxon is meg lehet oldani :). pl. az általad mellékelt linken található gwping-et (ha ez az) tegnap megtaláltam, valszeg egy próbát megér. Legalább a motiváció megvan, köszi :).
Nem tipikusan tűzfal disztribúció, de a Nethserver tökéletesen kezel akár 15 internetkapcsolatot is: https://docs.nethserver.org/en/v7/firewall.html
Igaz, én csak kettővel próbáltam :-)
Köszi, már minden mással megvagyok, szerintem egyszerűbb megoldani scriptekkel már, mint újratelepíteni, és kitanulni valami újat.
vagy lekezeled ppp up/down scriptekkel es kulonbozo route metric ertekekkel, de ugye az ellen nem ved, ha a szolgaltato gerinceben van szakadas, es a ppp el, csak nem jon rajta a "delej".
en ahol ilyen kellett, irtam egy scriptet ami percenkent lefut cronbol, megpingel 2-3 kulso ip-t (pl. 8.8.8.8) es ha nem megy akkor atirja a default route-ot es kuld egy emailt. nem szep, de mukodik. foleg olyan helyre kellett ilyen, ahol a nem megy azt jelentette neha, hogy volt ping de ugy 10-20% packet loss-al, ezt is lehet egy gyors (-i 0.1) 100-as (-c 100) ping eresztessel jol merni.
amugy az adsl-es net jobb mint a koax? ilyet is ritkan latni.
lehet, h a kérdező keveri a DSL-ről GPon-ra upgrade-lt PPPoE kapcsolattal, az tényleg klasszisokkal jobb a koaxnál
Mi a különbség? Hogy tudom kideríteni, hogy melyik van nálunk?
az adsl telefonkabelen jon, a gpon optikan
Ah, köszi - ez optika, tehát akkor Gpon.
Igen, valszeg ilyesmi lesz, és ha jól néztem, a fent írt gwping is ezt csinálja.
wpeople írta, hogy lehet, hogy keverem a DSL-ről GPon-ra upgrade-lt PPPoE kapcsolattal - lehet, nem tudom, mi a különbség. A szolgáltató DSL-ként adja, itt is PPPoE van, nem tudom, hogy lehetne kideríteni, hogy most akkor melyik.
Amúgy mintha a sávszélesség ua lenne, de a UPC koax valami elképesztően szar volt. Ha az irodaházban sokan voltak bent, akkor napközben olyan csomagvesztést produkált (60-80%, vagy több), hogy képtelenség volt dolgozni. Volt kint többször a UPC, talált érdekes hibákat (pl a fix IP ki volt osztva máshol is... khmm...), de egyik sem oldotta meg a problémát. Végül a kerületben megjelent a T-com, és azóta (ugyanazon a vason!) kifogástalanul megy a net.
aha. szoval van egy szar neted meg egy nem annyira szar ami meg szarabbul mukodik mint a masik. jo :)
volt nekem is ilyen ugyfelem, ahol mikro volt ami 3 csepp esotol is megallt, meg t-home koax kabelnet ami meg barmitol megallt barmikor. es ezen biztositsak ~100% rendelkezesre allast. 3 evig mondtam nekik, hogy vegyenek rendes netet, vegul meguntak, es szerzodest bontottak. velunk :)
Kb, bár a Gpon-ra (most már tudom :)) nem tudok rosszat mondani, mióta megvan (kb 2.5-3 éve), elég stabilan működik (mármint amikor működik :)). Ideértem a pandémiás időszakot is, amikor 15-20 user otthonról dolgozott VPN-en.
Az egyik felderített hiba az volt, hogy ahol bejön a UPC koax, szét volt ázva a csatlakozó. A szakik nagyon örültek, hogy megtalálták a hibát, de sajnos az sem oldotta meg. Utána volt a kiosztott fix IP ütközés (szintén eredménytelenül), aztán a koaxok, modem, és UTP kábelek cseréje, de normális netet nem tudtak adni. Objektíven tesztelni természetesen nem tudtuk, mert napközben a szar net is jobb volt, mint a semmilyen net, csúcsidőn kívül meg nem nagyon lehetett reprodukálni a jelenséget. És akkor sem, ha a szaki rátett egy laptopot, és elkezdte mérni a netet (egy kliensről).
:D
Amúgy nem tudom, mennyire éri meg ez a vacakolás, lehet, hogy elég lenne odatenni egy masiknet.sh scriptet, amit kézzel lefuttat bárki (van bent az irodában pár ember, aki ezt meg tudja oldani). Vagy távolról én átállítom (a UPC-s net is elérhető alapból). Tényleg ritka, mikor full elmegy a net, főleg hosszú időre - de annál bosszantóbb.
Ez azt csinálja,ping és default gw a válasz alapján:
https://gist.github.com/Apsu/5021255?permalink_comment_id=2635926
Vagy VRRP, debiánon van.https://blog.alexolivan.com/the-return-of-the-linux-router-from-pfsense-to-debian-part-4-from-carp-to-vrrp/
https://blog.claryel.hu
Érdekelni kezdett a téma és ezzel kapcsolatban akadtam rá a bondingra a Debian dokumentációjában:
https://wiki.debian.org/Bonding#Configuration_-_Example_2_.28.22Laptop-Mode.22.29
A laptopos példában a vezetékes hálózat az elsődleges és a wifi a másodlagos. A kérdező esetében két vezetékes szolgáltatás szerepel ugyan, de ehhez elég a hálózati interface neveket átírni. A leírás az RJ45-ös csatlakozó ki- ill. bedugásáról beszél és nem tudom, hogy van-e mélyebb különbség a kihúzott ill. a nem kihúzott, csak valamilyen szolgáltatói hiba miatt lerohadt kapcsolat között. Szerintetek átállna ebben az esetben is?
Ha jól értem a megoldást, akkor a bondingolt hálózati interfacere lehetne definiálni a tűzfal szabályokat és váltáskor nem kellene pingelni, új tűzfalszabályokat betölteni a másik WAN interacere ill. átírni routingot, mert a bonding elintézné az átállást a háttérben a két WAN interface ill. a bondingolt interface között?
A bonding layer 2-es redundanciát ad (gyak redundáns ethernet kapcsolatot) , a felvetett probléma layer 3.