OpenVPN remote státusz

Hálózatok egyéb

Adott egy Debian, adott egy OpenVPN kliens rajta.
Probléma:
Lenne két WAN vonal, egy nagy sebességű vezeték nélküli és egy ADSL. OpenVPN-ben meg tudok adni több remote állomást (WAN vonalanként különbözik a távoli állomás címe), de ha jól olvastam nem egyszerre használja, hanem vagy végig megy a listán az első működő remote direktíváig, vagy pedig a remote-random direktívával véletlenszerűsít a kliens, és addig próbálkozik, míg nem talál egy működő remote-t.
Namost. Azt szeretném, ha az első, nagy sebességű vonalat használná, amíg lehet. Ha megszakad, akkor átmenjen a másodikra (eddig megy is gyárilag), viszont jó lenne ha visszaugrana a nagy sebességű vonalra, amint lehetséges.
Megoldási kísérlet (nem túl elegáns). Figyelem 5 percenként (cron-nal időzítve) egy script-ből a naplókat, kiolvasom a legutolsó openvpn csatlakozási eseményt, ha nem az első remote ip cím szerepel ott, de meg tudom pingelni , akkor újraindítja az openvpn dameont (azt még nézegetem, lehet szerencsésebb lenne a sigusr1 szignál küldése, de nem tudom, akkor is előről kezdi-e a remote sorok beolvasását). Csak ugye a napló rotációs (mint a kapa :D), lehet már egy idő után nem tudom kiolvasni az utolsó kapcsolódási esemény infóit.
Kérdések:
-Hogy tudom naplók nélkül kiolvasni, hova csatlakozik a kliens?
-Ennél a mechanizmusnál, amit felvázoltam, nincs valami egyszerűbb és biztosabb?
-Újraindítás nélkül rá lehet-e venni az openvpn-t, takarodjon vissza az első remote-ra?

  • 9022 megtekintés

( kallaics | 2014. 02. 12., sze – 15:51 )

Amit keresel az a bonding. Mindkét kapcsolat aktív,de csak a master él. Ha meghal a master kapcsolat, akkor a szerver átteszi a forgalmat a másik vpn-re. Miért fontos,hogy melyik aktív?

Doksi: https://wiki.debian.org/Bonding

( Zs | 2014. 02. 12., sze – 18:04 )

Az OpenVPN amikor kihúzza a kapcsolatot, akkor hat marék scriptet futtat - ezek közül egy pl. az ip-up script. Itt valamelyikre drótozd rá a magad kis cuccát, hogy tegye le pl. a /tmp alá egy file-ba, hogy melyik IP-hez sikerült kapcsolódni. (Ok, ha nincs más, ez is bogarászható a logból.) A lényeg, hogy innen kezdve az eredeti kis script már nem a log-ból vadássza fáradtságos munkával, hogy ki az aktuális partner, kockáztatva azt, hogy a logrotate még ki is nyesi alóla a file-t és így találat sem lesz - hanem simán felveheti ebből a file-ból.
Sajna olyan opcióról nem tudok OpenVPN alatt, hogy egy létező kapcsolatot magától csak úgy újrahúzzon - de ezt ha jól értem, a te eredeti kis scripted megoldaná és persze csak akkor, ha érdemes is.

Ha nagyon újraindítás nélkül akarod a daemonnal újrahuzatni a kapcsolatot, akkor egy randa de működő megoldás lehet, hogy iptables szabállyal keresztbe teszel az élő de lassú kapcsolatnak, így az szakad, ezt az openvpn észleli és a reconnect során ismét próbálkozik az első kapcsolattal, ami már él, így igazából elérheted azt, amit akartál. (Csak azután ne felejtsd el kivenni a tiltó szabályt, ha már nem kell - különben soha többet nem csatlakozol a lassú vonalon!)

Akkor nem érted, mi a gond. Itt is újraépül, a másodikon, ha az első szakad, de ne az maradjon tartósan, hanem amint lehet csatlakozzon újra az első remote-ra, mert rohadt lassú.
Lehet nálatok eleve több vpn tunnel van esetleg valamilyen routing protokollal megspékelve, talán ospf alapú útválasztás a költségeket beállítva itt se lenne rosz, de nem akarnám túlbonyolítani.
A status parancsot nekem nem értelmezi csak az /usr/sbin-ben lévő bináris, és az is fájlba akar írni állandóan.
Asszem a Zs kolléga megoldási javaslata lesz a nyerő.

+1

Az OpenVPN rengeteg scriptet használ + vannak "hook"-jai is, ahol további scripteket lehet hozzá adni. Más szóval az openvpnnel ezt önállóan meg tudod oldani kiegészítő script hozzá adásával, nem kell se logot se mást túrni hozzá. (Én egyébként tűzfalszabályok dinamikus módosítására használom ezt a lehetőséget. Meg szerver oldalon tartok egy kis file-t, ahol mindig nyilván tartja ki van kapcsolódva és milyen ip-t kapott, így nem kell semmit túrni, ha rá akarok nézni).

Zavard össze a világot: mosolyogj hétfőn.

( Elbandi v | 2014. 02. 12., sze – 21:12 )

ket vpn kulon a vonalakra, az felet meg standard failover routing

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Mondjuk nincs forgalmi díj.
Amúgy próbáltam pár dolgot.
Próbáltam egy egyszerű scriptet (ami kíírja egy állományba a kapott paramétereket) berakni úgy hogy up [scriptnév elérési útvonallal] de már el se akart indulni az openvpn, talán valami jogosultság gond, de nem kutatgattam tovább.
Próbáltam a daemon újraindítás helyett egy sigusr1 jelzés küldést a daemonnak, de csak az épp aktuális kapcsolatot indította újra, nem ment vissza az első remote-ra.
A sigusr2 küldést is kipróbáltam a napló fájl elemzésének segítéséhez, de csak annyit ír, hogy köszi jól van és csá, semmi olyat amit fel tudtam volna használni, pl az épp aktuális remote host IP címe.

Most egyelőre azt csinálom, ha a naplóban nincs benne semmi infó a legutolsó csatlakozásról vagyis üres marad a változó, (napló csere esetén pl, de szerencsére ez mindig hajnalban történik) nemes egyszerűséggel ugyancsak reseteli az openVPN-t. Végül is működik, mert a cron nem dob olyan üzenetet mostanában, hogy unary operator vagy hasonló és nem is ragadt be lassabb sebességen eddig a vonal.

( Foltos | 2014. 02. 18., k – 09:52 )

Szia!

Csak pár ötlet:

-Hogy tudom naplók nélkül kiolvasni, hova csatlakozik a kliens?
"netstat | grep openvpn" vagy hasonló?
Illetve ezt nézted már?

-Újraindítás nélkül rá lehet-e venni az openvpn-t, takarodjon vissza az első remote-ra?
Esetleg iptables -sel eldobatni a csomagjait amíg timeout -ol?

( Swifty v | 2014. 02. 18., k – 13:46 )

Anno diplomamunkaként írtam egy kiegészítést az iptables-hez.
Ez megtalálható az xtables-addons-ban... (iface)

Ez a kiegészítő "figyeli" az interfész állapotát.
Pl. így használnám:

iptables -t filter -A OUTPUT -j DROP -p udp -d $MASIK_GEP_MASODLAGOS_IP --dport 1194 -m iface --iface $ELSODLEGES_INTERFACE --up

Ez nem enged a másoldagos IP cím felé forgalmazni, ha ez első inferfész "up" állapotban van... (És persze conntrack ellenőrzés elé kell tenni...)

--
Debian Linux rulez... :D

Nem rossz ötletek, viszont akkor visszaállásnál megint lesz egy szép hosszú 10-25 másodpercnyi szakadás.
Míg az "/etc/init.d/openvpn restart" parancs kiadása esetén, ha közben folyamatosan pingelek a vpn-en át akkor egy vagy egy sem vész el az icmp csomagokból, látszólag.

Ha UDP alapú a VPN csatorna, akkor mit érdemes beállítani, hogy gyorsan észrevegye a fizikai kapcsolat szakadását? Próbáltam 4 ping-ről 3-ra állítani és 3 sec-es időközre a pingek számát, de így is sok idő míg észreveszi az openVPN.

( bennyh | 2014. 02. 26., sze – 11:29 )

Nem az a gond, hogy nem veszi észre!
Az a gond hogy addig 20 másodpercre lehal a háló, míg egy openvpn restart a másodperc töredéke alatt lefut és újracsatlakozik. Mi az az ésszerű legkisebb keepalive beállítás, ami jó mind ADSL, mint bérelt vonalszerűség esetén?

Még mindig nem érted, mit írok. :D

Az hogy mi a minimum, azt neked kell kitapasztalnod. Lehet 1 3-at is megadni, de akkor mindenféle kapcsolaton keresztül folyamatosan lesz adatforgalom, még akkor is, amikor semmi más sem történik.

A VPN gyakorlatilag becsomagolja a két végpont közti csomagokat, és átküldi a tunnel-en.

Én még mindig azt csinálnám, hogy használnám az iface kiegészítést, és mondjuk még NAT-olgatnék is közben.

Mindkét végpont-nak fix IP-jei vannak?

--
Debian Linux rulez... :D