Proxy se používá např. na rozhraní dvou sítí, jejichž uzly nemají mezi sebou přímou konektivitu. Proxy se pak používá jako oddělovač obou sítí.
Originálním serverem rozumíme server, ze kterého chce klient získávat data. Originální server zpravidla leží v Internetu.
Klasická představa proxy je počítač s dvěma síťovými interfejsy. Jeden pro klientskou část proxy a druhý pro serverovskou část proxy. Jelikož proxy pracuje na aplikační úrovni, tak je jí vcelku jedno, kolik má počítač interfejsů. Často se v praxi provozují proxy na počítačích s jedním interfejsem.
Vraťme se však ke spojení dvou počítačů bez použití proxy.
V tomto případě klient komunikuje přímo s originálním serverem. Na úrovni protokolu TCP mezi sebou oba počítače navážou spojení. Klient aplikačním protokolem vydá požadavek na server. Server na tento požadavek odpovídá.
Uveďme si příklad z aplikačního protokolu HTTP. Předpokládejme, že klient chce získat ze serveru se jménem server soubor /cesta/soubor, klient tedy vydá protokolem HTTP příkaz:
GET /cesta/soubor
Server mu jako odpověď pošle buď požadovaný soubor nebo chybové hlášení. Všimněte si, že klient ve svém aplikačním požadavku nespecifikoval jméno ani IP-adresu serveru, ze kterého chce soubor získat - specifikoval jen požadovaný soubor. IP adresa zadaná uživatelem nebo získaná po překladu zadaného jména se používá na IP vrstvě tj. v záhlaví IP-datagramu. Aplikační vrstvu IP-adresa nemusí zajímat. (Neuvažujeme nyní pochopitelně případ virtuálních WWW-serverů, kdy na jednom serveru je virtuálně více serverů, které se liší svým jménem, kterému může odpovídat i jiná IP-adresa. Za příkazem GET musí následovat v protokolu HTTP verze 1.1 a vyšším ještě specifikace Host:).
V případě proxy originální klient nenavazuje spojení přímo s originálním serverem, ale se serverovou částí proxy. Klientská část proxy pak navazuje spojení s originálním serverem jménem originálního klienta.
Serverová část
proxy předává požadavky klientské části proxy a opačně. Při předávání požadavků
mezi oběma částmi proxy nemusí dojít pouze k mechanickému předávání, ale
předávání může být propracovanější. Zajímavé jsou zejména dvě následující
vlastnosti:
Takže proxy může např. pro protokol HTTP určovat, které počítače
mohou používat metodu GET a na jaká URL. Jiné počítače zase mají povolenu
metodu PUT či POST. Obdobně u protokolu FTP je možné povolit příkaz GET,
ale zakázat příkaz PUT, aby zaměstnanci vnitřní sítě nemohli zcizit data.
Vraťme se nyní k našemu příkladu protokolu HTTP. V případě použití proxy originální klient chce zaslat požadavek na WWW-server, ale server je až za proxy, takže originální klient nemusí umět ani přeložit jméno serveru na IP-adresu. Originální klient je rád, že mu DNS přeloží jméno počítače na kterém běží proxy na IP-adresu. Klient pak předává celý požadavek jako řetězec, tj. celé URI (chcete-li tak URL) předá jako řetězec a nezkoumá co je jméno serveru, co je cesta atd. Proxy pak tento požadavek zpracuje, tj. přeloží jméno serveru na IP-adresu, naváže s ním spojení a vydá příslušný příkaz GET.
Problém v Intranetu je tedy také s DNS (neuvažujeme-li případ, že se používá lokální překlad pomocí souboru /etc/hosts). Intranet může používat samostatné DNS nezávislé na Internetu. V takovém případě (jak jsem uvedl) ani nemůže klient přeložit jméno serveru z Internetu na IP-adresu. To provádí až proxy. Následující obrázek má očíslovány postupně jednotlivé akce nutné pro to, aby klient získal příslušné informace ze serveru:
Aby situace nebyla tak jednoduchá, tak je možné stavět proxy do kaskády,jak je znázorněno na následujícím obrázku:
Proxy on proxy umožňuje velkým podnikům si v Intranetu vytvořit zvláště chráněnou síť, kde např. centralizuje svá data. Vytvoří se uvnitř vnitřní podnikové sítě jakýsi Intranet se zvlášť bezpečným režimem. Některé firmy používají dokonce firewally pro oddělení takovýchto důležitých sítí (firewall on firewall).
Záměrně jsem použil v našich příkladech protokol HTTP. Protokol HTTP je totiž už postaven tak, aby podporoval proxy. Tj. ví-li klient, že přistupuje skrze proxy, pak v příkazech posílá celé URI (chcete-li tak URL). Proxy, která navazuje spojení s originálním serverem pak z URI vybere jméno počítače a naváže spojení s tímto počítačem a předá mu "zbytek URI". O protokolu HTTP říkáme, že přímo podporuje proxy.
Jenže co staré protokoly, které takové nejsou? Ty jsou dvojího druhu:
S klasickou proxy se nejspíše setkáte pro protokol FTP nebo TELNET. Představte si, že sedíte u klasického klienta pro TELNET. Proxy je spuštěna na počítači proxy.firma.cz a její serverovská část očekává požadavky od klientů na portu např. 1500. Tj. na příkazový řádek zadáte:
telnet
telnet> open proxy.firma.cz 1500
Proxy Vám odpoví:
*** Vitame Vas na proxy.firma.cz ***
Jenže co teď? Potřebujete nějak sdělit vaší proxy, jméno vzdáleného počítače, se kterým má její klientská část vašim jménem navázat spojení. A protokol TELNET žádný takový příkaz nemá. Jenže u TELNETu (i u FTP) se to dá udělat jednoduše - serverovská část proxy jako server rozšíří množinu příkazů o příkaz:
c server
Uživatel pak pracuje tak, že se nejprve programem telnet připojí na proxy, kde zadá příkaz c, v kterém specifikuje název nebo IP-adresu originálního serveru. Klientská část proxy naváže spojení s originálním serverem a začne předávat mezi klientem a originálním serverem data. Poté se klientu spojení již jeví jakoby mezi ním a originálním serverem žádná proxy nebyla.
Následující tabulka vyjadřuje IP-adresy a porty, které jsou použity
v našem příkladu pro klasickou proxy:
| Směr | IP-adresa odesilatele | Port odesilatele | IP-adresa příjemce | Port příjemce | Proxy | IP-adresa odesilatele | Port odesilatele | IP-adresa příjemce | Port příjemce | |||||
| ven | klient | >1023 | proxy.firma.cz | 1500 | --> | proxy.firma.cz | >1023 | server | 23 | |||||
| dovnitř | proxy.fima.cz | 1500 | klient | >1023 | <-- | server | 23 | proxy.firma.cz | >1023 |
Co by se stalo, kdybyste nezadali v příkazu telnet port 1500? Použil by se pro protokol TELNET standardní port 23. V takovém případě by se na počítači proxy.firma.cz aktivoval přímo server pro protokol TELNET, tj. po přihlášení se byste mohli pracovat jako interaktivní uživatelé počítače proxy.firma.cz. V praxi je však podstatně méně takovýchto interaktivní přístupů přímo na počítač proxy.firma.cz, proto si často správci proxy spustí proces telnetd na jiném portu a proxy na portu 23, aby uživatelům zjednodušili práci.
Jedním z řešení je generická proxy. Generická proxy je obecný program, který může správce konfigurovat a spouštět podle potřeby.
Serverovská část generické proxy je spuštěna (očekává požadavky od klientů vnitřní sítě) na konkrétním portu. Klientská část generické proxy je pevně nastavena na jeden originální server. Chceme-li umožnit klientům vnitřní sítě přístup na více serverů, pak musíme spustit generickou proxy pro každý server zvlášť. Každá spuštěná proxy pak očekává požadavky na jiném portu.
Jinými slovy. Co server, to jedna spuštěná proxy na příslušném portu.
Jako příklad si
zvolme generickou proxy pro telnet (pro telnet se zpravidla používá klasická
proxy, ale pro ilustraci je to docela dobrý příklad).
Na obrázku je znázorněno, že chce-li klient komunikovat se Serverem 1, pak musí kontaktovat proxy na portu 1551, chce-li komunikovat se serverem 2, pak musí skrze port 1552. Obdobně Server 3 je dostupný přes port 1553 (čísla portů byla zvolena náhodně).
Generická proxy nepotřebuje žádnou úpravu na straně klienta ani serveru. Školním případem generické proxy je situace, kdy mezi Internetem a Intranetem máme filtr. Běžným klientům zajistíme přístup do Internetu, ale bráníme klientům z Internetu v přístupu do naší sítě. To ovšem lze těžko udělat pro mail - tam je komunikace obousměrná. Proto mailový server umístíme do Internetu těsně před filtr. Naši klienti si budou chodit pro poštu protokolem POP3 na tento server. Jenže jak to udělat, když běžní klienti POP3 neumí pracovat s klasickou proxy? Řešení je nasnadě - použijeme generickou proxy, která očekává požadavky na portu 110 a opět na portu 110 kontaktuje náš (jeden) poštovní server.
Generické proxy
se často používají pro firemní aplikace. Tady se může stát, že proxy pracuje
opačně z Internetu do Intranetu, ale ne obecně - jen mezi dvěma počítači.
Chce-li firma vystavovat své služby na Internetu a data má ve vnitřní síti, pak nemůže nasměrovat proxy z Internetu do Intranetu a postavit svůj WWW-server do vnitřní sítě. Nemůže to udělat z bezpečnostních důvodů, ale ani pro zákazníka to není přijatelné. Zákazník by při použití protokolu HTTP musel pokaždé při přístupu skrze takové proxy překonfigurovávat svého klienta ... .
WWW-server musí být tedy umístěn v Internetu. Jenže jestliže naše aplikace vyžaduje data uložená v databázi ve vnitřní síti, tak jak se na ně dostat. Řešením je napsat si aplikaci, která bude volána WWW-serverem a bude se dotazovat do vnitřní sítě. Tuto komunikaci je možné omezit filtrem na dva počítače a případně doplnit o proxy na nějakých exotických portech (jak je uvedeno na obrázku). Dále si oba konce mohou prokazovat svou totožnost a případně i šifrovat data.
Mezi přístupovým routerem a proxy vznikne LAN, na které je WWW-server a aplikace komunikující dovnitř (naše proxy). Tato LAN je do Internetu připojena přes přístupový router. Na přístupovém routeru nakonfigurujeme filtr, aby nebylo možné zneužít portů pro aplikaci komunikující dovnitř uživateli z Internetu.
Je zajímavé, že se v parametrech při spouštění generické proxy zadávají pouze parametry klientské části proxy. Čili ty informace, které se u klasické proxy zadávají v úvodním dialogu při navazování spojení, tj. jméno a port originálního serveru. Generická proxy předpokládá, že takový dialog není možný, proto jsou tyto parametry nastaveny "na tvrdo" a generická proxy je tak vždy nasměrována na jeden konkrétní počítač.
Zůstaneme-li v UNIXu, tak kde se zadávají parametry serverovské části? Generická proxy je program, který pravděpodobně budeme spouštět pomocí super serveru inetd. Čili pro naší novou proxy si zvolíme nějaký port na kterém bude proxy po spuštění očekávat požadavky klientu. Např. port 1500. Zaneseme jej do souboru /etc/services:
.... novaproxy 1500/tcp nova proxy # Nase nova proxy ....Nyní musíme řící super serveru inetd, že v případě požadavku na port 1500 má startovat program /bin/nova_proxy, který jsme právě vytvořili. To se provede přidáním řádku do souboru /etc/inetd.conf:
.... novaproxy stream tcp nowait /bin/nova_proxy nova_proxy server port log .....Předpokládáme, že jsme naprogramovali generickou proxy, která jako první parametr čte jméno (nebo IP-adresu) originálního serveru, jako druhý parametr port, na kterém kontaktuje originální server. Jako poslední parametr se zpravidla udává identifikace pro SYSLOG, abychom v logu poznali, které hlášky jsou od naší nové proxy (nezapomeňte, že v souboru /etc/inetd.conf můžete zadat programu maximálně 4 parametry).
Nyní stačí restartovat super server inetd.conf (např. mu pošleme signál HUP) a příkazem netstat -a můžeme zjistit, jestli jsou na portu 1500 (novaproxy) očekávany požadavky klientů:
netstat -a Proto Recv-Q Send-Q Local Address Foreign Address (state) ..... tcp 0 0 *.novaproxy *.* LISTEN ....Z vnitřní sítě pak můžeme programem telnet otestovat, jestli se nám skrze generickou proxy ozve originální server:
$ telnet
telnet> open proxy.firma.cz 1500
*** Vita Vas server ten a ten ***
Prostě objeví se nějaká reakce originálního serveru - např. odmítnutí spojení (takovéto vítání je nepravděpodobné).
O transparentních proxy pojednává RFC-1919.
Transparentní proxy funguje jako router. Základní předpoklady pro práci transparentní proxy jsou:
S transparentní proxy nemusí vést klient žádný dialog. Transparentní proxy získá IP-adresu a port originálního serveru z IP-datagramu, který obdržela její serverovská část od klienta. Pochopitelně, že transparentní proxy může mít volitelně tabulku, kde je uvedeno od koho může kam akceptovat spojení. Dále může mít tabulku uvádějící transformaci IP-adres či portů mezi tím co obdrží od klienta a IP-adresou či portem na který bude skutečně její klientská část navazovat spojení.
Transparentní proxy se nejčastěji používají (u menších firem) pro protokoly TELNET, FTP a pro komunikaci klienta se serverem protokoly NNTP, IMAP, POP a POP3. Pro protokol HTTP není transparentní proxy zajímavá, protože ten umí pracovat sám s klasickou proxy, takže uživatel si jednou nakonfiguruje HTTP-klienta přes tuto proxy a dále se o proxy nemusí starat. U klasické proxy jsme si uvedli tabulku IP-adres a portů pro protokol telnet. V případě transparentní proxy klient použije v IP-datagramu přímo adresu originálního serveru a port 23 (TELNET). Tabulka má pak tvar:
| Směr | IP-adresa odesilatele | Port odesilatele | IP-adresa příjemce | Port příjemce | Proxy | IP-adresa odesilatele | Port odesilatele | IP-adresa příjemce | Port příjemce | |||||
| ven | klient | >1023 | server | 23 | --> | proxy.firma.cz | >1023 | server | 23 | |||||
| dovnitř | server | 23 | klient | >1023 | <-- | server | 23 | proxy.firma.cz | >1023 |
Zamyslíte-li se nad předchozí tabulkou, pak se vlastně transparentní proxy chová z hlediska klienta jako router s filtrem a z hlediska originálního serveru jako klasická proxy.
Rozdíly mezi klasickou a transparentní proxy:
| Problém | Klasická proxy | Transparentní proxy |
| IP adresace. | Všechny sítě musí umět adresovat proxy.firma.cz | Klient musí umět adresovat originální server. |
| DNS | Je možná úplná izolace Intranetu a Internetu. | V Intranetu musí být přeložitelné jména z Internetu. Opačně to není třeba. |
| Routing | Routing v Intranetu a Internetu může být nezávislý, ale v obou sítích musí být dostupná proxy.firma.cz. | Adresa originálního serveru musí být routovatelná už od klienta vnitřní sítě. |
| Skrytí IP-adres | IP-adresy Internetu jsou skryty před adresami Intranetu a naopak IP-adresy Intranetu jsou skryty před Internetem. | IP-adresy Intranetu jsou skryty před Internetem opačně tomu tak není. |
| Software pro proxy | Běžný software, který je přenositelný na úrovni zdrojových textů programu. | Speciální software s jehož přenositelností na jiné platformy jsou potíže - nutné úpravy do zdrojových textů. |
| Uživatelský software | Musí být konfigurovatelný, aby se dalo zadat jméno a port proxy. Dále musí umět vést počáteční dialog s proxy. | Stačí běžný software. |
| Znalosti uživatele | Musí si osvojit počáteční dialog s proxy. | Žádné další znalosti nejsou třeba. |
Např. pro sítě na bázi Novell Netware používající protokol IPX/SPX existují produkty nazývané IP-access. Jsou realizovány většinou jako NLM-moduly pro servery Novell Netware nebo jako služby pro Windows NT. Jedná se o to, že v takovýchto vnitřních sítích se často nepoužívá protokol TCP/IP ale právě IPX/SPX. IP-access umožňuje na straně klienta balit např. aplikační protokol HTTP nikoliv do TCP-paketů, ale do SPX-paketů. Mezi Internet a Intranet se umístí proxy, která na aplikační úrovni pracuje v protokolu HTTP, ale směrem do Intranetu balí/rozbaluje data do paketu SPX a směrem do Internetu do paketů TCP. Jelikož na aplikační úrovni pracuje na obě strany s protokolem HTTP, tak se nejedná o gateway, ale o proxy.
IP-access je zvláštní případ proxy, která pracuje s různými transportními protokoly.
Gateway na rozdíl od proxy provádí konverzi mezi dvěma aplikačními protokoly. Gateway může nebo nemusí pracovat s různými transportními protokoly. Na obrázku je gateway mezi protokoly HTTP a FTP, která na obě strany používá transportní protokol protokol TCP.
Protokol HTTP přímo podporuje gateway, proto v uvedené metodě GET je možné použít v URI název protokolu. Uvedli-li bychom na tomto místě (metoda GET) jako název protokolu protokol HTTP, pak bychom kontaktovali proxy.
Je vidět, že proxy a gateway má mnoho společného. Gateway musí na rozdíl (navíc) od proxy umět provádět konverzi mezi aplikačními protokoly. Na obrázku není vyznačen opačný směr, tj. ze serveru skrze gateway zpět ke klientovi. Avšak uživatelsky příjemná gateway musí rozlišit, zda-li klient specifikoval např. v uvedené metodě GET (protokolu HTTP) adresář nebo soubor. V případě, že specifikoval adresář, pak musí protokolem FTP provést výpis adresáře (příkaz dir) a tento výpis naformátovat v jazyce HTML tak, aby byl pro uživatele přehledný atd. V případě, že specifikoval soubor, pak příkazem get (protokol FTP) vypíše soubor a doplní jej o záhlaví HTTP, aby tato data mohla být přenášena HTTP protokolem.
Kromě často používané
gateway mezi protokoly HTTP a FTP se v praxi setkáváme s gateway mezi SMTP
a X.400, mezi SMTP a MS Mailem atp. Protokoly SMTP X.400, MS Mail, CC Mail
atd. jsou aplikační protokoly pro přenos elektronické pošty, ale každý
z nich používá jiný formát zpráv, některé jsou založeny na odlišném principu
přenosu dat (architektura klient/server nebo sdílení disků pro poštovní
úřad). Takováto poštovní gateway umožňuje posílat poštu mezi uživateli
různých sítí - např. mezi uživateli Internetu a datových sítí X.25, mezi
uživateli Internetu a uživateli LAN na bázi MS Windows atd.
Poštovní gateway bude pravděpodobně na transportní vrstvě používat směrem do Internetu protokol TCP, směrem do sítě X.25 některý z protokolů TP (OSI) a směrem k MS poštovnímu úřadu např. protokol Microsoft NetBEUI.
Dalším příklad gatewaye je gateway mezi protokolem FTP (Internet) a protokolem FTAM (OSI) pro přenos souborů. Oba protokoly slouží k témuž účelu - přenosu souborů, ale každý v jiném typy sítě. I když oba protokoly používají jiné příkazy pro přenos souborů, tak lze vytvořit převodní tabulku a vtělit ji do programu - vznikne tak gateway FTP/FTAM. Podobně existují gatewaye mezi protokolem TELNET (Internet) a protokolem Virtuální Terminál (OSI) pro síťový terminál (Pozor protokol Virtuální Terminál v OSI je jiný protokol než protokol Virtuální Terminál v TCP/IP!).
Gateway mail/FTP vznikla v dobách, kdy mnoho uživatelů nemělo plný přístup do Internetu - měli přístup pouze pro elektronickou poštu. Gateway mail/FTP pracuje tak, že uživatel posílá maily zvláštnímu adresátovi, který není člověk, ale program - gateway. V mailech se píší příkazy FTP jak je normálně znáte. Gateway vám pak poštou vrací co jí pomocí těchto příkazů bylo vráceno. Obdobně pracuje gateway mail/HTTP
Jiná gateway je news/mail. Jsou dva druhy konferencí. Konference typu listserv (tj. konference založená na elektronické poště) a konference typu news. Gateway news/mail umožňuje přístup přes listserv do konference news nebo naopak vkládá maily do konference news.
Gatewaye mail/news, mail/FTP, mail/HTTP a vůbec všechny mailové gatewaye jsou ve své podstatě programy, které požadavky zpracovávají dávkově. Tj. příchozí požadavky s ukládají do fronty a gateway je postupně zpracovává.