Newsgroup: it.comp.reti.ip-admin
Titolo: WINGATE

devo installere un Proxy sul nostro server NT4 con linea ISDN. (5 clients
tutti win95)
Cosa ne pensate di WINGATE ?
Fatemi sapere i vostri commenti
Ciao e Grazie
Antonio Gerli
------------------------------------
Gerli Metalli S.p.a.
P.zza S. M. Beltrade, 1
20123 Milano Italy
Tel. +39 - 02.80.95.11
Fax +39 - 02.89.00.714
Email 
gerlim...@mail.mdsnet.it

Fatemi sapere i vostri commenti
L'ho usato per un po' di tempo con un accesso RTG ed ho avuto vari
problemi sui client:
1) Non tutti i Java funzionano
2) Non tutti i CGI (!) funzionano
3) Non (tutto) funziona.
Visti i risultati ho montato un 486 con Linux, firewall, masquerade
e squid e ho risolto, anche se ho perso un po' di velocità (ma lo
squid funziona alla grande).
Credo che con l'ISDN non avrei perso neanche un bit, ma il cliente
vuole RTG.
Il problema in questo caso era avere anche un gateway, oltre al proxy.
Saluti,
Valerio

 Il problema in questo caso era avere anche un gateway, oltre al proxy.
Wingate NON e' un proxy, e' solo un port forwarder, puo' fare solo il
port forwarding TCP (con il suo orrendo protocollo sulla porta 23 oppure
con il SOCKS sulla 1080) e quindi non e' nemmeno un gateway/NAT (non 
passera' mai UDP e comunque non e' "trasparente"). NAT/ipfwadm puo' 
essere configurato per fare da gateway trasparente e dovrebbe essere
sempre piu' veloce di un port forwarder, in pochi casi estremi un port
forwarder puo' essere piu' veloce del gateway e in questo caso puoi
mettere sempre su Linux un bel socks (di cui Wingate e' una brutta copia),
un proxy fa un lavoro diverso con dei *grossi* vantaggi di velocita'
nella maggioranza dei casi e un leggero svantaggio in alcuni casi...
son cose diverse che funzionano in modo strutturalmente diverso:
- gateway/NAT/ipfwadm: agisce a livello IP, prende un pacchetto IP bruto
  gli cambia i numeri di porta e di IP mittente/destinazione e lo inoltra,
  teoricamente puo' non sapere nemmeno a che protocollo appartengono e
  in linea di massima il client non e' tenuto a sapere che il gateway 
  esiste.
- Port Forwarder: attende una connessione su una certa porta della rete
  interna, quando uno si connette li apre una connessione su una porta
  di un IP esterno e mette in corto circuito le due connessioni, agisce
  *sopra* a TCP, rallenta le operazioni di apertura delle porte leggermente,
  funziona solo con TCP (ma qualsiasi cosa che sia su TCP puo' essere fatta
  funzionare), necessita che il "client" sappia che deve seguire un protocollo
  per connettersi (Io utente interno mi collego alla porta 1080 del socks,
  gli dico "connettimi a 
www.tin.it
 porta 80" e poi continuo il mio lavoro)
- Proxy agisce ancora piu' su a livello di protocollo: sopra al protocollo 
  http (o news o mail o DNS), sapendo "cosa" sta chiedendo il client ha una
  cache sua e cerca di dare i dati lui, se non puo' chiede al mondo esterno.
Li ho elencati in ordine di velocita' (salvo il caso in cui un proxy
abbia i dati in cache un gateway e' piu' veloce di un port forwarder
e un port forwarder e' piu' veloce di un proxy) ed in ordine crescente
di "raffinatezza" e livello OSI a cui agiscono (un gateway agisce sul 
livello piu' "bruto", funziona bene o male con tutto e non e' specifico
per nulla, un proxy serve solo per uno specifico protocollo applicativo,
come http per esempio).
Personalmente (salvo configurazioni particolari ed esigenze specifiche di
firewalling) un port forwarder a mio avviso non si giustifica MAI, sara'
sempre piu' lento di un proxy che ha i dati in cache e sempre piu' lento
e meno "compatibile" di un NAT in tutti gli altri casi.
Nelle mie reti di solito ho:
- NAT che fa passare "tutto" (salvo che qualcosa si scelga di non farlo 
  passare).
- Un proxy per le cose che piu' si usano (html->squid), se l'utente interno
  vuole si mette quello come proxy sulla configurazione della sua macchina,
  se non vuole non ci mette niente e puo' dimenticarsi che esiste (passa
  comunque dal NAT).
Ciao,
-- 
Andrea

e meno "compatibile" di un NAT in tutti gli altri casi.
Concordo al 100%.
<snip>
Ciao,
Valerio