SOCKS proxyserver finns att hämta ifrån
sunsite. Det finns även ett
exempel på en konfigurationsfil i den katalogen som heter
socks-conf. Packa upp filerna till en katalog på ditt system och
följ instruktionerna för hur man kompilerar det. Jag hade ett par problem när
jag gjorde detta. Se till att dina Makefile-filer är korrekta.
En viktig sak att notera är att proxyservern måste läggas till i
inetd.conf. Du skall lägga till en rad
socks stream tcp nowait nobody /usr/local/etc/sockd sockd
så att servern kan köras då den efterfrågas.
SOCKS-programmet använder två konfigurationsfiler. En som beskriver vilken access som tillåts, och en som routar förfrågningar till den korrekta proxyservern. Access-filen skall finnas på servern och routing-filen skall finnas på alla Un*x-maskiner. DOS och Macintosh datorer gör sin egen routing.
Med socks4.2 Beta så heter accessfilen sockd.conf. Den skall innehålla
två rader, en tillåt-rad och en neka-rad. Varje rad har tre element:
Identifieraren är antingen permit eller deny. Du skall ha en rad för varje.
IP-adressen är en fyrabytes adress i vanligt format (tex 192.168.2.0).
Adressmodifieraren är också en typisk IP-adress. Den fungerar som en nätmask. Tänk dig adressen som 32-bitars tal. Om en bit är en `1' så måste den motsvarande biten i adressen den kontrollerar vara samma som den i IP-adressen. Till exempel om raden ser ut så här
permit 192.168.2.23 255.255.255.255
så tillåter den endast den IP-adress där alla bitar är samma som i 192.168.2.23, dvs endast 192.168.2.23. Följande rad
permit 192.168.2.0 255.255.255.0
tillåter alla adresser i gruppen 192.168.2.0 till 192.168.2.255, dvs hela klass C domänen. Man skall inte ha följande rad
permit 192.168.2.0 0.0.0.0
eftersom den tillåter alla adresser, oavsett vilken det är.
Så, tillåt först alla adresser som du vill tillåta och neka sedan resten. För att tillåta alla i domänen 192.168.2.xxx fungerar följande rader bra.
permit 192.168.2.0 255.255.255.0
deny 0.0.0.0 0.0.0.0
Notera den första "0.0.0.0" i deny-raden. Med en modifierare som är 0.0.0.0 så spelar fältet med IP-adressen ingen roll. Men att ha endast nollor är normen eftersom det är enkelt att skriva.
Det är tillåtet med mer än en rad av varje.
Specifika användare kan också ges eller nekas access. Detta görs via ident autentisering. Alla system stöder inte ident, tex Trumpet Winsock, så jag tar inte upp detta här. Dokumentationen för SOCKS täcker detta ganska bra.
Routingfilen i SOCKS är dåligt namnsatt till socks.conf. Jag säger
"dåligt namnsatt" eftersom det är så likt namnet på accessfilen så
det kan vara lätt att blanda ihop dem.
Routingfilen finns för att tala om för SOCKS-klienterna när de skall använda SOCKS eller inte. Till exempel i vårat nätverk så behöver inte 192.168.2.3 använda SOCKS för att kommunicera med 192.168.2.1 (brandväggen). Den har en direkt anslutning via Ethernet. Den definierar loopback-enheten, 127.0.0.1, automatiskt. Naturligtvis så behövs inte SOCKS för att kommunicera med sig själv. Det finns tre nyckelord:
deny talar om när SOCKS skall neka en förfrågan. Här används samma tre
fält som i sockd.conf: identifierare, adress och modifierare. Generellt,
eftersom detta även kontrolleras av accessfilen sockd.conf, så sätts
fältet för modifieraren till 0.0.0.0. Om du vill göra så att du inte kan
kontakta någon dator, så kan du göra det här.
Raden med direct bestämmer vilka adresser man inte skall använda SOCKS
för. Detta är adresser vilka man kan nå utan att gå igenom proxyservern.
Återigen har vi de tre fälten identifierare, adress och modifierare. Vårt
exempel skulle ha
direct 192.168.2.0 255.255.255.0
vilket ger direkt kontakt med alla datorer på vårt skyddade nätverk.
Raden med sockd talar om vilken dator som har daemonen för SOCKS-servern
på sig. Syntaxen är
sockd @=<serverlist> <IP address> <modifier>
Notera `@='. Detta låter dig specificera IP-adresserna för en lista av proxyservrar. I vårt exempel så använder vi endast en proxyserver. Men man kan ha många, för att tillåta större belastning och för redundans i fall något går sönder.
Fälten för IP-adress och modifierare fungerar som för de andra exemplena. Du specificerar vilka adresser som går vart genom dessa.
Att sätta upp en DNS innanför en brandvägg är en ganska enkel uppgift. Du behöver bara sätta upp en DNS på brandväggen och sedan låta alla maskiner bakom brandväggen använda denna.
För att dina applikationer skall fungera med proxyservern så måste de vara
"sockifierade". Du behöver två olika telnetar, en för direkt
kommunikation och en för kommuntikation via proxyservern. Med SOCKS följer
instruktioner om hur man SOCKiferar ett program, såväl som ett par
för-SOCKifierade program. Om du använder den SOCKifireade versionen för en
direkt anslutning så kommer SOCKS automatiskt att byta till rätt version. På
grund av detta så vill vi ändra namn på alla programmen på vårt skyddade
nätverk och ersätta dem med de SOCKifierade versionerna. "Finger"
blir "finger.orig", "telnet" blir
"telnet.orig", osv. Du måste informera SOCKS om dessa via filen
include/socks.h.
Vissa program tar hand om routing och sockifiering själva. Netscape är ett av dessa. Du kan använda en proxyserver under Netscape genom att skriva in serverns adress (192.168.2.1 i vårt fall) i SOCKS-fältet under Proxies. Man måste iallafall pilla lite med alla applikationer oavsett hur de hanterar en proxyserver.
Trumpet Winsock har inbyggt stöd för proxyserver. I "setup" menyn, skriv in IP-adressen för proxyservern och alla adresser som kan nås direkt. Trumpet hanterar sedan alla utgående paket.
SOCKS-paketet fungerar endast med TCP-paket, inte UDP. Detta gör det lite mindre användbart. Många användbara program, som talk och Archie, använder UDP. Det finns ett paket som är designat för att användas som en proxyserver för UDP-paket som heter UDPrelay, av Tom Fitzgerald <fitz@wang.com>. Tyvärr så är det inte, när detta skrivs, kompatibelt med Linux.
Proxyservern är, framför allt, en säkerhetsenhet. Att använda det för att öka tillgången till Internet med ett begränsat antal IP-adresser har många nackdelar. En proxyserver medför bättre access till Internet från insidan av det skyddade nätverket, men det gör insidan helt oåtkomligt från utsidan. Detta betyder att inga servrar, talk eller archieanslutningar, eller direkt e-post fungerar till maskinerna i det skyddade nätverket. Dessa nackdelar kan verka obetydliga, men tänk på det på detta sättet:
FTP skapar ett annat problem med en proxyserver. När man ger kommandot ls,
så öppnar FTP-servern en socket på klientmaskinen och skickar informationen
genom den. En proxyserver tillåter inte detta, så FTP fungerar inte.
Dessutom är proxyservrar långsamma. På grund av den större overheaden så är nästan alla andra sätt att få accessen snabbare.
Så om du har IP-adresserna och inte bekymrar dig för säkerheten så skall du inte använda en brandvägg och/eller proxyserver. Om du inte har IP-adresserna och inte bekymrar dig för säkerheten så kan du kanske använda en IP-emulator som Term, Slirp eller TIA. Term finns på sunsite, Slirp finns på blitzen.canberra.edu.au och TIA finns på marketplace.com. Dessa paket är snabbare, tillåter bättre anslutningar och tillhandahåller bättre tillgänglighet till det privata nätverket från Internet. Proxyservrar är bra för de nätverk som har många datorer som vill ansluta till Internet `on the fly', med en inställning och lite arbete efter det.