none
RDP - přístup přes záložní konektivitu

    Dotaz

  • Ahoj, prosím o radu.

    Mám na centrále terminal server a z poboček se přes WAN linku připojují klienti. Na veřejnou IP této WAN linky vede A záznam v DNS u provozovatele domény, např. hlavni.firma.cz . WAN linka ovšem občas vypadne a hodila by se možnost připojení přes nějakou záložní konektivitu. Ta bude mít jinou veřejnou IP a tedy DNS záznam jiný, např zaloha.firma.cz  A teď jak donutit klienty aby se připojovali ve chvíli nedostupnosti hlavní linky přes zálohu?

    Mít v DNS pod A záznamem dvě IP nechci, protože pak by DNS server odpovídal střídavě oběma IP, ale já chci zálohu využívat jen když hlavní nepojede.

    A měnit DNS záznam u providera podle dostupnosti linky se mi nezdá jako dobré řešení (pokud by to vůbec šlo), trvalo by dlouho než by klienti změnu zaznamenali.

    Neumí to třeba RDP klient sám o sobě?

    pondělí 11. května 2015 10:11

Všechny reakce

  • Nie, nejde to spravit co chces. RDP klient taku inteligenciu neobsahuje.


    ---------- Ondrej Zilinec - Cievo ----------

    pondělí 11. května 2015 10:13
  • Pokud do záložního pojítka (routeru umíš přidat i tu hlavní veřejnou IP adresu), mohl by jsi to řešit přes routovací tabulky na routerech poboček.

    Pak by jsi se připojoval pořád na tu hlavní IP adresu ale cesta by vedla přes to záložní pojítko.

    .

    Nastavit by to šlo buď dynamicky (váhou cesty) nebo staticky (po výpoadku by jis nastavil jinou cestu).

    Rozhodně to neřeš na úrovni klientských počítačů.


    JCH

    pondělí 11. května 2015 11:15
  • No ja si nemyslim, ze by to bylo jednoduche. Odchozi provoz se da resit nejak u sebe, prichozi provoz by asi vyzadoval nejake nezavisle adresni IP rozsahy. Nicmene nejsem tak dobry sitar.

    Ja bych navrhoval vyuzit hostingovych sluzeb nekoho, kdo ti garantuje dostupnost. Nebo proste mit dva zastupce na plose. Otazka je pro koho to resis :)

    úterý 12. května 2015 13:15
  • Avizuji dalsi problem:

    Jak chytry je router v hlavni firme?

    Jde o to, ze pokud je router hloupy a terminal ma na tento router default gateway, pak sice terminal prijme prez zalozni linku paket, ale odpoved posle na def.gateway do linky, ktera je spadla.


    tj na vypadek wan spoje musi reagovat i defaultni gateway ve firme a pakety do internetu musi zacit smerovat jinam.
    úterý 12. května 2015 13:33
  • defaultní gateway v centrále je celkem chytrý router, nějaký Zywall USG. Měl by umět něco jako Link sticking, takže komunikace iniciovaná je jednom rozhraní tam taky zůstane.

    Routování více cestami z poboček - to stojí za prozkoumání ale jsou tam nějaké celkem hloupé ADSL modemy, tak nevím. Sice mi to neřeší cestující uživatele, ale ti jsou zase zdatnější a uměli by kliknout na jinou ikonku na ploše.

    Problem je samozřejmě v uživatelích na pobočkách, jsou to retailové prodejny a uživatelé jsou tupá polena...

    Ještě jsem našel alternativního RDP klienta jménem RDP+, který umí zkoušet vice terminal serverů v rámci jednoho uloženého profilu, ale vybírá je náhodně. Psal jsem vývojáři, jestli by s tím nešlo něco udělat.

    Díky za tipy.

    středa 13. května 2015 10:29
  • Podobnou problematiku jsem řešil. Nejednalo se o WAN jako takovou, ale vyloženě o RDP over HTTPS. Hned na začátku jde o základní otázku. Jak velký výpadek unesu a když udělám velkou dostupnost pochopí ostatní, že ten pětiminutový výpadek je v této situaci plánován? (otázek je ve finále tímto směrem více, ale tato je taková základní). Když jsem se pouštěl do řešení problematiky bylo jasné kudy bych se měl vydat. Ta správná cesta je "LOAD BALANCER", ať to je již HW zařízení nebo MS NLB server. (potřeboval jsem rychlé a funkční řešení a při ceně HW balanceru bylo jasné, že tudy ne, nehledě na to než si to člověk osahá. Zkušenosti s NLB serververem nemám tak velké abych ho také hned implementoval do takovéhleho molochu co vznikl). U NLB serveru mne to hlavně vycházelo na další tři stroje, o které bych se musel starat.

    Řešení tedy bylo. Již ke stávajícímu RDS Gateway (rovnou na něm byla i role RDS Web Access), přibyla druhá RDS brána a proč by ne rovnou s wa. Za GW stála teprve RDS farma mimo DMZ (myslím, že není potřeba toho již popisovat).

    Každá GW je připojena do internetu jiným providerem a DNS A záznam je ROAD ROBIN (tedy stejný). A teď to kouzlo. Z lokality hostingu tyto dva servery sledoval nevytížený ftp server.

    Mechanizmus byl jednoduchý. Je-li na obou dostupný port 80 je všechno v pořádku. není-li port 80 dostupný podívej se do internetu (třeba google) jestli neupadla konektivita tobě. Pokud ne tak změn A záznam serveru A (GW1) na server B (GW2).  Podmínkou je mít nastavené nízké TTL (5minut). Takhle krásně by to všechno fungovalo. Pět minut výpadek a pak zase tradá fungujeme. Ale bohužel to tak není. Klienti mají dns cache delší. Na vlastních stanicích bylo řešení jednoduché. Soubor RDP pro připojení není soubor RDP, ale skript, který před spuštěním RDP klienta smaže dns cache na klientském PC. Takže uživateli spadne terminál. On si ho pustí znovu a funguje. Skript byl upraven dokonce tak, že uživatele informoval o tom, že se připojit ještě nemůže.

    Díky tomu, že GW jsou v režimu farma a na RDS Clusteru je nastaven dostatečně dlouhý čas pro opětovné připojení (cluster má RDS broker clustrovaný, to je v podstatě podmínka) tak uživatel nepřijde ani o rozdělanou práci.

    Bohužel toto řešení nefunguje v okamžiku kdy na klientské stanici nemáte oprávnění provést FlushDns. A stačí k tomu powershell :-)

    Cesta zpět je jednoduchá nahodí se nové dns a už nemusí ani docházet k dns flush, probírá se to pomalu k životu.

    Snad se mne to povedlo dostatečně popsat. Případně můžu nakreslit.

    • Navržen jako odpověď Petr Tóth pátek 22. května 2015 13:30
    čtvrtek 21. května 2015 21:29