Szolgáltatói IP cím váltás hatása a belső DHCP kliensekre

 ( lbaan | 2016. december 13., kedd - 12:54 )

Adott egy csomó felügyelet nélküli Debian-os gép. Az IP DHCP-n jön a helyi router-től. Az ISP fogja magát és IP-t vált. Ezt a router le is kezeli, de de erről a DHCP lease time alatt nem értesülnek a kliensek. Így a kapcsolatok (pl. OpenVPN kliens) leszakadnak a szerverről. A dolog a DHCP lease time lejárakor "magától" vagy "kézi" networking restart-ra jön helyre. Sajnos a DHCP szerver elég hosszú időt ad (órák~napok) és a router konfigba nem lehet belenyúlni. Viszont ilyen hosszú kiesés nem tolerált. A jelenlegi workaround egy távoli szervert pollingoló szkript. Kérdésem, hogy van-e erre valami kulturált megoldás. Előre is köszönöm az ötleteket!

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ő.

openvpn konfigban keepalive paraméter megfelelő beállítása...

ez természetesen megvan, emiatt tud újra felcsatlakozni amikor a DHCP frissül. De ez sajnos kevés, mert minden, amit a DHCP szerver korábban megadott a külvilágról, már a semmibe mutat.

mit ad meg a külvilágról a dhcp szerver?

http://unix.stackexchange.com/questions/222321/how-to-make-openvpn-to-autoreconnect-to-gateway-at-any-time

"If the peer cannot be reached, a restart will be triggered, causing the hostname used with --remote to be re-resolved (if --resolv-retry is also specified)."

Hátha segítség. Egyébként mit értesz az alatt, hogy "minden, amit a DHCP szerver korábban megadott a külvilágról, már a semmibe mutat"? Szerintem belső hálózaton nem ad a DHCP olyan beállítást a kliensnek, ami miatt a publikus IP-cím változásakor elveszne a belső gépek internetkapcsolata, a default gateway és a DNS szerverek címei állandóak.

+1
A dhcp összefüggést én sem értem hogy jön ide


// Happy debugging, suckers
#define true (rand() > 10)

Nekem 1 tippem van csak, de ahhoz elég sok feltételnek kellene teljesülnie, ami nem lehetetlen de nem is túl valószínű:
1. a VPN DNS alapján megy
2. nincs helyi DNS hanem a router kiosztja azt a DNS-t amit kap az uplinken
3/a. a szolgáltató más IP esetén más DNS-t ad meg, és nem megfelelő kliens esetén dobja a kapcsolatot
3/b. 2 uplink és 2 szolgáltató, ha átáll backup-ra akkor elvész a névfeloldás
4. aztán jön egy DNS timeout

De ez eléggé erőltetett, bár nem lehetetlen. Ha ez van akkor WAN címváltás után névfeloldás nincs, de IP alapján megy a kommunikáció.

Ha ez a helyzet akkor akár megoldás lehet bedrótozni egy 8.8.8.8-at, de szerintem a jó megoldás a polling és kiesés esetén egy dhclient restart (nevezzék azt akárhogy az adott rendszeren). Már ha a router szent és sérthetetlen...

2: kiosztja azt amit kap. A mostani sufnituning a 8.8.8.8 és a polling->restart.
Láttam olyat, hogy amikor a amikor a router éppen átáll, akkor átmenetileg "két szék között a pad alatt" állapot van. Pl. a T csapat mifelénk szereti újraindítgatni éjszakánként az eszközöket. Ilyenkor a DOCSIS minden csatornán 0dB-t ad, uplink nincs (minden 0.0.0.0). Optikán is előfordul, csak ott nem tart percekig. A mobilnetes routerrel is előáll, pl. amikor kétkártyás felállásnál átvált a hálózatok között.

Nálam otthon egy olyan buta szolgáltatói hgw van, amin nem lehet mac-ip hozzárendeléseket sem beállítani. A megoldás az lett, hogy egy filléres tplink wr841 openwrt-vel működik dhcp szerverként, csak persze nem saját magát, hanem a szolgáltatói routert reklámozza átjáróként, dns szervereket is ott határoztam meg. Értelemszerűen lan-lan portok vannak összekötve a két eszköz között. A szolgáltatóin pedig le van tiltva ez a szolgáltatás. Így a klienseken nem kell varázsolni. Lehetne valami kompaktabb eszköz is akár, de ez kéznél volt. Máshol másra pedig nexx wt3020-at használok.

Persze nálatok, sok helyen ez nem biztos, hogy megoldás, mert konfiguráli kell és plusz hibalehetőség.

sajnos a routerbe nem látok bele, csak a szomorú tények vannak: amíg nincs dhclient restart, addig nem jut ki a kapcsolat a szerverhez. Van olyan router/szolgáltató, ahol ez sohasem fordult elő (évek alatt), és van, ahol heti rendszerességű a probléma. Ilyenkor persze ránézni sem tudok, mert nincs VPN. Szóval próbálom körbelőni a problémát.

dirty hack, de... az openvpn tud futtatni scripteket is, sőt olyan perverzióra is rávehető, hogy tartsa UP-ban az interfacet, de ezzel együtt fussanak le szakadáskor a down-, kapcsolat ismételt felépülése után pedig az up-scriptek. Tehát ha rábeszéled erre az openvpn-t, majd készítesz down scriptet, amiben megbirizgálod az eth0 állapotát (ifdown eth0, ifup eth0; egyéb :-)), akkor szakadáskor maga az opnvpn is belerúghat egyet a DHCP-be.
Mondjuk sok minden eszembe jut erről a megoldásról, de az hogy szép lenne, na az nem. De ha adott egy ilyen DHCP szerver és nem módosítható a konfig, akkor...

ifdown eth0 sajnos nem játszik, mert azzal kinyírom a fix IP-s helyi kapcsolataimat is.
Az eth0:1 fix IP-n megy a többi eszköz miatt.

normalis router.

+1

szerintem is. Csak sajnos a routert (vagy akármilyen uplink kijáratot) nem mi adjuk, hanem adottság: azzal kell főzni amit kapunk.