Dotaz: Domácí server s neveřejnou IP, aneb jak se na něj připojit z venku?

[Fastmancz]

Zdravím, Plánuji si udělat domácí server pomocí Orange Pi One a na něj chci mít jednoduchý samba server, přes který se poté budu napojovat z venku. Kupovat budu následující komponenty:

Orange Pi One SET4 Pi One and Power Supply Adapter Support Android, Ubuntu, Debian not for Raspberry

TP-Link TL-SF1005D 5x 10/ 100Mbps Desktop Switch Patch kabel Cat5E, UTP - 10m, zelený SanDisk microSDHC Card - 32GB

Dále mám pronajatý levný VPS server na kterém mám jiné běžící věci a nerad bych tam tahal sambu, chci to mít oddělené od své práce. Takže pokud to dobře chápu, tak musím mít na VPS spuštěný OpenVPN server na který se z domova připojí Orange Pi One a přes n2n budu prohánět směrování portů na můj server domů?

SAMBA (VPS IP) ===> VPS VPN n2n ===> Orange Pi One (snad je to doufám pochopitelné).

Bohužel nevím, kde najít podobný návod, ale vím, že by to mělo jít. Děkuji vám za odpovědi.

Odpovědi

[NN]

Jaky ma vyznam ten 100-kovy switch? Je pomaly a Pi muzes zapojit primo do domaciho Modemu.. Dalsi mensi zadrhel bude polo dynamicka IP od poskytovatele.

[Fastmancz]

Switch mám kvůli tomu, že modem je již plný. Internet je od O2 - 40/4 Mb/s. IP je pevná, nemění se.

[lkouz]

No jestli už se ti podaří to Raspberry připojit do OpenVPN na VPS, pak N2N nepotřebuješ. Vše pojede v rámci té VPN. Nebo to můžeš tahat přes N2N, kdy si z VPS uděláš supernode. Nebo se můžeš O2 zeptat, jestli ti dají IPv6. Nebo si připlatíš za veřejnou IP u O2 (jsou to hovada, co?).

[AsciiWolf]

Osobně bych tohle řešil spíš přes SSH tunel (remote port forwarding) v kombinaci s autossh.

[Andrej]

Takže pokud to dobře chápu, tak musím mít na VPS spuštěný OpenVPN server na který se z domova připojí Orange Pi One a přes n2n budu prohánět směrování portů na můj server domů?

Proč? Vždyť přes IPv6 se lze přece připojit rovnou a bez zbytečných vrstev tunelů.

Pokud chce člověk VPN, řešení se jmenuje IPSec. (Implementace démona pro výměnu klíčů je například {Strong,Libre,Open}Swan.) OpenVPN je nezaslouženě populární jen proto, že má v názvu VPN. Jde o neefektivní jednovláknový userspace moloch. Naopak IPSec je řešení úzce integrované s kernelovým síťovým stackem a všemi jeho vymoženostmi.

[1john2]

V puvodnim dotazu to nebylo, ale jak je na tom klient pro Windows?

[Andrej]

Nevím. Žádné Windows nemám a nikdy jsem jejich IPSec klienta nezkoušel. Předpokládám, že tam nějaká podpora je. Dotaz skutečně nijak nespecifikuje, že by podpora Windows byla nějak podstatná nebo potřebná.

[pavlix]

Windows co si pamatuju používají vlastní řešení s L2TP over IPsec, takže to není tak úplně kompatibilní s jinými řešeními, ale zase jsem měl dojem, že to běží všude možně kromě Linuxu out of the box.

[Max]

Windows umí L2TP over IPSEC i IKEv2 (zrovna to nasazuju v jobu) a nečiní u problém ani NAT - NAT (server i klient za natem) a není problém ani více klientů za stejným natem.
Používám na to Debian Stretch + vlastní kompilaci strongswan 5.5.0 + pro L2TP xl2tpd
Zdar Max
PS: článek o tom plánuji zveřejnit

[pavlix]

Super. Mimochodem tebe jsem stejně chtěl potkat, ale nějak jsem nevyužil té možnosti, když jsem řešil tu tiskárnu... Na článek se samozřejmě těším, hlavně teda na IKEv2 a obecnou kompatibilitu.

[pavlix]

Proč? Vždyť přes IPv6 se lze přece připojit rovnou a bez zbytečných vrstev tunelů.

To není tak úplně pravda. Po IPv6 se lze spojit rovnou bez vrstev tunelů za splnění určitých podmínek, které zdaleka vždy neplatí.

Pokud chce člověk VPN, řešení se jmenuje IPSec.

Jedno z řešení se jmenuje IPsec. Není to špatné řešení a má spoustu elegantních vlastností, ale rozhodně to není jediné řešení. Nevím, kolik se toho za posledních pár let změnilo, ale pokud chci IPv6, tak bych se asi od {Open,Libre}Swan držel radši dál. Strongswan ovšem funguje po stránce IPv4/IPv6 s kernelovou implementací IPsec hezky.

[Andrej]

Ano, samozřejmě může být (a implicitně na routerech je) nastavený IPv6 firewall tak, aby se zvenku připojit nedalo. Může tam být i spousta dalších překážek. Nicméně na rozdíl od zoufalství, ke kterému dospěl IPv4, má IPv6 v podstatě plně pod kontrolou uživatel, bez příplatků a bez doprošování se u operátora. Sám si nastaví firewall, sám si zvolí adresy atd.

Já používám výhradně StrongSwan. Vím, že některé distribuce (Fedora) mají implicitně nainstalovanou jinou variantu, ale nějakou bližší zkušenost s jinými labutěmi nemám. StrongSwan mi funguje bez problémů.

[pavlix]

Nicméně na rozdíl od zoufalství, ke kterému dospěl IPv4, má IPv6 v podstatě plně pod kontrolou uživatel, bez příplatků a bez doprošování se u operátora.

Když si teda vyprosí u operátora vypnutí firewallu na jeho straně, což u WISP a místních optických sítí asi nebude problém, tam se vždycky dovolá někoho inteligentního, ale u velkých operátorů bych si vůbec nebyl jistý.

Já používám výhradně StrongSwan. Vím, že některé distribuce (Fedora) mají implicitně nainstalovanou jinou variantu, ale nějakou bližší zkušenost s jinými labutěmi nemám. StrongSwan mi funguje bez problémů.

Potvrzuju. StrongSwan mi jako jediný prošel základními testy, co jsem s ním dělal a vždy vytvořil transport/tunel podle zadání bez nějakých nesmyslných omezení. Pokud jde o balíček ve Fedoře, tak toho jsem maintainerem. Udržuju pokud možno aktuální verze (žádný backporting) a před časem jsem přidával upstreamovou podporu pro libipsec nebo jak se to jmenuje, když chceš z nějakého důvodu obejít jadernou implementaci. Jinak se v RH udržuje LibreSwan (dříve OpenSwan), takže tam bych zase očekával větší kompatibilitu proti různým polostandardním enterprise IPsec VPN jako nabízí třeba Cisco.

[Sid]

Dokaze IPSec fungovat na lubovolnom porte? Celkom ste mi nasadil chrobaka do hlavy ohladom IPSec akurat openvpn mam konfigurovane tak aby bezalo na 443 porte pretoze dost casto vo firmach bol problem prejst von cez hocico ine.

[pavlix]

OpenSSL společně s SSTP a jinými SSL VPN má tu výhodu, že je oproti IPsec bližší předpokládanému legitimnímu datovému toku, takže je větší šance se dostat skrz. Ale popřepínat porty se dá prakticky u všeho, ne? Akorát na IPsec to znamená používat UDP transport, jinak funguje IPsec přímo nad IP vrstvou a samotný datový tok pak nemá porty.

[Sid]

To by asi slo teda. Ale teraz som pozrel android klienta a pozeram, ze tam sa port nastavit neda (alebo je to dobre schovane). Ak teda klient predpoklada napevno, ze je to nejaky pevny port tak si asi moc nepomozem, ciastocne mi slo o to nemusiet instalovat na klientske stroje cosi dalsie a pouzit to co tam je.

[pavlix]

Na jakého android klienta, toho vestavěného? To není zrovna moc obecný IPsec klient, to je spíš připojovátko na cisco a microsoft, ne?

[Sid]

to sem neskumal iba som som sa pozrel ake VPN-ky ma cyanogenmod a co sa tam da nastavit. Tak daleko ako skumat kompatibilitu som nedosiel. Ak je to ale tak ako vravis (zil som v tom, ze IPSec je tak nejako v pohode a funguje to out of the box medzi roznymi systemami) tak namiesto skumania po veceroch asi pokorne prenesiem sucasnu openwrt konfiguraciu na Turris Omniu ked dorazi a spokojim sa s tym co funguje.

[pavlix]

Tak daleko ako skumat kompatibilitu som nedosiel.

Je to vidět už na těch názvech. L2TP over IPsec je Microsoftí záležitost, XAUTH je cisco, všechno je to hrozný bordel a čím víc cisco, tím víc. :D

[Max]

Mám vyzkoušeného L2TP over IPSEC v androidu a plně ok.
Další možnost je použít strongswan klienta pro android a ten umí víc věc, i IKEv2 + jako bonus drží spojení, když vypadne, udělá reconnect.
Aktuálně budu nasazovat pro cca 200 uživatelů s výhledem na 350.
Zdar Max

[luks]

IPSec je naprd. Temer nikde to nefunguje, protoze dnesni internet je zejmena TCP,UDP,ICMP. Vse ostatni je v ruznych castech sveta ruzne podporovane.

Pokud chcete VPN na kterou se muzete spolehnout, tak bohuzel musite jit cestou tunelovani IP pres TCP/UDP. Tedy OpenVPN je sluzba, co vam bude fungovat, IPSec at je jakkoliv krasny, tak vam ve vetsine pripadu nepojede.

OpenVPN na 443 vam pak pojede snad skoro vsude (sice lze odhadnout a blokovat, ale videl jsem to jen jednou a to v africke tramtarii).

[Andrej]

IPSec lze tunelovat přes UDP, když na to přijde. Nevím, kde je ta „většina případů“, ale mně IPSec prostě funguje. S IPv6 jde přímo a bez tunelování, na IPv4 zpoza NATu funguje přes UDP. (Ale spojení mezi dvěma veřejnými IPv4 adresami jde samozřejmě taky bez tunelu.)

OpenVPN je béčkový přežitek z doby 1-procesorových strojů, který s VPN souvisí víc názvem než čímkoliv jiným.

[Fastmancz]

Děkuji všem za odpovědi, ale zatím se v těchto odpovědí ztrácím. Co by teda bylo nejlepší řešení? V podstatě jde o to, spojit se s VPS serverem a používat jeho veřejnou IP s tím, že konkrétní porty by se přesměrovávaly na můj domácí server.

[Jooky (inactive)]

Co kontkretne chces dosiahnut ? SMB/CIFS protokol nie je optimalizovany pre WAN spojenie. Staci len trosku vyssia latencia a cele je to nekonecne pomale ...

[Fastmancz]

Co kontkretne chces dosiahnut ?

Budu mít domácí server připojený na switchy s neveřejnou IP, jak jsem již psal v úvodním příspěvku. Chci dosáhnout toho, abych se mohl z venku napojit na můj domácí server (samba). O internet v domácnosti se nestarám Já, proto k němu nemám přímý přístup. Jen nevím, jaké řešení je dobré. Dočetl jsem se tady strongSwan řešení, jestli je to dobré či ne, to nechám na vás.

[pavlix]

jestli je to dobré či ne, to nechám na vás.

Pobavilo. Pokud budeš potřebovat poradit s chlazením, tak domácí serveřík by určitě ocenil studenou koupel ve vaně s pěnou do koupele a psím šamponem. :)

[Fastmancz]

V "síťařině" se úplně nevyznám, očekával jsem tady nějakou radu, holt se budu muset podívat po zahraničních webech s podobnou problematikou.

[pavlix]

To rozhodně.

[Jooky (inactive)]

Chci dosáhnout toho, abych se mohl z venku napojit na můj domácí server (samba).

Mne skorsie islo o to, ci ta samba je potrebna. E.g. planujes editovat dokumenty, alebo len z casu na cas nieco stiahnut, etc ... pri vyssej latencii je CIFS/SMB tak nepouzitelny protokol, ze bezne veci nad subormi mozu trvat aj desiatky minut. Zbytok sa tu viacmenej uz riesil. VPN na nejake zariadenie, co ma verejnu IP a potom forwarding vybranych portov ...

[Max]

Na sambu přes net zapomeň. Obzvlášť, když budeš mít mezi článek v podobě VPS někde v tramtárii.
Pokud to i tak chceš zkusit, tak bych nejdříve zkusil, zda ten, co se ti stará o internet, by ti neudělal aspoň port forwarde. Protože pokud ano, mohl by jsi na tom PI rozjet OpenVPN, nebo IPSEC a mohl jsi mít tak bezpečné spojení mezi klientem a serverem.

Pokud port forwarde není možný, tak bych šel cestou ipsecu, tzn. :
PI <- IPSEC tunel -> VPS <- IKEv2 -> klient (windows/linux/Android/iPhone)
Pro ipsec použít strongswan, nastavit IKEv2 a do androidu strongswan klienta z google play.
Toto je pak podle mně nejrychlejší řešení, protože případný ssh tunel nebude nic rychlého.
Zdar Max

[j]

Jen pro info ... openvpn, samba (widloserver) ... 50Mbit spoj. A je to tragedie. Funguje to, o to by neslo, ale ze by se to dalo realne pouzivat ... jak bylo receno, vsechno se taaaakleeee tahne, takze ulozeni par kB souboru znamena treba 30s cekat, nez se to dokonci. V tomhle pripade je to pouzivany k obcasnymu stazeni nejakych souboru, ale vlastni prace probiha lokalne, takze tak se to pouzivat da.

[Andrej]

To spíš vypadá na nějaký problém typu MTU a čekání na timeout, případně obecně na něco, co zkouší na síti nějaký fallback po marném čekání (sekundární DNS, pofidérní nastavení firewallu atd. atp.). Pokud je latence třeba 50 ms, asi je jasné, že přenos pár kB nemůže trvat 30 s, pokud něco není hodně špatně.

[ehmmm]

Mozna, ze "j" tradicne trochu prehani (ale aspon tentokrat neni sprostej a neurazi), ale jinak prostrkavani Samby je fakt bida.

Shodou okolnosti jsem ji nedavno zkousel prostrcit skrz OpenVPN nebo SSH a fakt to bylo pomale. Pres to OpenVPN jeste pomalejsi nez pres SSH. Nekde jsem se docetl, ze ten protokol (Samba) na to fakt neni stavenej.

IPSec me taky napadlo, ale zkusenosti s nim mam spise spatne nez dobre a hlavne malo (vlastne vzdy pouze jako klient). Takze to si nechavam na jindy.

[Josef Kufner]

Ono hlavně ten protokol byl kdysi vyvinut IBM, kterého pak opustilo, neboť to stálo za prd. Microsoft se toho ale chytil a pokračoval. Dodnes to i na LAN běží poloviční rychlostí než vše ostatní.

[petrfm]

bohuzel dodnes to nema na lan konkurenci. pokud nepocitam nfs bez jakehokoliv zabezpeceni. nebo snad existuje protokol pro prenos souboru s autorizaci? samba je mozna pomala, ale funguje, dokonce napric vsemi platformami.

[Peter Golis]

WebDAV?

[j]

Blbejsi napadat nez tlacit soubory pres http jeste nikdo nevymyslel ... a nic na tom nemeni ani to, ze to pouziva miliarda lidi.

[Peter Golis]

NFSv4 s Kerberosom?

[petrfm]

A přihlásím se k tomu z Androidu? Z WIN? .... Samba mozna stoji za prd, ale je multiplatformni a dela za par minut to, co potrebuju. Nevim, proc autorizace neni soucasti protokolu pro prenos souboru. To je jako by se k FTP serveru mohl pripojit kazdy.

Navic, pres webdav si treba nepustis film. Respektive pustis, ale nejdrive ho musis stahnout. Pres sambu ti ten film pojede okamzite, takze se daji treba zobrazit nahledy, nebo si pustis ukazku a zase zavres, pres webdav musis pretahat cely disk, pokud neco hledas a potrebujes si to na par sekund pustit. V tomhle proste samba nema rozumnou konkurenci.

[Peter Golis]

Pokiaľ berieš limitácie uzatvoreného OS alebo uzatvoreného FW za etalón, tak tvoja otázka na tomto fóre postráda zmysel. Mal by si ju položiť technickej na podpore firmy MS, alebo firiem od ktorých máš tie androidové krabičky.

Ale inak, áno. Windows obsahuje podporu pre NFS aj s autorizáciou, a Android občas zvykne mať podporu aj pre NFS. A občas nemá podporu pre Samba/CIFS.

PS: Inak, mohol by si prezradiť na základe čoho si myslíš že je Samba/CIFS všeliek pri rozvetvených LAN a WAN všeliek, a vhodným riešením.

[petrfm]

pozor, ja nerikam, ze samba je nejaky vselek, nebo snad jenom lek. Ja rikam, ze samba je dnes stale jedine rozumne reseni, jak sdilet soubory v siti, pokud k nim chci pristupovat z vice zarizeni a pokud chci mit nejake elementarni zabezpeceni, aniz bych si k tomu musel nastudova stostrankovy manual.

Argumentace tim, ze problem je na strane MS, nebo Androidu jsou vhodne do filozoficke debaty, ale ne do realneho zivota. Problem mam ja, jako uzivatel, pokud potrebuju sdilet soubory. A samba ten problem resi, mozna ne dokonale, ale nejlepe ze vsech dostupnych protokolu. A ze nikdo nic lepsiho nevymyslel mne sice trapi, ale nic s tim nenadelam, lepsi protokol si napsat neumim a protlacit jej do vsech pouzivanych zarizeni sam nezvladnu. Tak pouzivam sambu a jsem rad, ze sdilim

[petrfm]

jo a pouzivam sambu pres net, na 20Mbit pripojeni se to chova jako normalni lokalni disk, nevidim na tom zadny problem. S 2Mbit wifi netem budou problemy i s prochazenim dnesniho webu, to se neda nic delat, mozna je lepsi zamerit se na problem s internetem, nez na sambu.

[Peter Golis]

Tu ale nie je problém s internetom, tu je problém s WAN Intranetom cez VPN v inom sieťovom segmente bez broadcastov.

[j]

To neni o tom, ze by 30s trval prenos, to je o tom, ze 30s trva, nez se aplikace domluvi s "diskem", ze se ulozeni povedlo. Kdyz pres to budes tlacit 10GB v jednom souboru, tak to bude ptakticky saturovat linku, ale kdyz to dojede, tak si tech 30s pockas na to, nez to z tech 99% skoci na 100%. Ona se samba stejne chova i na LANce, jen to tam je proste diky radove jinym parametrum linky v mezich akceptovatelnych pro praci.

[Fastmancz]

Tak nakonec Orange Pi One dorazil do 19 dní a vše běží bez problémově. Samba je tažená přes VPN, tak jak jsem potřeboval.