Ein privat videresendande proxy treng ikkje fysisk å sitja mellom laptopen og rutaren. Han kan vera ein annan maskin på same LAN, med eitt netverksgrensesnitt.

Laptopen koplar til adressa til proxyen og den lyttande porten. Proxyprosessen opnar ei eiga tilkopling mot nettstaden eller forelderen hans. Same grensesnittet kan bera båe samtalane, medan rutetabellen til verten vel neste hopp.

client → proxy listener
proxy → existing router → destination

Det er nok for ein applikasjon som uttrykkeleg har valt proxyen. På Linux krev denne vanlege ordninga ikkje at IP-videresending blir slått på berre for å senda førespurnadene til applikasjonen vidare.

Standardgatewayen svarar på eit anna spørsmål

Standardgatewayen til ein klient handterer pakkane klienten sender mot andre nettverk. Å endra den innstillinga får ikkje nettlesaren til å senda HTTP-proxyførespurnader eller SOCKS-forhandlingar. Like lite ruter det å skriva inn ein proxy i nettlesaren alle andre applikasjonar gjennom den maskina.

Ein vert kan gjera båe jobbane, men har då to konfigurasjonar å styra: proxitenesta og ruting- eller brannmurfunksjonen. Fleire grensesnitt kan gjera nettverksdeling enklare. Det er eit topologival, ikkje ein føresetnad som eksplisitt HTTP-proxying legg på.

Denne skilnaden forklarer også eit vanleg mislukka eksperiment: å redigera videresendingsreglane til ein proxyserver har inga verknad på ei direkte klienttilkopling som går gjennom ein annan rutar. Pakkane kryssa aldri den serveren.

Viss kravet er obligatorisk bruk, må du fastslå kvar alternativ utgåande trafikk kan kontrollerast. Ein eksplisitt proxy med eitt grensesnitt kan vera ei gyldig teneste, medan ein eigen gateway handhevar nettverkspolitikken. Plasser handhevinga der pakkane faktisk passerer.

Relaterte artiklar