VPN - přenosné připojení pro offline lokality

[HermaneusMora]

Potřebuji se vzdáleně připojovat k zařízením, která jsou v OFFLINE lokální síti zákazníka. Typicky různé počítače, PLC automaty, frekvenční měniče v rámci jednoho stroje ve výrobní firmě. Ta zařízení typicky NEMAJÍ ve své IP konfiguraci nastavenu Gateway.

Potřebuji "být v té lokální síti", vidět ta zařízení, pingnout na ně, připojit se k jejich webovém serveru, spojit se s nimi pomocí jejich proprietálního software.

Řešení obecně vidím v tom, že bude existovat nějaká krabička (něco jako chytrý router, jednodeskový počítač, případně starší laptop), který se předem nakonfiguruje a následně zapojí do místní sítě a připojí se k internetu a ta krabička zajistí, že se někdo dokáže ze svého PC vzdáleně připojit do té místní sítě.

Ta krabička bude přenosná a bude se převážet mezi různými firmami a vzdálený pracovník se bude připojovat tam, kde ji technik zrovna zapojí (a kde ji připojí k internetu).

To co chci, už tímto způsobem vlastně používáme, ale jako placené řešení firmy ewon.
https://www.ewon.biz/technical-support/pages/talk2m?ordercode=talk2m
Ewon je zdarma při občasném použití, ale při častém použití je dost drahý, proto bych chtěl něco podobného, ale ve vlastní režii.

Moje naivní schéma je zde:

https://imgway.cz/8T6e/VzdalenePripojeni1.png

Předpokládám, že bych potřeboval VPS server, na kterém by běžel OpenVPN server (cena VPS serveru problém není). Mám na tu VPS nějaké zvláštní požadavky (kromě dostatečného množství měsíčních dat)?
Předpokládám, že vzdálenému pracovníkovi by na počítači s windows by běžel pouze OpenVPN klient. Vzdálený pracovník bude připojen nějakým domácím nebo mobilním připojením k internetu.
Ale co ta krabička?
- Musí mít ethernetový port, aby se připojila k té LAN.
- Musí být schopna se připojit k internetu (např. přes wifi, nebo přes LTE SIM - lépe obojí, ideálně by měla mít ethernetový WAN port, ale to není nutné). Ten internet bude typicky "špatný", tedy žádná veřejná IP adresa a nemožnost se domluvit na nějakém přesměrování portů. Buď místní wifi, nebo mobilní data.
- Musí jít nakonfigurovat tak, aby se k internetu a VPN připojila po restartu sama, případně, aby to někdo méně zkušený dokázal zapnout přes webové rozhraní (dle připraveného návodu).

Jdu správným směrem? Poradíte jaká krabička by byla vhodná?

Pokud se budu chtít připojit do místní sítě, kde bude jiný privátní rozsah, budu muset měnit konfiguraci pouze v krabičce, nebo i na VPS OpenVPN serveru?
Nebo se pletu a je to složitější a abych byl vzdáleně přítomen v té LAN, tak by na krabičce musel běžet VPN server?

Díky.

[Reklama]

[_Jenda]

Jdeš správným směrem, zkontroluj si, že těm zařízením stačí jen TCP/IP viditelnost (to bys na krabičce NAToval a je to nejjednodušší), také by mohla vyžadovat, abys byl ve stejném segmentu -- pak bys potřeboval bridgovanou VPN (openvpn tap mode).

Pokud se budu chtít připojit do místní sítě, kde bude jiný privátní rozsah, budu muset měnit konfiguraci pouze v krabičce, nebo i na VPS OpenVPN serveru?

Bude potřeba správně nastavit routa. To by se dalo dělat na klientovi (ip r a 192.168.123.0/24 via krabička, resp. "route" direktiva v konfiguráku openvpn), ale pokud s tím na těch Windows nebudeš chtít zápasit (osobně to teda dělám tak, že mám Windows ve virtuálu s NATovanou sítí a routování tak řeší host OS), tak bych možná přes tu VPN poslal všechno (redirect-gateway) a na VPSce to nějak proroutoval.

Ale teď mě napadlo, že by se možná nic nestalo, kdybys přes krabičku poslal natvrdo všechny RFC1918 rozsahy (tj. dáš do konfigu openvpn na klientovi tři "route" direktivy pro 10.xxx, 192.168.xx a 172.nevímjakdál) a nazdar.

Ale co ta krabička?
- Musí mít ethernetový port, aby se připojila k té LAN.
- Musí být schopna se připojit k internetu (např. přes wifi, nebo přes LTE SIM - lépe obojí, ideálně by měla mít ethernetový WAN port, ale to není nutné). Ten internet bude typicky "špatný", tedy žádná veřejná IP adresa a nemožnost se domluvit na nějakém přesměrování portů. Buď místní wifi, nebo mobilní data.
- Musí jít nakonfigurovat tak, aby se k internetu a VPN připojila po restartu sama, případně, aby to někdo méně zkušený dokázal zapnout přes webové rozhraní (dle připraveného návodu).

Jako první řešení se nabízí Raspberry Pi s USB LTE modemem a případně USB síťovkou pro „WAN port“. Je k tomu potřeba kvalitní napájecí zdroj a kvalitní storage (microSD karty odcházejí), teď existuje https://rpishop.cz/emmc-micro-sd/3426-uugear-raspikey-32gb-emmc-pamet-pro-raspberry-pi.html tak bych zkusil to, ale osobní zkušenost nemám.

Nebo nějaký podobný jednodeskový počítač.

„Průmyslové“ řešení by byl Alix APU2. Většina verzí má přípravu na modem do miniPCIe a wifinu také tak.

Lowcost a snad celkem spolehlivé řešení by byl nějaký routřík s wifi a USB portem, například https://www.i4wifi.cz/cs/210667-routerboard-mikrotik-rb952ui-5ac2nd-hap-ac-lite (ten používáme v práci a zkušenosti dobré), do kterého flashneš OpenWRT a připojíš USB LTE modem (nevím jestli nebude potřeba posílit 5V napájení). Nevýhodou je omezenější systém (OpenWRT) protože to má jenom 16 MB storage. Výhodou oproti Raspberry je že to není snowflake - má to odolnou flashku do které se standardně nezapisuje a má to normálněji vyřešené napájení.

Další možnost je nějaký Intel NUC. Má to wifi a ethernet, některé mají vevnitř další USB a miniPCIe, takže by šlo modem možná zabudovat. A nebo jako USB dongle, no.

[BobTheBuilder]

Když by ta krabička měla být už počítač (NUC apod.), tak jestli by nebylo lepší tam dát nějaký plnohodnotný systém s možností vzdáleného připojení (např. TeamViewer) - ano, je komerční, ale bude to možná spolehlivější, než nějaký domácí bastl. Zasahující expert pak bude přímo v té síti a nemusíte řešit žádné síťové rozsahy a jejich konflikty, ten specializovaný software spustíte přímo v místě, přímo v cílové síti a odpadne vám celá škála problémů s připojením, které na dálku budete řešit velice obtížně.
Pokud použijete LTE modem (zase, pro daný účel ta cena nebude vysoká), můžete mít obvykle - ve firemních tarifech - i veřejnou IPv4 adresu. Tím vám zase odpadá prostřelování NATu a podobné radosti, které sice fungují, ale v terénu se budou špatně řešit. Ale s TeamViewerem veřejnou adresu řešit ani nemusíte, stačí vám to zařízení jen připojit do té místní sítě a nějak, jakkoliv, k internetu.
No a nakonec, nejschůdnější pro tohle bude nějaký malý notebook, protože ho může použít ten zasahující technik a pomoc přes ten TeamViewer (nebo něco takového) si vyžádá, když neví, jak dál.

[Radek Zajíc]

Na tenhle ucel by se dost hodilo nativni IPv6 na zarizenich + povoleni vybranych bloku "ze kterych je povolena sprava zarizeni" ve firewallu zakaznika (zarizeni by musela mit default gateway).

Pokud zarizeni maji jen IPv4, nabizi se standardni reseni typu IPv4 VPN, kde budete nejspis resit konfliky IPv4 rozsahu, NATy, premapovavani rozsahu RFC1918 do jinych RFC1918 rozsahu (ktere jsou zrovna u vas volne)... a nebo reseni s IPv6. :-)

Jak by to mohlo fungovat?

Na "krabicku" by mohlo davat smysl pouzit OpenWRT, protoze tam jde celkem snadno "predkonfigurovat" nekolik ruznych WAN pripojeni a pak se pro VPN klienta ("road warriora") pouzije to pripojeni, ktere je zrovna k dispozici.

Pokud chcete mit vic WAN rozhrani, budete pravdepodobne potrebovat neco jako MultiWAN (mwan3 na openwrt), ktery bude vybirat aktivni uplink a podle toho nastavovat default gateway, a k tomu navic jeste nejaky "post-dhcp" skript pro LAN, ktery vzdy posle cely RFC1918 blok skrze default gateway pro LAN.

Mezi serverem a "road warriorem" by mel dobre fungovat wireguard (pokud jsou v zakaznickych sitich "otevrene internety" a projde UDP provoz).

Pro zamezeni "konfliktu adres" (predpokladam RFC1918, tedy privatni IPv4 adresy) mezi lokalnimi sitemi zakaznika je dobre pouzit IPv6:
- server bude mit prideleny vetsi ROUTOVANY blok, napr. /64
- na serveru se z routovaneho bloku vyhradi napr. prvni /96 blok ("VPN blok") pro VPN uzivatele a druha /96 pro krabickovy preklad adres ("prekladovy /96 blok")
- na "krabicce" bude VPN klient, ktery bude mit zafixovanou IPv6 adresu z VPN bloku (umi OpenVPN i Wireguard)
- na serveru bude routovany "prekladovy /96 blok" na "zafixovanou IPv6 adresu z VPN bloku
- na krabicce bude bezestavovy NAT64/46, ktery namapuje cely RFC1918 rozsah na "prekladovy /96 blok"
- firewall na serveru pohlida, ze do prekladoveho /96 propusti provoz jen z predem schvalenych IPv6 bloku (napr. kancelar)

Pro NAT64/46 lze pouzit Jool (v OpenWRT podporovan).

Priklad:
- pc v kancelari: 2001:db8:1000:c::/64
- vlastni IPv6 adresa serveru: 2001:db8:1000:5::1 z bloku /64
- IPv6 blok routovany na server: 2001:db8:1000:6::/64 via 2001:db8:1000:5::1
- vpn rozsah: 2001db8:1000:6:0:0::/96
- routovany rozsah: 2001:db8:1000:6:1:0::/96

NAT64/46 se provadi mezi 2001:db8:1000:6:1:0::/96 a 0.0.0.0/0, tj. napr. provoz z 2001:db8:1000:6:1:0:192.168.100.1 se prelozi na 192.168.100.1 (a naopak).
PC v kancelari pak pristupuje z 2001:db8:1000:c:dead:babe:c001:cafe na 2001:db8:1000:6:1:0:192.168.100.1, coz je standardne odroutovano k serveru, server to interne naroutuje do VPNky a krabicka u zakaznika to prelozi na IPv4 a zarizeni je zpristupneno.
Krabicka se da libovolne presouvat, rozsah adres 2001:db8:1000:6:1:0::/96 zustava. V pripade vice krabicek pak lze pokracovat s 2001:db8:1000:6:2::/96, 2001:db8:1000:6:3::/96, atp.

[HermaneusMora]

Když by ta krabička měla být už počítač (NUC apod.), tak jestli by nebylo lepší tam dát nějaký plnohodnotný systém s možností vzdáleného připojení (např. TeamViewer)

Díky, ale ne. Toto používáme, když to jde, ale já se potřebuji připojit a pracovat tam s konkrétním proprietálním licencovaným SW. Případně tam potřebuji připojit externistu, který má na svém počítači licence, které nemáme ani my.

[Reklama]

[HermaneusMora]

Na tenhle ucel by se dost hodilo nativni IPv6 na zarizenich + povoleni vybranych bloku "ze kterych je povolena sprava zarizeni" ve firewallu zakaznika (zarizeni by musela mit default gateway).

Řešení, jak se přes IPv6 dostat do IPv4 LANky zní zajímavě, jsou tam ale 2 problémy
1) Já IPv6 vůbec neumím. Já neumím ani IPv4, nicméně jsem schopen metodou google-omyl něco nastavit.
2) Ten vzdálený pracovník může být na různých typech připojení. Různá domácí, hotelová nebo mobilní připojení. Klidně bez IPv6. Věnovat energii řešení, které bude fungovat jenom někdy, se mi nechce.

[ja.]

Dalsiu moznost by som videl v tunelovani L2.

Cisto sw: zerotier layer 2 bridging.

Krabicky (ale treba dve, na kazdy koniec): Mikrotik a EoIP. Nastavit tunel medzi krabickami (wireguard, ipsec, apod) a potom cez ten tunel EoIP. Pri tomto rieseni netreba nic na klientovi, len aby sa pripojil na niektory z interface krabicky.

[honzako]

Šel bych cestou nejmenšího odporu.

1. musíš si zajistit souhlas zákazníka že ti umožní něco tvého do jeho LAN zapojit
2. koupil bych GSM AP router - bůhví jak se to jmenuje, ale je to normální AP s přístupem na mobilní síť a má to normální ethernetové porty a přes něj se dostat do jejich sítě. Vím že to vyrábí úplně každý a stojí to asi 2 tis. (TPLink, Zyxel apod.)
3. vyřešit si jak se dostaneš na zařízení - servisní notebook apod.

Nevidím důvod proč by to nemělo fungovat.

[FactChecker]

Řešení už napsal Jenda. Na VPS nakonfigurovat OpenVPN server v TAP modu. Mikrotik s OpenVPN klientem strkat do spravované sítě. A vzdálený procovník bude mít také OpenVPN klienta a bude mu tak padat z tap rozhraní ethernetový provoz té vzdálené lokální sítě. Sám si nastaví IP adresu jako bude potřebovat a může použít i nástroje které nepoužívají IP protokol. Levné, jednoduché, funkční.

[Radek Zajíc]

Re: Ten vzdálený pracovník může být na různých typech připojení.
Vzdálený pracovník stejně bude potřebovat nějakou VPN, takže klidně může být připojený na ten VPN server - a Wireguard umí IPv6 docela bezpracně. OpenVPN to umí taky.

[skopda]

Vzhledem k tomu, že zařízení průmyslové automatizace používají různé bizardní proprietární protokoly které nemusí fungovat když se jim do cesty postaví NAT a funkčnost případně použitelnost ovládacího software může být závislá na velmi krátké odezvě tak konfigurování přes VPN nebude řešením které bude univerzálně spolehlivé.
Tam kde se plc konfiguruje přes web nebo modbus TCP to problém asi nebude, ale nějaké OPC nebo jiné zrůdnosti moc dobře fungovat nebudou.
Univerzální řešení bude notebook/NUC na kterém bude nainstalován konfigurační software a vy se k němu připojíte přes teamviewer/remoteDesktop/VNC nebo jinou službu pro vzdálené ovládání ať již cloudovou nebo se notebook připojí do libovolné vaší VPN a pak se připojíte remote desktopem. Notebook je vhodnější řešení protože možnost provozu na baterii se občas může velice hodit.

[5nik]

Jenom navrhnu ještě jedno řešení. S ROS7 pro Mikrotik přibyla podpora ZeroTier (pro ARMy). Na Mikrotiku by se to mělo umět dát do bridge s ethernetem a zároveň existuje klient i pro Windows. Tedy teoreticky L2 síť přes internet až do PC technika.
Nemám to ještě vyzkoušené, zatím teorie. Mikrotik má i boxy s LTE a Wifi (wAP r2, hAP AC3). Dalo by se to předpřipravit na více WAN, ale pokud by to selhalo, tak pro obyčejné techniky to bude náročné na ovládání.

[HermaneusMora]

Vzhledem k tomu, že zařízení průmyslové automatizace používají různé bizardní proprietární protokoly které nemusí fungovat když se jim do cesty postaví NAT a funkčnost případně použitelnost ovládacího software může být závislá na velmi krátké odezvě tak konfigurování přes VPN nebude řešením které bude univerzálně spolehlivé.
Tam kde se plc konfiguruje přes web nebo modbus TCP to problém asi nebude, ale nějaké OPC nebo jiné zrůdnosti moc dobře fungovat nebudou.

Už jsem psal. Existuje proprietální řešení od firmy EWON (ale jsou i další podobné), kterým to přes VPN funguje. Občas to bolí, ale celkově to funguje. Přiznám se, že zrovna OPC jsem přes to nikdy netahal. Tam kde je offline LAN, tam jsme OPC nikdy nepoužívali. Tam kde je OPC, tam je to připojeno do větší sítě a existuje způsob, jak se připojit po infrastruktuře zákazníka. Ale mám pocit, že přes ten EWON by mělo fungovat i OPC.
Nejsem síťař, netuším, jestli jsem si vybral úkol, který je velmi obtížný, jestli řešení EWONu zahrnuje velké know-how zkušených lidí a nelze to tak snadno napodobit, nebo jestli je to snadné, jak tu píší někteří.

Univerzální řešení bude notebook/NUC na kterém bude nainstalován konfigurační software a vy se k němu připojíte přes teamviewer/remoteDesktop/VNC

Díky, to jsem už také psal, že nechci. Když to jde, tak to použijeme, ale pro určité situace prostě potřebuji dostat k zákazníkovi nějaký konkrétní notebook, konkrétního programátora.

[_Jenda]

Když by ta krabička měla být už počítač (NUC apod.), tak jestli by nebylo lepší tam dát nějaký plnohodnotný systém s možností vzdáleného připojení (např. TeamViewer) - ano, je komerční, ale bude to možná spolehlivější, než nějaký domácí bastl.

Normálně ssh a vnc přes tu openvpn, ne?

Pokud použijete LTE modem (zase, pro daný účel ta cena nebude vysoká), můžete mít obvykle - ve firemních tarifech - i veřejnou IPv4 adresu. Tím vám zase odpadá prostřelování NATu a podobné radosti, které sice fungují, ale v terénu se budou špatně řešit.

Já teda s firemním vodafone veřejnou adresu nemám, a i kdybych měl, tak by asi byla dynamická, takže stejně bude potřeba řešit to. Ale fakt nechápu co je na openvpn co se ti připojí na server „v terénu se budou špatně řešit“.