Newsgroup: it.comp.os.linux.software
Titolo: accesso a internet con un client linux tramite un proxy windows

Lo so, lo so che si dovrebbe fare il contrario.
Solo che ci sono casi in cui non si puo`: accedo ad internet tramite un
wingate in rete locale e vorrei farlo con un client linux sulla stessa
rete.
Il client ha debian woody e sono riuscito a metterlo in rete: pingo gli
altri pc, compreso il proxy wingate.
Quest'ultimo fornisce dal mio lato l'accesso alle porte 25, 80, 110 e
1080.
Ho provato a installare lynx e mettere nel suo file di configurazione
http_proxy="
10.1.6.4:80
"
ma non riesco a navigare.
All'interno della rete c'e` un server DNS e mentre provavo la
navigazione ho controllato con netstat ed effettivamente il mio pc
interroga sulla 53 il DNS che ho configurato in /etc/resolv.conf, ma non
da segni di vita verso il proxy.
Quael'e` l'inghippo?
Potrebbe essere una questione di route? E, nel caso, che ropute devo
aggiungere?
Sempre lo stesso genere di problema esiste per gestire gli
aggiornamenti da rete con apt: ho letto man apt.conf e come suggerito
negli esempi della doc ho aggiunto al mio file una cosa del tipo:
// Options for the downloading routines
Acquire
{
  Retries "0";
  Proxy "
http://10.1.6.4:80
";
};
Ma, di nuovo non funziona.
Qualche aiuto?
TIA
-- 
manuel `fmf' ferrero | fmf@spiderman:~$%blow
 
http://fmf.come.to
  | %blow: No such job.

aggiungere?
Se ho capito bene ti manca solo:
# route add default gw 10.1.6.4
se e' quello l'indirizzo della macchina con wingate.

se e' quello l'indirizzo della macchina con wingate.
Allora, la situazione diventa complessa.
Chiariamo.
Questo  e`  il  comando  che  do  per  aggiornare la lista pacchetti con
debian:
 root@ferrero:~# apt-get update
 39%  [Connecting  to  
ftp.it.debian.org
  (213.92.8.5)]  [Connecting  to
 ftp2.it.debia
Questo  e`  l'output  di netstat mentre c'e' il tentativo di connessione
riportato sopra:
 root@ferrero:~# netstat -na
 Active    Internet    connections     (servers     and     established)
 Proto    Recv-Q    Send-Q   Local   Address           Foreign   Address
 State  PID/Program name
 tcp           0           0           
0.0.0.0:25
              0.0.0.0:*
 LISTEN 260/master
 tcp          0          1         
10.1.6.20:1029
 
213.92.8.5:21
 SYN_SENT 675/ftp
 tcp        0         1         
10.1.6.20:1030
 
130.136.3.200:21
 SYN_SENT 674/ftp
Come   si   vede  c'e'  il  tentativo  di  connessione  sulla  porta  21
(SYN_SENT), ma non c'e' risposta: dopo un po' va in time-out.
Queste sono le route dopo che ho aggiunto quella che mi hai  consigliato
tu:
 root@ferrero:~# netstat -r
 Kernel IP routing table
 Destination     Gateway         Genmask         Flags     MSS    Window
 irtt Iface
 10.1.0.0        0.0.0.0         255.255.0.0        U        40        0
 0 eth0
 0.0.0.0         10.1.6.4         0.0.0.0         UG         40        0
 0 eth0
 0.0.0.0         10.1.0.1        0.0.0.0         UG         40         0
 0 eth0
Non  conosco  molto  bene  la teoria sulle route, cosi' non funzionava e
allora ho pensato che fossero le due route  con  Destination  0.0.0.0  a
dare problemi e ho rimosso la seconda, queste sono le nuove route:
 root@ferrero:~# netstat -r
 Kernel IP routing table
 Destination     Gateway         Genmask         Flags     MSS    Window
 irtt Iface
 10.1.0.0        0.0.0.0         255.255.0.0        U        40        0
 0 eth0
 0.0.0.0         10.1.6.4         0.0.0.0         UG         40        0
 0 eth0
Continua a non funzionare.
Questa e' la configurazione che ho di apt:
 root@ferrero:~# cat /etc/apt/apt.conf
 APT 
 {
   // Options for apt-get
   Get 
   {
      Download-Only "false";
   };
 
 };
 // Options for the downloading routines
 Acquire
 {
   Retries "0";
   Proxy "
10.1.6.4:1080
";
 };
 // Things that effect the APT dselect method
 DSelect 
 {
   Clean "never";   // always|auto|prompt|never
 };
 DPkg 
 {
   // Probably don't want to use force-downgrade..
   Options {"--force-overwrite";}
 }
Nella riga proxy ho impostato come porta sia 1080 che 80.
Ho impostato la variabile d'ambiente http_proxy sia a 
10.1.6.4:80
 che  a
10.1.6.4:1080
 e mi sono riloggato dopo la modifica.
Continuano a non funzionare ne' apt, ne' i ping verso internet.
Qualche suggerimento?
Accidenti,   perche'   ho  l'impressione  che  stia  mancando  un  punto
semplice?
TIA
-- 
manuel 'fmf' ferrero
"Questa signature e' oscurata per protesta."
        -- io

 0.0.0.0         10.1.6.4        0.0.0.0         UG        40        0    0 eth0
Questo mi sembra corretto, in effetti prima c'era una riga di troppo.

Questo mi sembra corretto, in effetti prima c'era una riga di troppo.
Perfetto, come avevo immaginato.
La  prima  riga  dove  indirizza  i  pacchetti  diretti  alla  sottorete
10.1.0.0 con netmask 255.255.0.0?
La seconda riga dice che tutti i pacchetti che non  sono  gestiti  dalla
prima  riga,  quindi  tutti  quelli da e verso l'esterno, devono passare
tramite il gateway 10.1.6.4, giusto?
E dove viene detto che questi ultimi devono  passare  sulla  porta  1080
che e' l'unica aperta verso l'esterno? Forse e' questo che manca.


che e' l'unica aperta verso l'esterno? Forse e' questo che manca.
ALT! Ferma tutto.
Io avevo capito che il wingate facesse un full NAT, non avevo capito
che erano aperte *solo* quelle porte. Se e' cosi' e' normale che non
funzioni ping ne' nient'altro.
In questo caso puoi usare solo i proxy, ma devono essere quelli
corretti: http, ftp, ecc. non socks (1080) che devono essere attivi sul
wingate.

wingate.
Non mi ero spiegato bene evidentemente.
Il  pc ha wingate con aperte dal mio lato verso l'esterno la 80, la 21 e
la 1080.
In windows configuro il browser in modo che usi  il  proxy  e  passa  il
protocollo  http sulla 80, lo stesso per il client ftp sulla 21 e poi ho
usato  un  programmillo  che  si  chiama  winsocks   che   permette   di
socksificare  qualsiasi programma che non lo faccia nativamente: mozilla
ad esempio lo fa nativamente come detto, mentre hamster non lo  fa.  Per
poter  quindi  scaricare  i  ng  ho dovuto socksificare hamster. Ora per
hamster non sembra cambiato nulla, ma in realta' il protocollo  nntp  al
posto  di  passare  sulla 119 passa attraverso il socks sulla 1080 grzie
al programmillo citato.
Le cose nella rete di cui parlo sono cosi' e non si possono  mettere  in
discussione.  Mi  aspettavo  quindi  di  fare  la stessa cosa con linux.
Ora che ci ripenso come mi fai notare il ping non passa  per  forza:  il
wingate   non   fa   full   NAT,  ma  mi  aspettavo  che  impostando  in
.bash_profile la variabile
export http_proxy=10.1.6.4
almeno lynx mi permettesse di navigare.
Soprattutto dopo che mi hai fatto modificare la route verso il  gateway.
apt  passa  sul  protocollo  http,  quindi  come  da  man  usa la stessa
variabile d'ambiente $http_proxy.
L'equivalente in linux del  programmillo  che  socksifica  _forse_  l'ho
trovato  e  si  chiama  tsocks,  ma  per  installarlo  devo  prima poter
scaricare pacchetti dalla rete con apt[1].
Perche' dici "non socks (1080)" nella tua risposta precedente?
TIA
[1] in realta' l'ho scaricato come pacchetto deb da  windows  e  poi  ho
montato  la  partizione  windows  e  l'ho  installato  con  dpkg, ma una
configurazione alla veloce non  funzionava,  cosi'  l'effetto  e'  stato
solo  aumentare  la  mia  confusione  che  ha, tra l'altro, portato alla
castroneria sul ping... Ora l'ho disinstallato: primo punto sul  roadmap
e'  far andare un browser attraverso la porta 80. questo porta poi a far
andare apt acui  seguira'  tsocks.  Se  qualcuno  (tu?  :)  continua  ad
aiutarmi...


almeno lynx mi permettesse di navigare.
Questa impostazione del proxy dovrebbe funzionare. Fammi sapere.