Van egy VPS-em, amit pár hónapja kezdtem el használni.
OpenVPN-t tettem fel rá, de nem indul, mert nincs tun interface.
Régen nem kellett linuxot adminisztrálnom, de ha jól sejtem, még mindig az a koncepció, hogy ha a kernel támogatja a tun interfészt, akkor automatikusan létre is jön a /dev alatt valahol a hozzá tartozó device file.
Tehát ha nincs file, akkor nincs támogatás a kernelben.
A saját gépemen a gyári Debian stretch kernel tartalmazza, ami kell, és van device file.
A VPS-en is Debian van, de ahogy nézem, valami nagyon régi kernel verzió fut, és a telepített Debian jessie-ből semmilyen kernel csomag nincs fent.
Hogy megy ez?
A VPS üzemeltetője rakott össze egy kernelt, és a virtuális gép ezt tőle kapja meg? Ha valami nekem nem tetszik, akkor tőle kell kérni, hogy adjon másfélét?
Vagy egy kernellel szolgálja ki az összes ügyfelet, és ha nem tetszik, amit ad, akkor mehetek máshová vagy tegyek le az openvpn-ről?
Hozzászólások
Na jó, felvettem egy ticketet. Meglátjuk, mit írnak majd.
Sajnos a szolgáltató azt mondja, az én csomagomhoz nem tudnak tun interfészt adni.
A következő ötletem az ssh tunnel lenne, de amikor régebben használtam, akkor az egy minden korlátozás nélküli ssh kapcsolat volt.
Tud úgy ssh tunnelt nyitni egy távoli felhasználó, hogy nem adok neki shell hozzáférést?
Tudom valahogy korlátozni, akár sshd konfigurációval, akár iptables konfigurációval, hogy csak bizonyos portokhoz férjen hozzá?
Na megyek manuált olvasni és google barátomat zaklatni a témával.
Ha valakinek van pozitív / negatív tapasztalata, vagy valami mást javasolna, nyugodtan írja ide!
"Sajnos a szolgáltató azt mondja, az én csomagomhoz nem tudnak tun interfészt adni."
Sajnos, nagyon félreértettek téged. Ők szvsz. valami távoli admin interface-re gondoltak, nem a virtuálgépeden létrehozható, helyileg kezdeményezett vpn-re.
egyáltalán nem biztos, ha valami lightweight cucc (openvz, lxc) ami shared kernelt csinál, ott nem biztos hogy megy.
Az már tárhely, nem vps a szememben.
hát, azért egy tárhelynél lényegesen több. Ráadásul az, hogy a te szemedben mi, az nem nagyon tántorítja el a piacot attól, hogy vpsnek hívja ezeket :)
Hát, tárhely, de a tárhelyre feltelepített Linux disztribúciót a shared kernel azért futtatja is.
Ez az első alkalom, hogy VPS-t használok, szóval igazából nincs összehasonlítási alapom.
Ahogy írtam, nincs kernel csomag telepítve, nincs boot loaderem, szóval nekem is az a feltételezésem, hogy valamilyen shared kernel lehet.
Mindkettőbe lehet (technikailag). Más szolgáltatóknak sem akadály (ha akarják).
MikroVPS | 50% kedvezmény VPS-re HUP50 kuponnal
tudom, de szokták nem akarni.
(illetve ha jól rémlik, valamelyikkel nem annyira ment régen)
Nyugi, tök jól lehet korlátozni.
Egyrészt persze, lehet neki nem adni shellt, lehet akármit is kizárólagosan futtatni ForceCommanddal, le lehet csapkodni egy csomó dolgot (AllowAgentForwarding, AllowAgentForwarding, AllowTCPForwarding, GatewayPorts) be lehet rakni a sessiont egy chrootba (ChrootDirectory, bár ez nem teljesen triviális), PermitOpen-nel meg lehet mondani, hogy pontosan hova kérhet portforwardot, meg ilyesmik. Az egészet össze lehet fogni egy Match User akárkivel.
sshnak meg lehet mondani, hogy -N, akkor nem indít semmit, csak a portforwardok és hasonlók mennek.
Igen, találtam tegnap éjjel elég jó és részletes leírást.
Az ssh -N-re nem hagyatkozhatok, az ssh-t nem én fogom indítani. Viszont ezekkel a fentiekkel az ahhoz a felhasználóhoz tartozó dolgokat jól le fogom korlátozni, csak végig kell majd alaposan tesztelni, nehogy valamit elnézzek.
A -Nre természetesen nem hagyatkozhatsz. Az azért van, hogy kényelmesebb legyen a kliens :)
Szerintem igazából egy:
Illetve én még elé kb ezt betolnám (vagy még valami ennél is erősebbet, ez a reasonably jó, amit arra használok, hogy defaultból sshzzak vele össze vissza, de nyilván ha a server oldalra is van ráhatás, akkor)
Egyébként meg vmelyik nap ezt láttam:
https://github.com/apenwarr/sshuttle
Érdekes, hogy a leírás, amit találtam, azt mondta, hogy AllowTcpForward no, és PermitOpen localhost:1234 az jó lesz, csak a távoli gép 1234 portját érem majd el.
De ez így nem működött.
Viszont az általad javasolt AllowTcpForward local + PermitOpen az működik, és a fel nem sorolt portokhoz nem tud kapcsolódni.
Fura ez a logika, hogy ha nincs PermitOpen, akkor bármit elérhetsz, de ha engedélyezem az 1234-et, akkor a többit ezzel tiltom.
Bocs, elég offline hétvége van :)
Bár eddig nem tűnt fel, hogy kicsavart logika, de belegondolva értem miért gondolod annak. Az van, hogy ez nem egy tűzfal konfig, szóval nem olyan rossz az, hogy ha valami speciálist nem akarsz állítani, akkor nem játszik, hogy ne kelljen külön kapcsolgatni (a gyakorlatban egyébként az is van, hogy a permitopen defaultja egy csillag szerintem).
Azt viszont nem nagyon hiszem, hogy AllowAkarmiForward no mellett menne forward. Viszont érdemes az összes negatív caset végigtesztelni, hogy nem enged olyat, amit nem kéne, biztos amit biztos.
Pedig ennek van egy nagyon egyszerű és logikus oka: a PermitOpen sokkal frissebb fejlesztés, régen ilyen nem volt. Ergó ha csak szépen upgradeled a sw-t, de a konfigod régi, akkor az nem volna túl sysadmin-friendly hozzáállás, hogy "egyszercsak" elbaszódik a korábban működő konfig, merthogy bevezettek egy új konfig opciót, ahol a default más, mint az eddigi default működés. A másik része a dolognak (hogy ha valamit engedélyezel, akkor miért lesz a default a tiltás) meg pragmatizmus: ha már hozzányúltál a konfighoz és beraktál egy PermitOpent, akkor az előző érv már nem játszik, viszont így nem kell plusz egy extra opcióval megmondanod, hogy amúgy a felsorolt engedélyezett dolgokon kívül minden más tiltott - ez a logikus default ugyebár, annak kevés értelme van, hogy felsorolom az engedélyezett portokat, plusz még a default is engedélyezés.
Hm. A dev fájlt fejből nem tudom, de maga az interfész attól lesz, hogy csinálsz egyet. A használt OS verziótől függ, hogy hogyan. A legkönnyebb az "ip tuntap add dev tun0 mode tun" paranccsal. De ha régi a telepített iproute csomag, akkor próbáld az openvpn-nel magával: "openvpn --mktun --dev tun0"
=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?
Ha LXC alapú a VM, akkor ott alapból nem nagyon szokott tun-od lenni, külön kell engedélyezni (http://serverfault.com/questions/429461/no-tun-device-in-lxc-guest-for-…). IntoVPS-nél pl. annyi, hogy az admin panelen kattintanod kell egyet, hogy kapj egyet.
Szerk.: az IntoVPS ráadásul nem is LXC, hanem OpenVZ, de gizikegőzeke.
BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)
úgy szokott az menni, hogy külön meg kell engedélyezni... van amikor megengedik neked a panelből, de van amikor a szupport csinálja.
Lehet félreértelek. Olyan nincs hogy /dev/tunX vagy /dev/ethX
A hálózati interfészeket legegyszerűbben (szerintem) úgy tudod megnézni, hogy # ifconfig -a
* Én egy indián vagyok. Minden indián hazudik.
/dev/net/tun van, ha van :) Lásd: https://www.kernel.org/doc/Documentation/networking/tuntap.txt
BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)
No ez már egy harmadik malom :(
Persze, ha a kernel nem tartalmazza a tun modult, vagy nincs beforgatva akkor nincs, nem lesz. Nem tudjuk milyen Linux -ot pakolt fel, de elvileg a /boot/config-"kernel verzió" -ban benne van mi is került bele.
Viszont ha ott van, akkor sincs aktiválva, mindaddig amíg valami nem igényli. Az "# ifconfig -a" minden pillanatnyilag létező interfészt listáz akkor is ha inaktív. Mármost a gépemen nincs tun, pedig be van forgatva (modul) de ahol feltelepítettem (router OpenWrt) az OpenVpn -t ott él és virul a tun (akkor is megvolt amikor még nem volt jól konfigurálva) :)
* Én egy indián vagyok. Minden indián hazudik.
A /boot könyvrár üres.
Akkor az valami virtualizáció (LXC/OpenVZ/...), úgyhogy külön kell bekapcsoltatni a tun támogatást. A ticketre nem válaszoltak? FAQ-ban nincs benne? Control panelen gomb? :)
BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)
Control panelem nincs.
Ticketre válaszoltak, azt mondták, nem tudják a tun-t bekapcsolni nekem.
Jellemzően nincs sok különbség egy OpenVZ-s és egy rendes VPS árában, így érdemes lehet váltani.
+1
A modprobe tun parancsra mi a válasz?
Nincs ilyen modul
gee, kíváncsi lennék, mi is ez a "VPS" szerver, amit bérelsz. A reklám elkerülése érdekében küldd el, légy szíves, magánban a szolgáltatás linkjét. Előre is köszi.
(Semmi rosszindulat, tényleg kíváncsi vagyok, mit is árulnak vps-ként, ergo: hol a "kereskedelmi határ" a tárhely (nem mezei pl. back-up tárhelyre gondolok) és a vps között.)
elküldtem.
Megnéztem, köszi. Ezért az árért kapsz olyan VPS-t, ahol magad választhatod ki az oprendszert, és a "vas" ua. vagy még jobb is, mint amit most bérelsz.
Nem akarok reklámozni senkit, ezért, ha nem érzed problémának, akkor oszd meg a linket bátran, mert úgy is lesznek itt sokan, akik bemutatják a saját kínálatukat.
(Ha kéred, akkor privátban javasolhatok egy céget, de azt is csak azért, mert pozitív tapasztalataim vannak irányukban.)
Igazság szerint, eddig, ezen kívül nincs velük bajom, ezt meg az ssh tunellel megkerültük. Szóval egyelőre (amíg más gond nem jön), nem annyira vagyok motivált, hogy váltsak.
Én választhattam, hogy Debian legyen rajta (nem tudom, miért CentOS-t írnak a leírásban).
Illetve annyi még, hogy fontos volt, hogy helyben (vagyis UK) legyen a szerver, az itteni belföldi hálózaton menjen.
Az a tippem, hogy akik itt sokan a sajátjukat kínálnák, azok közül inkább Magyarországon lesznek a gépek, nem az Egyesült Királyságban.
"Az a tippem, hogy akik itt sokan a sajátjukat kínálnák, azok közül inkább Magyarországon lesznek a gépek, nem az Egyesült Királyságban."
Ebben igazad van.
---
Kiscicák reality.
aceshells nagy barátom már évek óta uk felé ;)
huh, nagyon regen hasznaltam: ppp-vel (+ssh) is lehetett valami titkositott kapcsolatot csinalni, egy-ket userhez meg az is jo lehet.
--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!