OpenVPN csatlakozás alternatív IP címre

Hálózatok egyéb

Sziasztok!

OpenVPN-t használunk arra, hogy otthon levő kollégák is tudjanak dolgozni.
A kérdésem az volna, hogy egy ovpn állományban meghatározott csatlakozást be lehet-e úgy állítani, hogy ha az elsődleges IP címre nem tud csatlakozni, akkor próbáljon meg ugyanezt egy másodlagos IP címmel?

Két internetcsatlakozást használunk arra, hogy ha az egyik kiesik, akkor gyorsan tudjunk váltani (a két szolgáltatás természetesen két külön szolgáltató két külön optikán).

 

Gábor

  • 993 megtekintés

( ggallo | 2024. 12. 16., h – 15:48 )

Lehet több --remote sorod, amit vagy a konfig sorrendben, vagy --remote-random esetén véletlenszerűen próbál a kliens.

A kapcsolat időkorlátaival pedig be tudod állítani, mikor tekintse hibásnak a kapcsolatot és próbáljon újat létesíteni.

( arpi_esp v | 2024. 12. 16., h – 16:08 )

igen lehet

> természetesen két külön szolgáltató két külön optikán

ami valojaban egy optikai kabel csak egyik berli a masiktol :)

sok településen a Diginek és a T-nek is van külön külön saját gpon hálózata.
Fixme, de a Digi (mint 4iG leányvállalat) már sokkal inkább saját berkekben oldja meg a településen lévő hálózat (jellemzően redundáns) uplinkjét - minthogy a T-től béreljen.

Konkrétan amikor a Digi megvette az Invitel lakossági üzletágát, akkor a gerinchálózati kapacitásból is részesült...

( dorsy v | 2024. 12. 16., h – 16:51 )

Szerkesztve: 2024. 12. 16., h – 16:52

Legyen a cegnek havi 5-10 EUR-ja egy VPN VPSre?
Minden masra ott a dyndns.

miert allna meg? (minden masra ott az SLA)
a nem 10 eur-ba kerulo berelt vonal (ketlem, h az...) nem fog megallni? :)
hint: nem ket lakossagi fos 72-oras "megkezdjukahibaelharitast" kategorias netet kellett volna alapbol bekottetni? :)
ha mar szarbol epitjuk a varat, nem a VPS rendelkezesre allasa lesz a szuk keresztmetszet...

Ok, ez jogos is, ha napi többszöri kiesés van az irodai vonalakon, ami bosszantó rendszeres újracsatlakozást okoz a felhasználóknál munka közben.

De ha nem ez a helyzet (itt szerintem nem ez két optikai vonalas előfizetéssel), hanem tuti-ami-biztos miatt van a második vonal, akkor felesleges pénzköltés és plusz munka még egy (több) VPS bevonása.

attol fugg.
pl. ha a vegso megoldas a rendelkezesre allas novelese (szerintem a kerdezo - vagy a fonokei - ezt szeretne elerni), ez a kezdete lehet az irodai infra jobb helyre koltoztetesenek. (nem valami koszos home grade net moge)
es ha "kattogvillog" a net, azt a round robin IP-re csatlakozgatas nem fogja neked megoldani; ugyanugy szakadozni fog a user szemszogebol a vpn...

( Luckye | 2024. 12. 17., k – 10:15 )

[Off]
Jól elment a beszélgetés. Bírom, hogy felteszek egy kérdést egy problémáról és a hozzászólások döntő többsége nem a probléma megoldására tesz javaslatot, hanem arra, hogyan oldjam meg másképp (vagy hogyan kerüljem ki). És ez nem csak erre a kérdésemre igaz, hanem az összesre...
[/Off]

ggallo hozzászólása volt a megoldás, köszönöm neki!

A hálózat szakadozása nem jellemző, alapvetően meg vagyunk elégedve a rendelkezésre állással, nem is célom az, hogy a net megszakadása észrevétlenül, szakadásmentesen biztosítsa a kapcsolatot, csak az, hogy egyszerűen, néhány kattintással át tudjunk állni a másik kapcsolatra. Igaz ez a vpn kapcsolatokra is.

Gábor

mifele ket berendezes? mifele kezi matyizas? ez egy klasszik failover dual uplink. nem a kerdezo az elso, akinek ilyenje van/volt/lesz...
egy berendezesen illik kezelni a forgalmat, ami a bastyagep. annak az aktualis defaultGW fele nezo publikus IP-je tokeletes ennek a feladatnak az ellatasara... ha pedig a vpn megdoglott, mar ugysincs mirol beszelgetni.
es igen, a kovetkezo kerdes az, mi van akkor, ha a dyndns doglik le? jaigen, erre irtam fentebb, h VPS, ahova az iroda meg a kliensek is csatlakoznak... :) GOTO 10

azert jo a problema, mert ezer fele jobbnal jobb es szarabbnal szarabb megoldas van ra, tobbek kozt pl, hogy a dyndns-t sem feltetlen az ujitja, akinel az ip van, hanem mondjuk a monitoring (ami szinten tok jol elvan egy 10 EUR VPS-en :P), ami figyeli, hogy melyik az aktulis elerheto pubIP-d. mondjuk. is. akar. vagymondjuk https://serverfault.com/questions/528742/can-i-have-2-a-records-for-the… ha mar ket IP-d van... :) esakkor szorakozhatsz a conntrackkel, hogy ki melyik IP-n jott be, az is erdekes hazi feladat :)

"routert/vpn-t is rakhatsz HA cluster-en VM-be, ha ez a fetisizmusod." - azaz rögtön jön az, hogy melyik "hirdesse" magát a dyndns-felé... Ha a kliens dönt, akkor bizony ott egyszerűbb a failover-t megoldani a kapcsolódásnál, ahogy azt az openvpn konfigja lehetővé is teszi... Faék egyszerű a kliensen, faék egyszerű a szerver oldalon... Aztán hogy a "kifelé" irányt hogyan oldja meg a rendszer, az más kérdés...

csak epp ami szerinted a mas kerdes, az a valsoagban ugyanugy a problema resze :) bingo. dual A-rekorddal pedig megcsak konfigot sem kell hakkolgatni hozza es barmikor valthatsz IP-t alatta, anelkul, h sz*patnad a usereket Zinformatikus kollegat a konfigvaltassal. :)
de felolem mindenki ugy szivatja magat es a kollegait static IP-kkel a konfigokban, ahogy akarja :D

A DynDNS-el és egyéb DNS alapú failover-el az a baj, hogy a cache-elések és TTL-ek miatt nem tudhatod, hogy a kliensnél valójában mennyi idő alatt frissül be az infó. Erre a VPN feladatra a legjobb, ha az egész rendszer úgy van felépítve, hogy bármikor bármelyik vonal használható (vpn1. és vpn2. külőn A record-on bejegyezve - hogy szükség esetén akár IP-t tudj változtatni alatta - és mindkettő felvéve a kliens configjába), amennyiben épp működöképes. Szóval, valójában egyben load balance is.

"Probléma esetén nyomják meg a piros gombot és nyugodjanak békében!"

Dinamikus IP-n szolgáltatást, mégpedig rendelkezésre állás/elérhetőség szempontjából kritikus szolgáltatást nyújtani ősi... Na szóval fillér...ó szokás.

"annyi TTL-t adsz neki amennyit akarsz"

Amely TTL-t úgy vesz figyelembe a kliens OS cache, a kliens resolvere és az általa használt NS, ahogy akarja.

ha nem te uzemelteted az os-t, akkor ott nincs IT... ha te tudod melyik link el es te mondod meg az melyik IP, annak vannak elonyei. peldaul, h nem a kliensre bizod hol/merre probalkozzek. :) es nem a kliensen, egyenkent kell karban tartsd az ip-ket. erre szuletett a dns... sot, kombinalhatod is, mondhatod, h vpn1.olcsojanos.hu meg vpn2.olcsojanos.hu...

Mi a baj az IP váltással? Normális rendszer alatt az ember szökőévente (sem) vált IP-t. Akkor meg tervezetten átírod a DNS recordokat és ráérsz megvárni, míg mindenhol befrissül. (de ha dinamikus IP és DynDNS, akkor is, amíg egyik mögött változik az IP, addig a másik zavartalanul működik a kliens számára)

Használhatsz saját DNS szervert, persze, meg az összes kliensedet is egyenként rákényszerítheted, hogy ők is azt használják - csak minek?

A csavart nem biztos, hogy kalapáccsal kell beverni! ;)

"Probléma esetén nyomják meg a piros gombot és nyugodjanak békében!"

ha nem latod az elonyet annak, hogy te mondod meg mikor minek mi az ipje, az nem az en problemam :)
hint: a legtobb normalis dns szolgaltatonak van API-ja is. megcsak az sem feltetlen kell, h nalad legyen.
normalis rendszer alatt nem megy el a berelt vonal, meg nincs aramszunet sem... szokoevente sem. :)
itt jelenleg a szarbol varat epites a tema. imho.

Nem, az alternatív megoldás nem biztos, hogy megoldás. Ugyanis sokszor az alternatív megoldás nem arra ad választ, amit kérdeztem. Itt például nem ad választ arra, hogyan lehet az openvpn configot több IP címre beállítani, csak arra, hogyan oldhatom meg a magasabb rendelkezésre állást. De a kérdés nem ez volt.

Szerintem az mindig hasznos tud lenni, ha ismert az eredeti problema/feladat, mert arra tobb jo megoldas is lehet, jelen esetben te mar elindultal egy uton, ahol lett egy konkret kerdesed (es szerencsere valaszod is).
Az alternativ megoldasok, ahogy irtad is nem mindig jo megoldasok, de megis segithet kicsit mas iranybol is megkozeliteni a problemat es kihuz egy rabbit hole-bol, amibe esetleg sikerult belefutni es bent ragadni.

Ez komplexebb kérdéseknél valóban működik, de amikor onnan indulsz, hogy "na, akkor kellene x meg y dolgot venni, és ez-az-amazt konfigurálni" miközben a kérdésből süt, hogy ő már tart valahol a mostani megoldással, és valami nagyon konkrét dologra kérdez rá, akkor nem nagyon segítenek az alternatív megoldások, azt éred el vele, hogy csak a bosszúság növekszik, hogy "feltettem egy egyszerű kérdést, miért nem írja akkor azt, hogy fingja nincs".

Én főleg ezért kérdezek itt ritkán, és nagyon defenzíven, mert a legtöbb esetben nagyon pontosan tudom, hogy miért azt a megoldást akarom, van egy infra, amibe ezt tudom beilleszteni (de vagy nem tudom, vagy nem akarom megosztani a többi részletet kéretlenül), kérdeztem valamit, elsősorban arra várok választ.

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-