Dotaz: OpenVPN a přenášený laptop

[Petr Tomášek]

Zdar!

Mám tři sítě propojené pomocí OpenVPN / TAP a vše funguje, jak má. Až na jednu drobnost. Když do jedné sítě připojím laptop (a bez problému se z něj dostanu na stroje v jiných sítích) a pak ten laptop fyzicky přenesu a zapojím do sítě jiné, pak už na stroje z jiných sítí nevidím. Pomůže jen restart OpenVPN. Vypadá to, že se OpenVPN naučí, kde laptop je a už „nepustí“. Existuje nějaká možnost, jak OpenVPN říct, aby se po nějakém čase poohlédnul po tom, zda-li je informace o tom, kde se stroje nalézají stále ještě aktuální (vzdálenosti mezi sítěmi jsou ve stovkách kilometrů, takže prakticky vždy je mezi připojením laptopu do různých sítí minimálně 3 hodiny, kdy laptop v síti vidět vůbec není)?

Pokud ne, dá se nějak OpenVPN říct, aby flushla informace týkající se konkrétní MAC adresy?

Dík

Odpovědi

[NN]

Mnoho otazek. Ta topologie vypada takto?

A -- VPN -- B -- VPN -- C

nebo takto,

    -- A
VPN -- B
    -- C

Veta "stroje z jiných sítí nevidím" znamna co presne? Routing mas v poradku? Traceroute vypada jak? Ping se dostane kam az? Pakety jsou zahazovane kde presne?

Vypadá to, že se OpenVPN naučí, kde laptop je a už „nepustí“.

VPN ma prece session, ktera se s odpojenim rozpadne. Log VPN klienta vypada jak? Nema OS jen problem s ostranenim docasnych cest z routing tabulky?

[PetebLazar]

Tazatal zmiňuje TAP rozhraní což by snad mělo být propojení ekvivalentní bridge a nikoli routeru (TUN)? Schéma propojení by neškodilo.

[Petr Tomášek]

Tazatal zmiňuje TAP rozhraní což by snad mělo být propojení ekvivalentní bridge a nikoli routeru (TUN)?

Přesně tak. Jinak by to ani nedávalo smyslu (cílem je, aby zůstaly zachovány IP adresy a laptop byl dosažitelný na své IP adrese nezávisle na tom, kde se nachází - což logicky za pomoci TUN nejde...). Mimoto tam jede VOIP, takže stejně jiná volba není reálná...

Schéma propojení by neškodilo.

sice se nezdá, že by na tom tak záleželo, ale tady to je:

                                --  router/klient - síť B   
  síť A - router/server -- VPN -- 
                                --  router/klient - síť C

Problém ale nastává při jakémkoliv přenosu laptopu z jakékoliv sítě A,B,C do sítě jiné.

[Petr Tomášek]

VPN ma prece session, ktera se s odpojenim rozpadne.

Jaké odpojení? Ty sítě jsou připojeny pořád, jenom se mezi nimi přenáší laptop.

Log VPN klienta vypada jak?

Co by tě konkrétně zajímalo?

Nema OS jen problem s ostranenim docasnych cest z routing tabulky?

Ale to s routováním nemá nic společného, jasně píšu, že se jedná o TAP, nikoliv TUN. (Spíš se jedná o jakousi vnitřní "ARP" tabulku OpenVPN, podle které OpenVPN ví, kdy má v bridgi směřovat packety pro tu či onu MAC adresu do té, či které sítě...)

[Adamec]

Skriptem, po připojení do sítě restartovat službu ...

koukni do (pro inspiraci) /etc/network/if-up.d

[Petr Tomášek]

No, to už je jedno, jestli se to udělá ručně nebo skriptem (uživatel laptopu má tak jako tak rootovská prává). Problém ale je, že se na nějaký čas rozpadne spojení. Tomu bych chtěl za každou cenu zabránit, potřeboval bych, aby se OpenVPN dalo říct: pro tuto konkrétní MAC se znovu nauč, ve které síti se pohybuje... (nebo, ještě lépe, aby to OpenVPN udělalo třeba po 3 hodinách automaticky...)

[Petr Tomášek]

Aby bylo jasno: laptop není jediný, kdo VPN využívá. (Je jediným zařízením, které má problém, pokud je přenesen ze sítě do sítě ...)

[PetebLazar]

Když se noteboku před připojením do druhé sítě přepíše MAC u adaptéru na jinou, tak může s ostatními sítěmi komunikovat úspěšně (bez restartu OpenVPN)?

Ve společné síti je jediný (nezávislý) DHCP server?

[Petr Tomášek]

Když se noteboku před připojením do druhé sítě přepíše MAC u adaptéru na jinou, tak může s ostatními sítěmi komunikovat úspěšně (bez restartu OpenVPN)?

Hm, no to by asi šlo, ale je to teda dost rovnák na vohejbák... Jestli nebude jednodušší, abych se nakonec povrtal ve zdrojácích OpenVPN

Jak bys řešil, aby laptop automaticky rozeznal, ve které síti se nachází a podle toho nastavil MAC? Momentálně používám NetworkManager kvůli uživatelskému komfortu v jiných sítích, nedovedu si moc představit, že by ho šlo jednoduše k tomu ohnout...

Ve společné síti je jediný (nezávislý) DHCP server?

Ne, každá síť má vlastní, DHCP packety na TAP rozhraní blokuji přes ebtables.

[petr_p]

Ne, každá síť má vlastní, DHCP packety na TAP rozhraní blokuji přes ebtables.

Obávám se, že to je příčina.

Když stroj rozesílá ethernetové rámce, bridge po cestě se učí, na které lince viděly jakou zdrojovou adresu. Když pak mají přeposlat rámce učený pro ni, tak aby se ušetřilo, tak přepošlou jen tu zapamatovanou linku.

Když stroj přenesete, tak bridge se magicky nedozví, že mají naučenou informaci zahodit. Buďto se čeká na vypršení časového limitu, nebo musí danému bridgi projít pod rukama rámec z nové linky.

Kdybyste neblokovat DHCP dotazy, tak stroj po připojení pošle broadcastový dotaz (pozor na úsporné DHCP klienty, které začínají unicastovým prodloužením staré adresy), který se rozleze po celé síti, a všechny bridge se tak naučí nové umístění. Ve vašem případě se ale tak stane jen v oblasti omezené ebtables.

Je třeba si také uvědomit, že OpenVPN, také nějak implementuje bridge. Jestli ovšem se chová jako úsporný switch, nebo jako broadcastující hub, o tom dokumentace mlčí.

[PetebLazar]

Ptal jsem se proto, že v souvislosti bridge mode se zminuji v dokumentaci OpenVPN dve varianty a to s centralnim DHCP serverem a server-bridge (kdy asi openvpn server spravuje vyclenenou svou cast IP rozsahu, apriori zná co kudy směřovat?). https://openvpn.net/community-resources/ethernet-bridging/

Dynamicky by se MAC adresa síťového adaptéru dala měnit například podle dohledaného WiFi okolí (MAC adresy APs v dosahu)?

Napadla mne i možnost zda nemůže jít o dlouhý timeout MAC záznamů v LAN switchích, ale to nejde dohromady s uvedeným řešením problému pomocí restartu OpenVPN serveru. Leda že by při restartu OpenVPN došlo k dočasné deaktivaci síťového rozhraní a jeho LAN portu ve switchi s navázanou invalidací záznamů MAC. V tom to asi nebude.

Chtělo by to na síťových rozhraních fyzických/virtuálních trasovat ARP atd. Kdo poslední to ignoruje(zahodí).

[Petr Tomášek]

No, to by chtělo, ale budu muset počkat, až zase pojedu těch párset km... Teď mi to momentálně funguje a ARP se skrz OpenVPN bez problému dostanou...

[Petr Tomášek]

To mi přijde poněkud přitažené za vlasy. Přeci to musí fungovat i bez DHCP broadcastu (např. při statické adrese) a sice přes ARP. To se mi opravdu nezdá.

[petr_p]

Ano, ARP používá broadcast. (Doteď jsme si mohli myslet, že máte IPv6, kde se na to používá multicast.) Ježe my nevíme, co s tím laptopem děláte. Třeba ho uspíte a spánek (asi chybně) se nezapočte do životnosti záznamů. Třeba jste narazil na jinou chybu v Linuxu. Třeba laptop mezi tím vůbec nemá potřebu komunikovat, takže se žádný ARP packet nevyšle.

Každopádně si budete muset sednout s tcpdumpem na jednotlivých linkách a zjistit, kde se vám rámce ztrácejí, či kam jinam tečou. A začít opravdu můžete s ARP. Nástroj arping znáte?

[GeorgeWH]

A to, ze ti tri siete zdielaju rovnaky subnet (lebo iny zmysel v bridgovany sieti nevidim), ti za vlasy pritiahnute nepride?

[Petr Tomášek]

Rozhodně ne.

[Jira]

Tak jak bylo napsano výše.

"/etc/network/if-up.d", mám takto skripty na vpnku, sdílené disky

Vždy když se připojíš do jakékoli sítě tak se restartuje vpnka

[Petr Tomášek]

Ty máš zřejmě dost problém pochopit psaný text. Takže znovu: OpenVPN běží na routeru, jedná se o propojení sítí, laptop se připojuje do těchto sítí...

Takže tvé řešení by bylo dost krkolomné, možná by to přes ssh nějak šlo, jenže já ani nechci, aby měl root na laptopu automaticky přístup na roota na routeru (bez ohledu a to, že uživatel, který s laptopem pracuje, heslo k root@router zná).

[Bluebear]

Zda se mi že ten, kdo nechápe jsi ty. Sektář Tomášek.

[Petr Tomášek]

Tobě se může zdát, co chce. Dokud nenapíšeš něco konkrétního k věci, jsou to jen páchnoucí zvratky...

[PetebLazar]

Routerem se míní provoz nsplnohodnotném Linux/x86, nebo nějakém embedded zařízení OpenWRT/RouterOS(Mikrotik) atd? Ta implementace openvpn na Mikrotiku (pouze přes TCP) mi přišla chováním tragická.

[Petr Tomášek]

Plnohodnotný Debian Wheezy + Devuan Jessie (Ještě jsem nestihl migrovat všude...).

[GeorgeWH]

Tak si po presune pozri, kto ma kde nacachovanu tvoju MAC adresu. Mozno by pomohlo skratit aging na bridgoch.

[PetebLazar]

Teď už se pouštím na hodně tenký led. U popisu OpenVPN@bridging se také zmiňuje možnost vypnout STP(Spanning Tree Protokol), pokud se není třeba obávat smyček. Nemůže v případě příchodu stejného ARPu z různých cest (po přesunu) aktivní SPT detekovat smyčku a omezit komunikaci? https://community.openvpn.net/openvpn/wiki/OpenVPNBridging

[GeorgeWH]

Tym to urcite nebude, to by ti neslo nic, resp. by si musel mat zbridgovane este dve dalsie siete medzi sebou. Ale keby si si pozrel tu cache...

[Petr Tomášek]

Tak si po presune pozri, kto ma kde nacachovanu tvoju MAC adresu.

Kde bych se měl podle tebe podívat?

Mozno by pomohlo skratit aging na bridgoch.

Ten nepřesáhne 300 sekund, můj problém trvá v řádu dní, takže tím to nebude.

[GeorgeWH]

Na bridge.

Akoze sa ti to nerozbehne ano po niekolkych dnoch? Vzdy az po restarte VPN?