Egy publikus IP-vel rendelkező szerveren futó megosztást szeretnék elérhetővé tenni külső gépek számára, ami részben sikerült is OpenVPN segítségével a következő konfig szerint. A gond az, hogy van egy kisebb vállalati hálózat, ahonnan proxy mögül jönnek ki a gépek. Itt kívülről az IP címük azonos, belső címük 192.168.1. (dhcp-vel kiosztva). Meg lehet valahogy engedni, hogy ezek a kliensek vpn nélkül is fel tudják csatolni a samba megosztást? Az nem vezetett eredményre, hogy a hosts allow részénél az adott IP-t is beírtam sem a kisebb vállalati hálózat esetén, de ha egy normál ADSL hoszton tesztelem az épp aktuális IP-vel. Azért kellene kiküszöbölni ennél a vállalati hálózatnál a VPN használatát, mert a rendszergazdák nem igazán tudták eddig a klienseket és a belső hálózatot beállítani.
(Tehát logikailag valami olyasmiről lenne szó, hogy ha van egy távoli szerverteremben egy szerver, amin elérhető egy samba megosztás, hogyan lehet engedélyezni, hogy vpn-el és fix IP-vel rendelkező kliensek is kapcsolódhassanak hozzá.)
Nagyon köszönöm a segítséget előre is!
[global]
workgroup = valami
netbios name = akarmi
guest ok = yes
read only = yes
security = user
encrypt passwords = yes
guest account = nobody
interfaces = eth0 tun0
hosts allow = 10.8.0.0/24
[test]
comment = teszt megosztas
path = /home/teszt/samba
valid users = teszt1
browseable = Yes
read only = no
guest ok = no
Hozzászólások
hosts allow: cég külső ip címe/32, gateway forwardolja a 137től a 139 tcp-t, + a 445 -öt esetleg (ez elvileg a netbios névszolgáltatás, lehet hogy ez esetben mellőzhető), és nyilván a sambás gép tűzfalán is ezek a portok nyitva legyenek..
--
Imperare sibi maximum imperium est.
A vállalati belső hálózathoz nincs hozzáférés. Gatewayen nem hinném, hogy nekem bármit is állítanának, ha a kliensen nem akarnak. :S
(Vállalati hálón kívülről ezek a portok egyébként nem látszanak.)
sambát simán kitenni publikus IP-re? Hát, te tudod... Én biztos, hogy nem tenném. Kizárólag VPN. Azt viszont nem feltétlenül kell kliensenként, hanem a kis vállalati proxy-t (ha hozzáférsz) is össze tudod VPN-ezni a sambával, amit megfelelő route beállítások után így a belső háló összes kliense elérhet.
+1
Bár nem igazán értem
"a rendszergazdák nem igazán tudták eddig a klienseket és a belső hálózatot beállítani"
melyik oldalhoz nincs hozzáférés?!
Azt szeretném, hogy a Sambát csak VPN-en keresztül lehessen elérni és igazából a vállalati IP engedélyezése is csak egy utolsó utáni megoldás lenne...
A szerverhez van hozzáférés, ami nem része a vállalati hálózatnak.
A helyzet azért bonyolult mert...
Adott egy vállalati hálózat, akinek a rendszergazdái nem tudtak adni néhány száz MB olyan tárterületet egy részlegnek, ami a belső hálózatból is és kívülről biztonságosan (VPN-en keresztül) elérhető. Erre azért lenne szükség (mint mindenhol máshol a VPN-re), hogy a hetekig külföldön vagy cégen kívül lévő főnök és néhány kolléga távolról is hozzáférjen az adatokhoz. Az a megoldás született, hogy vettünk egy nem mai gyerek, de jól működő és olcsó szervert, amit a vállalati IT a vállalati hálózaton kívül beállított nekünk egy publikus IP-n, amit mi felügyelünk és ígéret született rá, hogy VPN-en keresztül ezt majd elérjük.
Jelenleg a dolog a VPN klienseken a routolással hasal el, ahol a gépeken nincs rendszergazda jog (márpedig elvileg sehol sincs). A kliens kap a vpn szervertől IP-t csak a megosztást nem érjük el. Ezért gondoltam, hogy ha a vállalati IP-t engedélyezem, akkor belülről a VPN megkerülhető.
Tehát eddig volt egy minimális belső tárhely, amit belülről elértünk, most meg van egy külső is, amit kvázi csak kívülről érünk el, vagyis nem jutottunk sehová, csak az látszik, hogy működhetne a dolog, ha nem ütköznénk belső falakba. Az ugyanis, hogy a belső IT-val harcol az ember, aki pénz, idő vagy hozzáértés hiányában várakozásra kényszerít, az nem megoldás, mert úgy nem lehet hatékonyan dolgozni.
Ha majd próbálok egy belső vpn logot küldeni, hátha pofonegyszerű a vállalati kliensek beállítása, csak jogok nélkül elég nehéz kitalálni, hogy mit kellene módosítani vagy engedélyezni.
Ha jól értem
- belső hálózatba vpn-en keresztül be lehet jutni (kapsz ip a belső hálózatban)
- a vpn nem a samba szerveren van
"vállalati hálózaton kívül beállított nekünk egy publikus IP-n"
Ez mit jelent az internet felől közvetlen elérhető vagy a belső hálózatban egy fix ip amire a tűzfal át tud forward-olni bizonyos portokat?
Nem lehet, hogy a vpn-es szerveren a nincs bekapcsolva az ip_forward (már ha Linux)?
- a vpn és a samba egy szerveren van (Deian Lenny + openvpn)
- ez a szerver nem része a vállalati hálózatnak, publikus, az internet felől elérhető fix IP-je van (logikailag olyan, mintha lenne egy vállalati hálózatod, a szerver meg egy szerverhotelben lenne egy másik IP-n)
- a belső (vállalati hálózatba) nem lehet vpn-el bejutni, pont fordítva nem megy a dolog: a belső vállalati hálózatból kellene tudni kijutni a külső publikus ip-vel rendelkező szerver "hálózatába", ami mögött nincs local hálózat, mert nincsenek mögötte gépek fizikailag csak virtuálisan kapcsolódnak hozzá a vpn kliensek és érik el a megosztást
- a vállalati hálózaton kívülről (mobilnet, otthoni adsl, kábelnet) felépül a vpn kapcsolat, látszik a samba megosztás, használható, csak bentről nem
- bentről a nem admin jogú kliensen is szépen felépül a kapcsolat, kapok a 10.8.0.x-ből IP-t, csak a helyi hálózatot nem routolása nem sikerül (ha a kliensen rendszergazda van bent, akkor meg megy).
Ezért írtam, hogy küldök majd, ha eljutok odáig egy belső vpn kliens logot a nem admin joggal futó xp kliensről, mert amelyik kliensen rendszergazdaként indítják el a vpn-t arról megy, de nem fognak rendszergazda jogot adni. Itteni IT meg nem tud felülkerekedni ezen a problémán én meg ha kérek valamit, hogy esetleg nem-e így vagy úgy kellene beállítani a klienst, akkor az n hét...
A VPN és a valós háló hálózati címtartománya ugyan abban van vagy különböző?
- vpn: 10.8.0.y (samba: 10.8.0.1)
- vállalati kliensek belső ip: 192.168.1.z
(A vállalati külső IP és a szerver publikus IP-je az egy tartományban van: a.b.c.45 és a.b.c.49 )
A logokban ez utal hibára (a nem rendszergazda joggal futó vállalati klienseken):
"
NOTE: FlushIpNetTable failed on interface [65540] {94EC6E4B-6CA3-4909-B97C-0E3ED29D9C07} (status=6) : A leíró érvénytelen.
TEST ROUTES: 0/0 succeeded len=2 ret=0 a=0 u/d=down
Route: Waiting for TUN/TAP interface to come up...
.
ez párszor egymás után, majd
.
C:\WINDOWS\system32\route.exe ADD 192.168.0.0 MASK 255.255.255.0 10.8.0.23
Warning: route gateway is not reachable on any active network adapters: 10.8.0.23
Route addition via IPAPI failed [adaptive]
Route addition fallback to route.exe
Az útvonal hozzáadása nem sikerült: Vagy hibás a kapcsolatindex, vagy az átjáró nincs a kapcsolattal egy
hálózatban. Ellenőrizze a számítógép IP-címtábláját.
"
Miért is akarsz egy 192.168.0.0 alhálót routolni, ami gyakorlatilag kizárólag magát a samba szervert takarja? (ha jól vettem ki a fentieket)
10.8.0.23-on sem éred el direktben a Sambát?
Mellékesen "dícséretes" hogy egy "komoly" IT-val rendelkező cégnél a cég és a vezetők érdekeit kiszolgáló - viszonylag egyszerű - IT megoldásra külső ember kell, akinek a belső IT ott tesz keresztbe, ahol tud és ezért fentről még seggbe sem rúgják őket :(
Gondolom, a belső IT-n bukik meg az irodai router össze-vpn-ezése a külső sambával is - amivel legalább egyszerű lenne a történet.
Anno a szervert otthon installáltam és állítgattam be meg teszteltem, úgy ahogy gondoltam, hogy jó lesz, onnan maradt benne a push "route 192.168.0.0 255.255.255.0"
Ha kikommentezem, akkor sem vagyok előrébb, mert akkor meg ilyen hibákat kapok:
"
C:\WINDOWS\system32\route.exe ADD 10.8.0.0 MASK 255.255.255.0 10.8.0.23
ROUTE: route addition failed using CreateIpForwardEntry: A hálózati hozzáférés megtagadva [status=65 if_index=3]
Route addition via IPAPI failed [adaptive]
Route addition fallback to route.exe
Az útvonal hozzáadása nem sikerült: A hálózati hozzáférés megtagadva
Initialization Sequence Completed
"
Amit a mellékesben írsz teljesen igaz lenne egy pénzhajhász profitorientált cég esetén, de amikor egy nonprofit jellegű dologról beszélünk, akkor másképp fest a dolog. Az, hogy a vezetők érdekeit mi szolgálja, arról jobb nem beszélni, a belső IT is ki van nekik szolgáltatva és rengeteg igény lenne, amire nem kapnak forrást. Rugdossák őket rendesen szerintem. Én sem konkrétan erre lettem felvéve, csak úgy mellékesen kellene megvalósítani a dolgot és tényleg szükség lenne rá. Viszonylag valóban egyszerű megoldásról lenne szó. A legrosszabb az, hogy úgy kell dolgozni, hogy tudod azt, hogy sokkal egyszerűbben is lehetne, van rá megoldás és akkor minden helyről falakat építenek. Még az sem gond, ha nekem kell rájönnöm, hogy mit hogyan kell csinálni...
Csak kezdem már azt érezni, hogy ehhez is kell érteni kicsit, ahhoz is kicsit, aztán tulajdonképp semmihez sem tudok érteni kicsit többet. Ha meg nem próbáljuk megváltani a környezetünket, akkor beállok abba sorba, aki gépiesen elfogadja azt, ami van és dolgozik úgy, ahogy tud.
Hát lehet, hogy sima user-rel nem fog menni, valószínűleg kellene legalább egy "Network Operators" csoport tagság
Egy VPN config-ot be tudsz ide tenni?
"
port 1194
proto tcp
dev tun
ca /etc/openvpn/ca.crt
cert /etc/openvpn/server.crt
key /etc/openvpn/server.key
dh /etc/openvpn/dh1024.pem
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist /etc/openvpn/ipp.txt
push "route 192.168.0.0 255.255.255.0"
keepalive 10 120
comp-lzo
client-to-client
persist-key
persist-tun
status /var/log/openvpn/openvpn-status.log
log /var/log/openvpn/openvpn.log
verb 3
mute 20
"
write only mód miatt törölve :)
Szia!
A VPN kliens nem fog menni, ha nem rendszergazdaként futtatod! Nálunk is volt ebből probléma, de ha csak a kliens fut rendszergazdaként, akkor minden rendben van.
Üdv,
Imi
Valóban ez lesz a megoldás, hogy a kliens rendszergazdaként fusson.
Hogyan lehet ezt megoldani valamilyen biztonságos módon?
Ha "runas /savecred /user:admin"-al csinálják, akkor a rendszergazda jelszava elmentésre kerül és gyakorlatilag bármi futtathatóvá válik a gépen rendszergazdaként. Ha szolgáltatásként indul, akkor meg elvész a kontroll, vagyis a user nem látja, hogy felépül-e a kapcsolat (gondolom én).
Ezt az egészet el kell felejteni, tessék azt a pár tízezret kiadni egy win licencért és máris minden remekül fog működni, erre az való.
Én ugyanezt a problémát ssh-n keresztül oldottam meg. Csak egy ötlet, ha esetleg érdekel. http://alirezabagheri.com/blog/?p=67
Putty helyett myentunnel-t használtam service-ként.
+1 mármint az ssh tunnel-re, persze ehhez kell login a samba-s gépre.
Talán egy másik megoldás lehet a WebDAV ami tulajdonképpen megkerüli a Samba-t.