Newsgroup: it.comp.os.linux.sys
Titolo: Wins tramite VPN

Ciao a tutti,
ho realizzato una VPN con OpenVPN. Tutto funziona correttamente tranne la
risoluzione dei nomi NetBIOS delle macchine. Una macchina della rete
interna raggiunta dalla VPN funge da PDC+WINS; il browsing delle risorse
condivise viene effettuato correttamente se utilizzo l'indirizzo ip delle
macchine remote, mentre fallisce la risoluzione del nome.
10.8.0.8.netbios-ns>server.netbios-ns:NBT UDP PACKET(137):QUERY;REQUEST;UNICAST
server.netbios-ns>10.8.0.8.netbios-ns:NBTUDPPACKET(137):QUERY;NEGATIVE;RESPONSE
Questo è il log di una richiesta di risoluzione da parte del client
connesso in VPN; la stessa query fatta direttamente da una macchina delle
rete interna invece da esito positivo. La versione di Samba che ho sul
server PDC+WINS è la 3.0.5. Ho cannato qualcosa?
Grazie,
Andrea.

 
Mi correggo, non è un problema di VPN, ma di WINS; nella rete locale le
richieste vengono fatte in broadcast (e funzionano). Se faccio un query
sul server nessun nome mi viene risolto:
querying robertod on 127.0.0.1
Negative name query response, rcode 0x03: The name requested does not exist.
name_query failed to find name robertod
Avete qualche idea?
Grazie,
Andrea.

Mandi! Andrea Cerisara
  In chel dí si favelave...
AC> server PDC+WINS è la 3.0.5. Ho cannato qualcosa?
WINS per definizione non passa i gateway, va solo in broadcast. O usi
OpenVPN in bridged mode e non in routed mode, oppure ti metti a
giocherellare con il server wins capace di replica che il progetto
samba ha appena rilasciato, ancorchè in beta.
-- 
  I matti tutta la vita dentro la notte
  chiusi a chiave					(F. De Gregori)

WINS per definizione non passa i gateway
Questo non è vero. Wins serve proprio per passare i gateway, dato che
è una connessione punto-punto. Tu sul client imposti un server wins
a.b.c.d e il client lo può raggiungere.
E' la risoluzione tramite broadcast che non riesce a passare i
gateways.
-- 
Ci sono 10 tipi di persone al mondo: quelle che capiscono il sistema binario
e quelle che non lo capiscono.

 samba ha appena rilasciato, ancorchè in beta.
Ti confondi col netbios.



Non necessariamente.
Il netbios può utilizzare la risoluzione dei nomi punto-punto (ovvero
client che puntano a server wins) oppure quella in broadcast.
E' la risoluzione di nomi netbios in broadcast a non potere passare i
gateways, non il netbios tout court.


 WINS per definizione non passa i gateway
WINS è stato introdotto apposta per risolvere il problema
della risoluzione non in broadcast.
Fa un po' meno schifo della risoluzione in broadcast. ma fa
schifo lo stesso, questo è vero, tant'è che, con qualche decina
d'anni di ritardo rispetto al resto del mondo, da win2000 in poi
si dovrebbe risolvere solo via dns, in una struttura AD "pura".
-- 
Chaos A.D.		|	Raging crowd
Tanks on the streets	|	Burning cars
Confronting police	|	Bloodshed starts
Bleeding the Plebs	|	Who'll be alive?

> WINS per definizione non passa i gateway
w> WINS è stato introdotto apposta per risolvere il problema
w> della risoluzione non in broadcast.
w> Fa un po' meno schifo della risoluzione in broadcast. ma fa
w> schifo lo stesso, questo è vero, tant'è che, con qualche decina
..al di la dello schifo è difficile usare un server wins che non sta
nella tua rete, la soluzione a questo problema dovrebbe essere usare
dei wins server (uno per rete) in replica tra loro.
Solo che samba non implementa la replica.
Non per cercare di avere ragione a tutti i costi, e che stavo pensando
a questo è ho scritto quello. ;)
-- 
  ...ma quel suo volo certo vuol dire
  che bisognava volare					(F. Guccini)

dei wins server (uno per rete) in replica tra loro.
Cosa intendi per "è difficile"? Tu hai un client nella rete
192.168.1.0/24
 e il server wins in un'altra sottorete, esempio
192.168.1.50.
Sui clients imposti quel server, e se quel server è raggiungibile WINS
funziona.


 nella tua rete
Non per fare polemiche, eh, ma...
root@2[~]# ifconfig eth0.8
eth0.8    Link encap:Ethernet  HWaddr 00:06:5B:D9:18:B6
          inet addr:10.10.8.64  Bcast:10.10.8.255  Mask:255.255.255.0
          inet6 addr: fe80::206:5bff:fed9:18b6/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:6065 errors:0 dropped:0 overruns:0 frame:0
          TX packets:4972 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:2573191 (2.4 MiB)  TX bytes:853089 (833.0 KiB)
root@2[~]# route -n|grep ^0.0.0.0
0.0.0.0         10.10.8.1       0.0.0.0         UG    0      0        0 eth0.8
root@2[~]# ifconfig tap0
tap0      Link encap:Ethernet  HWaddr 5E:5C:43:E4:2C:05
          inet addr:10.66.0.250  Bcast:10.66.0.255  Mask:255.255.255.0
          inet6 addr: fe80::5c5c:43ff:fee4:2c05/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:2859 errors:0 dropped:0 overruns:0 frame:0
          TX packets:3489 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:1646826 (1.5 MiB)  TX bytes:346725 (338.5 KiB)
root@2[~]# route -n|grep 10.1.0.0
10.1.0.0        10.66.0.1       255.255.0.0     UG    0      0        0 tap0
root@2[~]# nmblookup -R -U 10.1.2.2 keydat
querying keydat on 10.1.2.2
10.1.2.82 keydat<00>
Ovvero: ho usato un wins remoto, che è su una delle mie reti aziendali,
arrivandoci via tap0, che è un'interfaccia creata da openvpn.
O forse non ho capito cosa intendevi dire?
(btw, possibile che abbia letto qualche tuo post su samba-it?)


 (btw, possibile che abbia letto qualche tuo post su samba-it?)
Ecco, sono nella tua stessa situazione, solo che il server WINS remoto
non risponde alle query. Eppure, sulla documentazione c'è scritto solo
di abilitare il suppporto con la direttiva adeguata. E' possibile
che ci sia un altro server WINS sulla rete?
Grazie,
Andrea.

Mandi! whiplash
  In chel dí si favelave...
w> root@2[~]# ifconfig tap0
tap, bridging, così non vale...
w> (btw, possibile che abbia letto qualche tuo post su samba-it?)
Si, possibile. ;)
-- 
  La nave è ormai in mano al cuoco di bordo, e ciò che trasmette
  il megafono del comandante non è più la rotta ma ciò che
  mangeremo domani.				(Sören Kierkegaard)

Mandi! Valerio Vanni
  In chel dí si favelave...
VV> Cosa intendi per "è difficile"? Tu hai un client nella rete
VV> 
192.168.1.0/24
 e il server wins in un'altra sottorete, esempio
VV> 192.168.1.50.
..hem, 192.168.1.50 è in 
192.168.1.0/24.
..
VV> Sui clients imposti quel server, e se quel server è raggiungibile WINS
VV> funziona.
..ma solitamente per questioni di efficienza si tende a mettere un
server wins per ogni rete, e a quel punto avresti due server wins...
-- 
 Due cose sono infinite: l'universo e la stupidità umana,
 ma riguardo l'universo ho ancora dei dubbi.	(A. Einstein)

 tap, bridging, così non vale...
Niet: il bridging ha un senso differente, nel mio caso.
Il wins non è comunque sulla sottorete della tap.


server wins per ogni rete, e a quel punto avresti due server wins...
Non sono molto d'accordo. Un server wins ha un carico di lavoro
abbastanza basso e non c'è ragione di moltiplicarlo.
