Sziasztok!
Már egy ideje szívok ezzel a problémával.
Adott egy Debian 5-ös szerver. Ezen a szerveren van Samba és OpenVPN is.
A szerver lokálisan a 10.0.0.51-es IP-re hallgat, míg OpenVPN esetén 10.8.40.1.
Ha lokális gépről tallózom a megosztásokat, akkor szépen megjelennek a Samba-ba beállított megosztások, viszont ha OpenVPN-en keresztül megyek, akkor nem tudom tallózni, a Windows nem tud kapcsolatot teremteni.
A probléma csak Samba-val van, mert OpenVPN-en keresztül pingelni tudom a szervert és még az SSH is megy 10.8.40.1-re.
Ha az OpenVPN-be felveszem, hogy route-olja a 10.0.0.0-ás hálót, akkor a .51-es IP-re hivatkozva működik a Samba. (Csak a probléma, hogy az a hálózat ahonnan OpenVPN-en mennénk fel szintén 10.0.0.0-ás hálózat, így összeakad)
A Samba-ba fel van véve az interfaces-be a 10.8.40.0-ás háló, de semmi. iptables-ben sincs semmi olyan szabály ami tiltana.
Szerintetek merre keressem a hibát? Conf-ot tudok adni ha kell.
Szerk.:
Azt el is felejtettem mondani, hogy ez korábban működött, majd egyszer megadta magát és azóta semmi. A hálózatban semmi változás nem történt.
OpenVPN újratelepítés már volt a szerveren. A Samba lenne a következő, de nem akarok felesleges fejfájást okozni a felhasználóknak.
Hozzászólások
Szerintem alapban van elcseszve a történet ha 10/8-as a subnet bármelyik oldalon.
Ha pedig nem az akkor ne titkold, mert amennyit leírtál az alapján nem nagyon lehet segíteni...
10/24 mind a két oldal
Mi kell? Mit adjak meg?
Mar mindegy. Nem jo de nem okoz gondot.
Rosszul olvastam, szóval mindkét oldal azonos subnet (az mindegy hogy /8 vagy /24).
Nem ártana külön subnet-eket használni ha más cél is van, mint a .51-es IP-t elérni kliens oldalról. Ha csak ezt kell elérni, akkor kliens oldalon nem kell kiosztani a .51-es IP-t és csak azt kell route-tal letolni (push "route 10.0.0.51 255.255.255.255").
Egyébként site2site vpn-t akarsz?
Legegyszerűbb talán ha a dhcp-kiosztásban tiltod az 51-es IP-t
Persze attól még eléggé kókány
--
God bless you, Captain Hindsight..
Ha broadcast-tal megy a browsing (nincs WINS szerver), akkor tap mod kell az openvpn-ben, es bridge hasznalata, ami maceras. Egyszerubb IP cimmel hasznalni a VPN-es klienseken a sambat futtato gepet. Ha a samba elobb indul, mint az openvpn felhuzza a lokalis IP cimet, akkor nyilvan nem fogja hasznalni az smbd a nem letezo IP cimet. lsof megmutatja, milyen socketeken erheto ez az smbd, ezzel ellenorizheted. Az SSH jo esellyel 0.0.0.0-an figyel (az smbd is, ha nincs megadva az interfaces / bind interfaces only).
+1 igy kezd. Ip alapon mukodnie kell.
Ha megy akkor mar lehet a dnsel bibelodni.
Ahhoz, hogy a win "natívan" lássa OpenVPN-en keresztül tap interface és bridge kell kell mindenképp. Tun-al és routolással is összehozható, de akkor - tudtommal - a "sima" win tallózással nem fogod látni a sambát.
Első körben megnézném, hogy a bridge rendben van -e? Valami hasonlót kellene látni:
==================~# brctl show
bridge name bridge id STP enabled interfaces
br20 8000.00e04fd93830 yes eth1.20
tap20
br21 8000.00e04fd93830 yes eth1.21
tap21
br22 8000.00e04fd93830 yes eth1.22
tap22
==================================
Tehát egy meglévő interface és egy tap interface legyen párban.
Ahogy előbb említették, nagy galibától mented meg magad, ha a bridge előbb áll fel, mint az OpenVPN és majd csak ezt követően induljon a samba.
Mindenkinek köszönöm a segítséget és tippeket!
Sikerült megoldani a problémát. A Samba conf-ból kivettem az interfaces sort és most működik a Samba OpenVPN-en keresztül. (Bár még most sem értem, hogy miért szállt el egyik napról a másikra)
Tudom, hogy kókány megoldás az egész, de ezt így örököltem meg. A Debian szerver nem a mi cégünknél van és még valamelyik elődöm telepítette. Az ottani hálózatba nekünk nincs beleszólásunk, azt ők alakították ki.
A mi oldalunkon tudom, hogy nem jó a 10-es háló, mert alig vannak gépeink, de ezt is csak megörököltem és még nem volt idő, hogy átszervezzük az egész hálózatot (pedig ráférne).