Merőben elméleti kérdés:
mondjuk van 1 doboz, több ilyenolyan vpn kapcsolattal, de nem akarom mindig mindet élőn tartani. viszont, ha jön egy adott kérés a dobozon keresztül, akkor 1-ik másikat fel kéne húzni mondjuk. Vagy valami egész hasonló feladat: valamilyen felbukkanó forgalom esetén csinálni valami dolgot.
Eleddig arra jutottam, hogy:
- logozom az adott forgalmat (iptables/nftables/pf),
- azt nézegetem valahogy,
- meglátom, csinálok, amit akarok.
Nem baj, ha OS agnosztikus a dolog, azért emlegetem a pf-t is.
Tudunk-e ennél civilizáltabb pl. protokollszintű/ netán általános (transproxy) megoldást? Mindezt lehetőleg gyorsan, közel 0 késleltetés mellett?
- 371 megtekintés
Hozzászólások
Részben fedi le az igényt a Wireguard gyári működése: ha nem kérsz tőle keepalive-ot egyik oldalon sem, akkor semmit sem forgalmaz mindaddig, míg nem jön a csatornába való adat. Ráadásul ha olyan csomagot kap, ami nem jól van titkosítva, arra semmit sem válaszol, mintha ott sem lenne a szolgáltatás az adott porton.
Az, hogy extra műveleteket végezz amikor forgalom van ezzel nincs megoldva, de az, hogy "ne legyen élő VPN kapcsolat", az maradéktalanul.
- A hozzászóláshoz be kell jelentkezni
Az IPSEC policy is működik (a legtöbb rendszeren/implementációban). Berak egy TRAP-et a kernelbe és ha érkezik matchelő forgalom akkor elindítja a tunnelt (Ike, childsa handshake-et).
Ha nincs forgalom az egyéb beállítások alapján (liftetime, rekey, dpdaction) egy idő után a kapcsolat lebomlik.
Strongswan esetén az up/down eventre lehet script hook-ot is rakni (updown plugin).
- A hozzászóláshoz be kell jelentkezni
Nem kimondottan a VPN a kérdés, valami általános megoldásra vágyom.
- A hozzászóláshoz be kell jelentkezni
Ha jól emlékszem, akkor az iptables -nek van egy nfqueue targete, amit például egy pythonban írt listener program "néz", így ha bármi érkezik rá, akkor egyből ráveti magát, és onnantól kezdve azt csinálsz benne, meg magával a beérkező csomagokkal, amit csak akarsz.
- A hozzászóláshoz be kell jelentkezni
ilyesmi, kösz.
- A hozzászóláshoz be kell jelentkezni
Vagy akár fel lehet rakni egy https://balasys.eu/hu/zorp-gpl/ -t, a konfigurációs állomány python kód, vagyis az adott forgalommal tényleg bármit meg tudsz tenni, amit pythonban meg lehet tenni, beleértve a várakoztatást (akár NOP -ok küldésével kliens felé, hogy ne szakadjon meg a TCP csatorna) amíg elindul az a program, vagy VPN, aminek a beérkező kapcsolat át akarod adni.
Az iptables+nfqueue egyszerűbb, de "egylövetű" eszköz, míg a Zorp egy kisebb csillagromboló, de hosszabb távon hasznos lehet, hogy mindent is tud.
- A hozzászóláshoz be kell jelentkezni
viszont, ha jön egy adott kérés a dobozon keresztülNem biztos, hogy ez megoldható gányolás nélkül. Ugyanis a vpn úgy működik, hogy amikor felhúzod, akkor jönnek létre a tap device-ra a route-ok, azaz amíg nincs vpn tunnel, addig elvileg nem jöhet létre "adott kérés a dobozon keresztül".
Mindenképp szükséged lesz egy shadow routing táblára, ami nem a default felé küld bizonyos csomagokat. Viszont ekkor tudsz erre a route-ra szűrni, nemtom' akár még udev-rule-t is rakhatsz a tun/tap-jára, ha engedi. Ha nem, akkor marad az iptables target gányolás, de ekkor oda kell figyelned, hogy a routing ne ütközzön.
- A hozzászóláshoz be kell jelentkezni
Függ attól, hogy egyébként a trigger forgalom hogyan van kezelve. Ha oda bele tudsz nyúlni, az is jó, ha esetleg lehet pl systemd féle socket activationnal használni a main servicet, akkor dependenciákkal rá tudsz indítani a másikra. Sőt, bizonyos esetekben akár a maga a másodlagos service is elég lehet socket activationnal.
Egyébként küldhetsz például nftablesből egy jól szűrt filterrel egy dup-ot valami local is daemonnak, ami aztán ezt triggernek használja az indításhoz. Vagy kiteheted az egészet tproxyval userspacebe, triggerelhetsz rá, és lapátolhatod tovább.
De ez a legyen általános megoldás egy kb bármilyen forgalomra, de még menjen BSDn is... szóval kissé irrelisztikusnak tetszik lenni :)
- A hozzászóláshoz be kell jelentkezni