classic.ISPforum.cz

Zdravím, potřebuji na domácí testování nějak zajistit zálování NAT serveru. Připojení mám následující ISP -> RB433 -> server -> vlastní síť. RBčko mi slouží pouze jako HW firewall. Občas se stane, že server zamrzne a síť pod ním není dostupná. Veškeré síťování mám zajištěné pomocí VLAN a tak není problém, v takovém případě RBčko připojit na VLAN sítě za serverem, nastavit NAT i DHCP a celý server tak obejít. Potřeboval bych to ale zautomatizovat.
Řešení č.1: na RBčko vytvořím script, a jakmile neprojde cca 10 pingů na server, startuji vlastní NAT a DHCP pomocí kterého změním výchozí bránu.

Řešení č.2: Ta VLANka mezi serverem a vlastní sítí bude mít třeba adresu 10.10.10.0/24. Na serveru pojede DHCPko s NATEM pro tuto síť. Zároveň ta VLAN bude připojena do RBčka ovšem na adrese 10.10.200.0/24. Na RBčku bude NAT a DHCP server čekající 10s na odpověď. Jakmile server vypadne, zařízení se automaticky přepojí do jiné sítě. Čas platnosti DHCP záznamu bych nastavil na 10-30 minut.

Existuje nějaké třetí řešení? Jaké jsou nevýhody jednotlivých postupů? Výhodu druhého řešení vidím pouze v tom, že nemusím řešit psaní scriptu. Jinak mi připadá první řešení takové čistší.

A nebude lepší pořešit příčinu, proč ten server padá?
Takhle řešit následek je jak drbat se levou nohou za pravým uchem.

Příčina je, že se v tom hrabu. Teď budu kupovat KVM kartu, aby bylo možné server popostrčit, ale i tak potřebuji prostě jistotu, pro případ co kdyby.

Na něco, co funguje, se přece zásadně nešahá.

Jinak varianta 2) nebude dělat co chceš. I když RB bude opožděno o 10 sec, tak co mám vyzkoušeno, tak stejně nějaký klient nakonec dostane adresu od záložního routeru a ne primáru. A navíc, kdo dostane IP od záložního DHCP, tak se ho bude držet jak sopel, prootže při vypršení leasu se snaží primárně snaží kontaktovat přímo původní DHCP server a pokud tne bude odpovídat, tak si bude držet IP od něj. A budeš mít v LAN po čase slušný chaos. Vyzkoušeno.
To by to záložní DHCP musel úplně ztichnout, když jede primár. MKčku chybí funkce pro spolupráci DHCP serverů a synchronizaci, případně HA mezi sebou.

Varianta 3) RBčko s Linuchem propojíš VLANou přes kteoru jde provoz přímo do netu jako teď, na RB hodíš další VLAN nebo ether port, který bude přímo na LAN, třeba ta 10.10.10.0/24. Na linux na ethX dáš IP 10.10.10.1/24, na MKčko na etherX 10.10.10.2/24. Dále pustíš na MKčku VRRP nad etherX, stejně tak si pustíš na linuxu vrrpd nebo keepalived nad ethX s tím, že budou držet IP 10.10.10.254/32, adresa .254 bude defualt brána ven. DHCP pustíš na linuxu i MKčku se stejným nastavneím, jenom pro dynamick přidělované rozsahy dáš třeba, ať linux přiřazuje z bloku 10.10.10.32/27 a MKčko jako pool má 10.10.10.64/27. Statikcé přiřazení a spol musíš dát stjeně do obou, jako DNS jim dáš tu 10.10.10.254. Pokud máš v LAN počtač,e které dělají hlubší analýza paketů, dělají to iněkteré antivir balíky, tak možná bude třeba vypnout na nich ARP inspekci, aby se dostaly do Inetu.
MKčko bude NATovat jen to, co přileze přímo z 10.10.10.0/24.

O protokolu VRRP jsem vůbec neměl ponětí. Ano, asi by to bylo nejlepší řešení. Ale mám v serveru dhcp uloženy v databázi a jejich seznam se několikrát denně mění. Takže bych ještě musel vyřešit DHCP. Ale nebylo by jednodušší na MKčku vytvořit bridge mezi VLAN, jako takový bypass serveru. Pak každých 5 minut spouštět script, který pošle několik pingů na server. Pokud server neodpoví, bridge aktivovat, jinak nechat neaktivní. Je mi jasný, že po dobu přepnutí bude v síti bordel, ale tich několik minut se to nechá vydržet a zase to pravidlo se použije cca 5x za rok.

A nebo skriptíkem z toho linuxu přes SSH nebo API ládovat ta leasy i do DHCP v tom RBčku.
Jiná možnost - ne zcela košer, ale funkční, je dát ten dhcp server v RB až na VRRP rozhranní. Vypadá to divně, ale funguje to pak tak, že daný DHCP server je aktivní jen v době, kdy je ten VRRP jako master, čili linux kaput.
Ona třeba řada windows klientů má problém změnit IP, když nedošlo fyzicky k detekci rozpojneí jejich linky, zkrátka si nechají starou IP, přestože jim bude právě aktivnéí DHCP posílat NAK a nutit něco jiného. Pomůže buď vytrhnout/vrátit jim kabel nebo vypnout/zanout wifi, případně ipconfig -release/ipconfig -renew.

Zkusím rozběhat to VRRP, minimálně se naučím něco nového. A jinak to cestuvání uživatelů pomocí DHCP funguje naprosto bezvadně. V dřívějších dobách jsem takto přepojil za provozu klienty z jednoho segmentu do druhého. W2K,WXP, W7, W8 mobile, android - všechny tyto systémy to zvládly na první pokus. Ale samozřejmě pak celou dobu špačkovali a chtěli něco jiného. Ale DHCP se vždy podřídili.