Unu retkarto sufiĉas por eksplicita prokurilo
Komprenu kiam antaŭa prokurilo povas dividi la LAN sen fariĝi la defaĵa enirejo de la klientoj.
Privata antaŭa prokurilo ne devas fizike sidi inter la tekkomputilo kaj la enkursigilo. Ĝi povas esti alia maŝino en la sama LAN, uzante unu retinterfacon.
La tekkomputilo konektiĝas al la adreso de la prokurilo kaj al la aŭskulta pordo. La prokurila procezo malfermas apartan konekton al la retejo aŭ al ĝia patro. La sama interfaco povas porti ambaŭ konversaciojn, dum la enkursiga tabelo de la gastiganto elektas la sekvan salton.
client → proxy listener
proxy → existing router → destinationTio sufiĉas por aplikaĵo, kiu eksplicite elektis la prokurilon. En Linukso, ĉi tiu ordinara aranĝo ne postulas ŝalti IP-plusendadon nur por plusendi la petojn de la aplikaĵo.
La defaĵa enirejo respondas al alia demando
La defaĵa enirejo de kliento traktas la pakaĵojn, kiujn la kliento sendas al aliaj retoj. Ŝanĝi tiun agordon ne igas la retumilon eldoni HTTP-prokurajn petojn aŭ SOCKS-negocadojn. Same, entajpi prokurilon en la retumilo ne enkursigas ĉiun alian aplikaĵon tra tiu maŝino.
Gastiganto povas plenumi ambaŭ taskojn, sed tiam ĝi havas du agordojn por administri: la prokuran servon kaj la enkursigan aŭ fajroŝliman funkcion. Pli da interfacoj povas faciligi retan apartigon. Ili estas topologia elekto, ne antaŭkondiĉo trudita de eksplicita HTTP-prokurado.
Ĉi tiu distingo ankaŭ klarigas oftan malsukcesan eksperimenton: redakti la plusendajn regulojn de prokura servilo havas neniun efikon al rekta klienta konekto, kiu vojas tra alia enkursigilo. La pakaĵoj neniam transiris tiun servilon.
Se la postulo estas deviga uzo, difinu kie oni povas kontroli alternativan eliran trafikon. Eksplicita prokurilo kun unu interfaco povas esti valida servo, dum aparta enirejo plenumas la retan politikon. Metu la plenumadon tie, kie la pakaĵoj efektive pasas.