OpenVPN remote státusz

 ( bennyh | 2014. február 12., szerda - 15:25 )

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?

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

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

Nem akarom feltétlenül bond-olni, a második csak (vész)tartalék.
Azért fontos, mert a két link sebessége között két nagyságrendnyi a sebességkülönbség a feltöltés irányába, míg egy nagyságrendnyi letöltés felöl.

hát ha nem a jó a megoldás, akkor hajrá :) Lehet scriptelni...

Már kész a script, csak kellene értelmes megoldás az openvpn státuszának lekérdezésére, hogy az írásomban szereplő naplózási gond ne jöjjön elő naponta.

/etc/init.d/openvpn status tunX

Bár én tuti nem gányolnék ennyit, főleg,hogy van kész megoldás.

openvpn konfigba:
management IP PORT

telnet-el rámész és sokat megtudsz :) Lehet kapcsolatot lelőni is, státuszt kérdezni, stb.

Egyébként a legjobb, ha mindkét VPN-t kihúzod és quagga-val osztod, hogy melyik legyen az elsődleges vonal.

Csak doksi alapján (én arra használtam a bondingot, hogy a virtuális gépem hálózata független legyen attól, hogy a host épp wifin vagy etherneten lóg), egy mode=1-es bonding nem lenne jó?
(http://wiki.centos.org/TipsAndTricks/BondingInterfaces)

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!)

Nálunk minden openvpn tunnel magától újraépül ha leszakad, szóval ezt tudja alapból.

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.

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

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

"az felet" = "afelett"? ;)
Egyébként nem biztos, hogy jó ötlet, amennyiben forgalmi díjat (is) fizetnek a vonalak után. Ugyanis valami keep-alive úgy emlékszem, akkor is megy a "dróton", ha magán a VPN-en nincs forgalom. (vagy ezt csak a pppoe csinálja?)

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.

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?

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.

Az én megoldásomban észre kell hogy vegye, hiszen a tűzfal nem engedi neki, hogy a "régi" úton kommunikáljon.
Amit keresel, az a keepalive opciónál van.
--
Debian Linux rulez... :D

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?

keepalive... Ahogy mondtam...

Illetve a /etc/network/if-*.d könyvtárakat bogarászd át!!!

--
Debian Linux rulez... :D

Még mindig nem érted, mi a gondom.
Pl érdemes lemenni ilyenre pl hogy keepalive 1 3 ? Másodpercenkénti ping 3 másodperc után bontás. Vagy mi az a minimális ping és timeout intervallum aminél lejjebb nem érdemes menni?

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

Értem én hogy gőzmozdony, de mi hajtsa? :) Akkor nincs rá recepted, próbálgassam.
Van egy kitüntetett végpont (remote server) annak mindkét ip címe fix, a másik végpontnak (client) csak az egyik lába fix a másik dinamikus, ezen az oldalon fut most a script.