- opplæringen
Hei, Khabrovites! Jeg tror mange nylig har støtt på problemer med å få tilgang til de nødvendige ressursene på grunn av forsøk fra Roscom of Shame of Supervision på å blokkere Telegram. Og jeg synes kommentarer er unødvendige her. Faktum er at disse ressursene ikke har skylden for noe, men de er blokkert. Det oppsto problemer med Viber, ReCaptcha, GoogleFonts, Youtube osv. (bortsett fra selve telegrammet). Dette skjedde i min organisasjon, og vi trenger noen uskyldige tjenester som luft. På et tidspunkt ble alt løst ved hjelp av proxy-servere, men de var ustabile eller slått helt av (de ble også blokkert av vår flotte og mektige RKN).
Etter å ha lest en haug med artikler, kom ideen opp om å lære Squid å kjøre individuelle URL-er gjennom Tor. Om du skal bruke denne metoden er opp til deg. Men jeg vil si at etter implementeringen forsvant alle problemene som var før. Hvem bryr seg, gå under katten.
Hvorfor er det sånn?
Artikkelen ble skrevet utelukkende med det formål å hjelpe de som ulovlig lider av det totale deliriet som skjer i landet vårt. Den er også rettet mot de som trenger en "gjennomsiktig" blekksprut med HTTPS uten sertifikatspoofing og muligheten til å spore besøk både over HTTP og HTTPS, siden artikkelen i hovedsak er en fortsettelse av artikkelen, siden jeg her foreslår en løsning for en lang -stående feil som ikke tillot å se domenenavn på https-ressurser i loggene og ikke tillot bruk av nyere versjoner av Squid. Vel, også bare for de som er interessert i å bruke Squid.
Hva er fordelene?
- Ubegrensede skaleringsmuligheter
- Relativ enkel støtte og administrasjon
- Hvis dette er viktig, kan du gi anonym tilgang til ressursene som er angitt i listen (selv om dette ikke er emnet for artikkelen, men anonymitet er gitt "gnister"
- Stabilitet. Når du bruker flere Tor-tjenester (ulike konfigurasjonsfiler), kan du koble dem til Squid og få round robin.
- Helt gratis. For alltid.
Jeg vet ingenting, Squid \ Tor er treg, jeg går og setter opp en VPS med en VPN over bakken
Gratulerer! Har du virkelig bestemt deg for at Roskomnadzor påførte deg ulemper, og du fortsatt må betale for det for å komme deg ut av situasjonen? OK. Du kan trygt hoppe over artikkelen og heve VPN-tunneler. Forresten, VPN er vellykket blokkert. Enkelt. Og i lys av de siste hendelsene vil jeg foreslå at snart ingen vil kunne bruke VPS for å omgå lovlig blokkering. Og på toppen av det kan VPS-en din også bli blokkert "bare fordi Telegram sitter ved siden av den." Tor vil ikke blokkere, på ingen måte. Hvis du konfigurerer det med obfs, så aldri og ingen steder (kanskje et emne for en egen artikkel, siden obfs ikke vurderes i denne artikkelen). Og hvor mange slike VPS vil trenge å heves med VPN? Hvordan servere den? Her er løsningen mye enklere, pålitelig og, om ønskelig, ganske rask, og også gratis. Så før du villeder andre lesere, må du vurdere alle + og - VPS med VPN på nytt, og først da hevde at Squid+Tor er en treg, upålitelig løsning.
Tor vil bli blokkert! I Kina, ut, allerede blokkert
Nei. Nei. Og nok en gang nei. I Kina fungerer Tor med obfs konfigurert. Fungerer utmerket. Det er ingen måte i verden å blokkere Tor. Selv Kina, med sine kapasiteter, sinn og økonomi, klarte ikke å gjøre dette.
Tor er treg! Og hvis du jobber gjennom obfs, så er det generelt skrekk!
Se dokumentasjonen og en haug med artikler på Internett, som beskriver hvordan du kan sørge for at hastigheten er på et anstendig nivå. Og igjen, etter å ha konfigurert flere kopier av Tor med forskjellige konfigurasjoner på denne måten, kan de festes til Squid og få round robin.
Så la oss starte med en liten teori. Som vi alle vet, er ikke Tor en HTTP-proxy, den kan ikke gjøres til en direkte peer for den underliggende Squid "men. Den gir SOCKS proxying (selvfølgelig, ikke bare, men det er det vi trenger). For at vi skal gifte oss Tor med blekksprut, du trenger noe som kan fungere som en kanal fra Tor til blekksprut og tilbake. Og selvfølgelig, mine damer og herrer, dette er Privoxy. Likevel er han i stand til å være en direkte likemann, og sende alt videre til Tor.
Det ble som sagt lest mange artikler, men ingen passet meg. Jeg kom over denne artikkelen, men den passet ikke helt for meg heller, siden jeg ikke trenger en støt. Generelt innebærer alle tilgjengelige artikler, nesten alle, enten en bump eller bare http, og i mitt tilfelle trenger du både HTTPS og spleis og åpenhet. Jeg så også denne og , men det er helt andre tilnærminger. Dens fordeler og ulemper. Jeg valgte selv en haug med Squid + Tor.
Jeg har allerede skrevet om hvordan man lager transparent Squid med HTTPS-proxy uten å endre sertifikater. Og selvfølgelig prøvde jeg å implementere ideen på den. Men skuffelsen ventet på meg. HTTP-forespørsler gikk perfekt til TOR, men HTTPS gjorde det ikke. Problemet er ikke så godt kjent, og jeg fikk vite av en av utviklerne at dette er en feil i eldre versjoner av Squid. Men under eksperimentene ble det funnet en løsning - Squid 3.5.27, der denne feilen er fikset + vakre domenenavn i loggene (https), i stedet for ip-adresser. Men også her ventet flere skuffelser på meg, som vil bli diskutert nedenfor. Men alt, som de sier, er ferdig med en fil.
Så, innledende data:
- Debian Stretch (9) x86 (prøvde ikke x64)
- Squid 3.5.23 sorterer fra depot
- Frisk blekksprut sorterer fra offsite
- OpenSSL
- Libecap3
- Privoxy
- Rette armer og mye kaffe og kaker
Så la oss gjøre oss klare til å bygge:
apt-get install fakeroot build-essensielle devscripts apt-get build-dep squid3 apt-get install libecap3 apt-get install libecap3-dev apt-get install libssl1.0-dev apt-get install libgnutls28-dev
VIKTIG!
Det er veldig viktig å installere nøyaktig libssl1.0-dev, og ikke en annen versjon, ellers vil Squid enten ligge etter eller ikke bygge i det hele tatt på grunn av uforståelige feil
apt-get source squid3
Last ned akkurat dette arkivet med Squid-kilder:
Wget -O squid-3.5.27-2018.tar.gz http://www.squid-cache.org/Versions/v3/3.5/squid-3.5.27-20180318-r1330042.tar.gz
Gå til Squid-kildekatalogen og oppdater kildene til de nylig nedlastede typene:
Cd squid3-3.5.23/ uupdate -v 3.5.27-2018 ../squid-3.5.27-2018.tar.gz
Gå til den nylig opprettede katalogen med oppdaterte kilder:
cd ../squid3-3.5.27-2018
Legg til kompileringsalternativer til debian/regler:
Enable-ssl \ --enable-ssl-crtd \ --with-openssl
Råd
Forresten, du kan slå av alternativene du ikke trenger, dette vil fremskynde kompileringen
Deretter må du lappe kildene med denne oppdateringen:
client_side_request.patch--- src/client_side_request.cc Thu Aug 18 00:36:42 2016 +++ src/client_side_request.cc Man Sep 19 04:41:45 2016 @@ -519.20 +519.10 @@ // note the note transaksjonsstatistikk. http->request->recordLookup(dns); - if (ia != NULL && ia->count > 0) ( - // Er NAT-destinasjons-IP-en i DNS? - for (int i = 0; i< ia->telle; ++i) ( - if (clientConn->local.matchIPAddr(ia->in_addrs[i]) == 0) ( - debugs(85, 3, HER<< "validate IP " << clientConn->lokale<< " possible from Host:");
- http->request->flags.hostVerified = sant; - http->doCallouts(); - komme tilbake; - ) - debugs(85, 3, HER<< "validate IP " << clientConn->lokale<< " non-match from Host: IP " << ia->in_addrs[i]); - ) - ) - debugs(85, 3, HER<< "FAIL: validate IP " << clientConn->lokale<< " possible from Host:");
- hostHeaderVerifyFailed("local IP", "any domain IP");
+ debugs(85, 3, HERE << "validate IP " << clientConn->lokale<< " possible from Host:");
+ http->request->flags.hostVerified = sant; + http->doCallouts(); + retur; ) tomrom
Hva er den til? Jeg skal forklare. Da jeg skrev den første artikkelen om kikk og spleis sa jeg at nyere versjoner ikke fungerer, og det var, og akkurat det samme, fikser denne patchen selve problemet med at Squid selektivt dropper HTTPS-forbindelser, med en interessant melding i cache.log :
SIKKERHETSVARSEL: Vertshodeforfalskning oppdaget på ... (lokal IP samsvarer ikke med noen domene-IP)
Faktum er at på en vert løses noe til en IP, noen ganger til en annen på en nabovert, og til en tredje på Squid selv. det er en DNS-cache og den oppdateres ikke synkront. Squid finner ikke treff for ip-domenet i cachen sin (fordi den oppdaterte cachen litt tidligere eller senere) og avslutter tilkoblingen. Det virker som beskyttelse, men i dag anses det som normalt (round-robin DNS). Utviklerne fikk rett. Og vi trenger det ikke i det hele tatt! Til de som sier at denne oppdateringen kan være en sikkerhetsrisiko, vil jeg svare at jeg rådførte meg med Yuri Voinov, som er direkte relatert til Squid-utviklingsteamet, om denne oppdateringen. Det er ingen trussel her!
Så vi opprettet en fil for oppdateringen, kastet koden, vi må lappe den:
Patch -p0 -i client_side_request.patch
Deretter må du avbryte applikasjonen av en oppdatering under kompilering (ellers vil du få en feilmelding om at denne oppdateringen ikke kan brukes, siden den allerede er brukt). La oss gå til debian/patcher/series og kommentere der 0003-SQUID-2018_1.patch ved å sette et skilt foran den #
:
dpkg-buildpackage -us -uc -nc
Installer squid-langpack
apt-get install squid-langpack
og installer ferske pakker
dpkg -i squid-common_3.5.27-2018-1_all.deb dpkg -i squid_3.5.27-2018-1_i386.deb
Hvis apt sverger til avhengigheter, gjør det
Systemctl deaktiver blekksprut
og opprette en systemd tjeneste i katalogen /etc/systemd/system(tjenestefilen ligger i kildene, og er fullstendig kopiert her)
Cat /etc/systemd/system/squid3.service ## Copyright (C) 1996-2018 The Squid Software Foundation og bidragsytere ## ## Squid-programvare distribueres under GPLv2+-lisens og inkluderer ## bidrag fra en rekke enkeltpersoner og organisasjoner. ## Vennligst se filene COPYING og CONTIBUTORS for detaljer. ## Description=Squid Web Proxy Server After=network.target Type=enkel ExecStart=/usr/sbin/squid -sYC -N ExecReload=/bin/kill -HUP $MAINPID KillMode=prosess WantedBy=multi-user.target
La oss slå den på
systemctl aktivere squid3.service
La oss installere tor, privoxy
apt-get install for privoxy
Jeg personlig rørte ikke Tor-konfigurasjonen i det hele tatt, men Privoxy-konfigurasjonen kan bringes til dette skjemaet:
Lytteadresse 127.0.0.1:8118 toggle 0 enable-remote-toggle 0 enable-remote-http-toggle 0 enable-edit-actions 0 forward-socks5t / 127.0.0.1:9050 . maks-klient-tilkoblinger 500
Nesten ferdig. La oss gå til katalogen /etc/squid, vi vil endre noe der. La oss lage en pem-fil som trengs for spleis:
Openssl req -new -newkey rsa:1024 -days 365 -nodes -x509 -keyout squidCA.pem -out squidCA.pem
Og la oss bringe squid.conf til følgende skjema:
Acl localnet src 192.168.0.0/24 # Din lokalitet acl SSL_ports port 443 acl Safe_ports port 80 # http acl Safe_ports port 21 # ftp acl Safe_ports port 443 # https acl Safe_ports port 70 # gopher_0 port a-cl port # gopher 0 port 1 65535 # uregistrerte porter acl Safe_ports port 280 # http-mgmt acl Safe_ports port 488 # gss-http acl Safe_ports port 591 # filmaker acl Safe_ports port 777 # multiling http acl CONNECT-metode CONNECT acl SSL-metode CONNECT Squidify-metode DANSK. Jeg anbefaler på det sterkeste å bruke samme DNS her og på klienter dns_nameservers 77.88.8.8 # Liste over domener som må tillates gjennom Tor acl rkn url_regex "/etc/squid/tor_url" http_access deny !Safe_ports http_access deny CONNECT !SSL_portshost http_access deny manager http_access tillat lokalnett http_access tillat localhost http_access nekte alle icp_access nekte alle htcp_access nekte alle #transparent port spesifiseres av intercept http_port 192.168.0.1:3128 alternativet intercept options=NO_SSLv3:NO_SSLv3:NO_SSLv2 trenger også spesifisere en ikke-transparent port , fordi hvis du vil spesifisere #proxy-adressen manuelt i nettleseren, og spesifisere en transparent port, vil du få en tilgangsfeil, så du må #spesifisere en ikke-transparent port i nettleseren, med mindre selvfølgelig et slikt ønske er , dessuten får loggene #feil om at den ikke-gjennomsiktige porten ikke er spesifisert =) http_port 192.168.0.1:3130 options= NO_SSLv3:NO_SSLv2 # og til slutt spesifiser HTTPS-porten med de nødvendige alternativene https_port 192.168.0.1:3129 intercept ssl-bump opt ions=ALL:NO_SSLv3:NO_SSLv2 connection-auth=off cert=/etc/squid/squidCA.pem sslproxy_cert_error tillat alle sslproxy_flags DONT_VERIFY_PEER #spesifiser en regel med en liste over blokkerte ressurser (i filen blokkerte domener som)acla.com. ssl::server_name "/etc/squid/blocked_https.txt" acl step1 at_step SslBump1 ssl_bump peek step1 #avslutt tilkoblingen hvis klienten får tilgang til en blokkert ressurs ssl_bump terminate blocked ssl_bump splice all # Aldri_ direkte tillat domener spesifiserte RK-listen rkn # Spesifiser en proxy , hvor domener skal sendes fra listen, i vårt tilfelle - Privoxy cache_peer 127.0.0.1 overordnet 8118 0 no-query no-digest default cache_peer_access 127.0.0.1 tillate rkn cache_peer_access all_0.lrdsprogram .0lrdsprogram /squid/ssl_crtd -s / var/lib/ssl_db -M 4MB coredump_dir /var/spool/squid refresh_pattern ^ftp: 1440 20% 10080 refresh_pattern ^gopher: 1440 0% 1440 refresh_/cbin? ) 0 0 % 0 refresh_pattern . 0 20 % 4320 logfile_rotate 4 pid_filename /var/run/squid.pid
url_regex-listen ser omtrent slik ut (listen er bare et eksempel!):
Zenway\.ru \.*google\.com \.*viber\.* \.amazon\.com \.fbcdn\.net \.slack\.* media\.api\.viber\.com* static\. viber\.com* secure\.viber.* \*.cloudfront\.net fonts\.gstatic\.com med-edu\.ru
Gjennomsiktig proxy- et kommunikasjonsskjema der trafikk, eller deler av den, blir omdirigert til en proxy-server implisitt (ved hjelp av en ruter). Samtidig kan klienten bruke alle fordelene til en proxy-server uten ekstra innstillinger for nettleseren (eller andre applikasjoner for å jobbe med Internett). Eksempel: rute -p legg til 10.32.5.5 maske 255.255.255.255 10.32.1.14
Klassifiseringen av proxy-servere for anonymiseringsformål er presentert i artikkelen Web proxyer.
Tekniske detaljer
Klientdatamaskinen har en innstilling (av et spesifikt program eller operativsystem), ifølge hvilken alle nettverkstilkoblinger over en bestemt protokoll gjøres ikke til IP-adressen til serveren (ressursen) hentet fra DNS-navnet til ressursen, eller direkte spesifisert, men til IP-adressen (og en annen port) til proxy-serveren.
Hvis det er nødvendig å få tilgang til en ressurs ved å bruke denne protokollen, åpner klientdatamaskinen en nettverkstilkobling til proxy-serveren (på den nødvendige porten) og gjør en normal forespørsel, som om den hadde tilgang til ressursen direkte.
Etter å ha gjenkjent forespørselsdataene, etter å ha kontrollert korrektheten og tillatelsene for klientdatamaskinen, åpner proxy-serveren, uten å bryte forbindelsen, selv en ny nettverksforbindelse direkte med ressursen og sender den samme forespørselen. Etter å ha mottatt dataene (eller feilmeldingen), sender proxy-serveren dem til klientdatamaskinen.
Dermed er proxy-serveren en fullverdig server og klient for hver støttet protokoll og har full kontroll over alle detaljene i implementeringen av denne protokollen, har muligheten til å bruke tilgangspolicyer satt av administratoren på hvert trinn av protokollen.
Proxy-servere er den mest populære måten å få tilgang til Internett fra de lokale nettverkene til bedrifter og organisasjoner. Følgende faktorer bidrar til dette:
- Hovedprotokollen som brukes på Internett er HTTP, standarden som beskriver støtte for arbeid gjennom en proxy;
- Proxy-støtte av de fleste nettlesere og operativsystemer;
- Tilgangskontroll og trafikkregnskap for brukere;
- Trafikkfiltrering (integrasjon av proxyer med antivirus);
- Proxy-server - kan fungere med minimale rettigheter på alle operativsystemer med nettverksstøtte (TCP / IP-stack);
- Mange applikasjoner som bruker sine egne spesialiserte protokoller kan bruke HTTP som en alternativ transport eller SOCKS proxy som en generisk proxy som passer for nesten alle protokoller;
- Mangel på Internett-tilgang ved bruk av andre (ikke-standard) protokoller kan øke sikkerheten på et bedriftsnettverk.
For tiden, til tross for den økende rollen til andre nettverksprotokoller, overgangen til å lade Internett-tjenester etter tilgangshastighet, samt fremveksten av billige maskinvarerutere med NAT-funksjonen, fortsetter proxy-servere å bli mye brukt i bedrifter, siden NAT ikke kan tilby en tilstrekkelig kontroll over bruken av Internett (brukeratentisering, innholdsfiltrering).
De vanligste proxy-serverne
- 3proxy (BSD, multiplattform)
- CoolProxy (proprietær, Windows)
- Eserv (shareware, Windows)
- HandyCache (shareware, Windows) er gratis for hjemmebruk
- Kerio Control (proprietær, Windows, Linux)
- Microsoft Forefront Threat Management Gateway, tidligere Microsoft ISA Server (proprietær, Windows)
- Blue Coat Proxy SG (maskinvare/virtuelt apparat)
- nginx (en webserver som har en driftsmodus som en omvendt proxy og brukes ofte til dette)
- Squid (GPL, multiplattform)
- Trafikkinspektør (proprietær, Windows)
- UserGate (proprietær, Windows)
- Internet Control Server (shareware, FreeBSD)
- Tor (BSD, multiplattform)
- Ideco ICS (proprietær, Linux)
- WinGate (proprietær, Windows)
- (med autorisasjon)
- Apache (webserver som har tilleggsmoduler for å implementere frem og tilbake proxy)
Proxifiers
En proxy er et program som omdirigerer andre programmer gjennom proxy-servere. Proxifiers brukes ofte for Internett-klienter som ikke støtter proxy-servere.
- Sammenligning av proxifiers (eng.)
- Proxy-programvare og skript i lenkekatalogen
Det tok meg nylig å sette en gjennomsiktig proxy-server på ett kontor. Internett-tilgang der er organisert gjennom ASUS WL-550g-ruteren, som det var en alternativ fastvare på.
For de som ikke er i faget vil jeg forklare at en transparent proxy skiller seg fra en vanlig primært ved at nettlesere på klientmaskiner ikke trenger å spesifisere proxy-serverinnstillinger eksplisitt. En gjennomsiktig proxy avskjærer ganske enkelt den innkommende HTTP-trafikken og tar deretter forskjellige handlinger med den. Samtidig får brukeren følelsen av at han jobber på Internett uten proxy-server.
Generelt, for å utføre denne oppgaven, installerte jeg Debian på en separat PC, og satte deretter Squid, Apache og Lightsquid der for å se statistikk. Etter det dukket spørsmålet opp om hvordan du pakker all trafikk på den 80. TCP-porten på proxy-serverdatamaskinen.
Det enkleste som kom til tankene var å registrere noe slikt på gatewayen:
iptables -t nat -A PREROUTING -s lokalt nettverk-p tcp -dport 80 -j DNAT -til-destinasjon proxy-server-ip:port
Det fungerte... All trafikken begynte egentlig å gå til proxy-serveren, men i statistikken Lightskweed viste det var en liten hendelse. Alle Internett-forespørsler sendt fra datamaskiner på nettverket vises nå i statistikk som forespørsler sendt direkte fra den lokale IP-adressen til ruteren. Hvorfor skjedde dette, fordi DNAT bare endrer destinasjonsadressen i IP-pakken? Alt er veldig enkelt. Den generelle regelen om at hele nettverket gikk på nett har ikke gått bort, og der hadde vi noe sånt som dette:
iptables -t nat -A POSTROUTING -s lokalt nettverk-j MASKERADE
Faktisk viste det seg at i PREROUTING-kjeden endret vi destinasjonsadressen, og så, i POSTROUTING-kjeden, endret også avsenderadressen.
Vi gjør det riktig!
Etter å ha rotet gjennom Internett, kom jeg over en dokkingstasjon som sier hvordan man omdirigerer til en gjennomsiktig proxy.
Så først blir det skrevet en regel som vil tillate all trafikk som kommer fra proxy-serveren til Internett uten endringer:
iptables -t mangle -A PREROUTING -j ACCEPT -p tcp -dport 80 -s proxy-server-ip
Vi merker trafikk som går til Internett fra andre datamaskiner på det lokale nettverket:
iptables -t mangle -A PREROUTING -j MARK -set-mark 3 -p tcp -dport 80
Deretter lager vi en ruteregel - vi legger all den merkede trafikken inn i en ny tabell 2:
ip-regel legg til fwmark 3 tabell 2
Etter det skriver vi ruten for tabell 2:
ip-rute legg til standard via proxy-server-ip dev router-lan-grensesnitt tabell 2
Etter disse trinnene vil all trafikk bli rutet til proxy-serveren på det tidspunktet rutingbeslutningen tas, dvs. før du når POSTROUTING-kjeden.
Men det er en liten nyanse her, all trafikk fra datamaskiner på det lokale nettverket vil komme til proxy-serveren på port 80, så Squid må konfigureres på port 80 eller OMDIREKTERE fra port 80 til noen 3128. Regel på proxy-serveren vil se noe slikt ut:
iptables -A PREROUTING -t nat -i eth0 -p tcp -dport 80 -j OMDIREKTERE -til-port 3128
Siden den 80. porten på proxy-serveren uansett vil være opptatt, uansett om vi henger Squid på den eller gjør en omdirigering, ikke glem å binde Apache til en annen port, fordi som standard henger den også på TCP 80.
En proxy-server er en veldig praktisk og ekstremt nyttig ting, som kan være mer enn noen gang nyttig i en rekke tilfeller. Proxy-servere kan være av forskjellige typer, en av de mest populære typene av slike servere er en gjennomsiktig proxy-server. En transparent proxy-server er en server som kan kobles til uten bruk av spesielle programmer og ekstra nettleserinnstillinger. Denne tilstanden kan oppnås med en spesiell brannmurinnstilling, som resulterer i omdirigering av all trafikk fra port 80 til porten som tilhører proxy-serveren.
Hva er en transparent proxy-server?
En transparent proxy-server er en server som kan kobles til uten bruk av spesielle programmer og ekstra nettleserinnstillinger. Denne tilstanden kan oppnås med en spesiell brannmurinnstilling, som resulterer i omdirigering av all trafikk fra port 80 til porten som tilhører proxy-serveren.
Denne innstillingen har en rekke funksjoner og interessante effekter, hvorav den ene er at brukere av et slikt system ikke en gang vil vite at de får tilgang til et bestemt nettsted via en proxy-server, siden denne innstillingen lar deg helt bli kvitt behovet for manuell konfigurasjon av nettklienter, noe som er veldig praktisk og praktisk. Det er denne effekten som i stor grad bestemmer populariteten som en transparent proxy-server har i vår tid.
Hvordan få transparent proxying til å fungere?
For at transparent proxying skal fungere riktig, må ruteren konfigureres riktig. Som du vet bruker de fleste moderne datanettverk en ruter for å koble til det lokale nettverket og Internett. Essensen av å konfigurere ruteren i dette tilfellet er å omdirigere all trafikk på port 80 til den squid transparent proxy-serveren. Det er tilfeller, spesielt for små nettverk, når du kan kjøre en proxy-server selv på en ruter, noe som er veldig praktisk.
Når du setter opp en gjennomsiktig proxy-server, kan du også trenge mange brannmur-IP-tabeller, noe som kan være veldig nyttig i tilfelle problemer med å omdirigere trafikk.
Hva er en transparent proxy for?
Som nevnt ovenfor har en gjennomsiktig proxy-server sine egne fordeler, som gjør den så ofte brukt. Hovedfordelen med denne typen proxying er at klienten som skal bruke en transparent proxy-server ikke trenger å konfigurere noe, noe som er veldig praktisk og behagelig for klienten selv. Alt som må gjøres er å organisere trafikkomdirigering på ruteren riktig, noe nettverksadministratoren må gjøre, hvoretter alle deltakere i dette nettverket vil kunne nyte alle fordelene som en proxy-server har. Når det gjelder fordelene med proxy-servere og deres muligheter, kan følgende skilles:
- Anonymitet. En proxy-server lar deg skjule din egen IP-adresse når du besøker et bestemt nettsted, noe som er veldig praktisk hvis du er utestengt på et nettsted, eller du ikke vil vise din tilstedeværelse av en annen grunn.
- Datakomprimering. Før du overfører informasjon til sluttbrukeren, komprimerer proxy-serveren den, noe som lar deg spare nettverkstrafikk ganske bra.
- Tilgangsbegrensning. Proxy-serveren tilbyr også svært gode alternativer for å begrense tilgangen, for eksempel lar den deg nekte tilgang til enkelte nettsteder, eller begrense trafikk til spesifikke brukere om nødvendig.
Som du kan se, har proxyer, og spesielt transparente proxyer, en rekke fordeler og styrker, så hvis du vil bruke dem også, kan squids transparente proxy være et veldig godt valg for deg.
En gjennomsiktig proxy-server, også kjent som en avskjærende proxy eller en tvungen proxy, er en server som fanger opp utgående informasjon på nettverket før den når Internett, uten noen konfigurasjon på klientdatamaskinen. I motsetning til eksplisitte proxyer, som krever programvarebasert konfigurasjon, krever transparente proxyer kun en serversidekonfigurasjon, noe som betyr at de kan brukes på et nettverk uten at sluttbrukeren vet om det. Disse serverne brukes ofte til å optimalisere belastningsbalansen eller filtrere innhold. Mange skoler og arbeidsplasser bruker denne proxy-serveren.
Som en eksplisitt proxy kan en transparent proxy forbedre nettverksytelsen gjennom en prosess kjent som caching. Data lagres lokalt ved den første forespørselen, slik at påfølgende forespørsler kan behandles mye raskere. På et nettverk som bruker en gjennomsiktig proxy, går alle forespørsler fra klientdatamaskiner gjennom en enkelt vert, slik at verten kan lagre oftest forespurte data lokalt, og spare behovet for å overføre data over Internett. Når et stort antall nettforespørsler gjøres – for eksempel på mange skole- eller bedriftsnettverk – kan bufring spare mye tid og båndbredde.
En gjennomsiktig proxy kan også brukes til å filtrere eller blokkere bestemt nettinnhold fra å få tilgang til nettverket. Nettverksadministratoren kan sette opp en liste over nettsteder som proxy-serveren vil filtrere før sluttbrukere får tilgang til dem. For eksempel kan en arbeidsgiver ønske å hindre ansatte fra å se sportsnettsteder mens de er på jobb. Med en riktig konfigurert gjennomsiktig proxy vil et forsøk på å sjekke gårsdagens sportsresultater resultere i en sidefeil for den ansatte, noe som hindrer ham eller henne i å bruke timer på en ikke-arbeidsrelatert nettside. Selv om denne filtreringsmetoden ofte vil være tilstrekkelig til å forhindre at brukere ved et uhell får tilgang til upassende innhold, kan avanserte brukere finne måter å omgå filtreringsprosessen på grunn av begrensninger i denne teknologien.
Gjennomsiktige proxy-servere er nyttige for mange pedagogiske og kommersielle datanettverk. En gjennomsiktig proxy-server krever ikke konfigurasjon på hver klientdatamaskin, så nettverksadministratorer bruker dem ofte som en tidsbesparelse for individuelle systeminnstillinger. Selv om en gjennomsiktig proxy gir de samme bufrings- og filtreringsfordelene som de fleste eksplisitte proxyer, tilbyr den ingen maskeringsfunksjoner for Internett-protokoll (IP). Derfor er en gjennomsiktig proxy ikke egnet for mange nettsikkerhetsformål som ofte er forbundet med nettfullmakter.
