Retejoj en la sama subreto povas preterpasi la travideblan prokurilon de enirejo
Klarigas kial trafiko en la sama subreto povas preterpasi interkaptan regulon de enirejo, dum interretaj petoj aperas en ĝia protokolo.
Interreta retumado aperas en la protokolo de la enireja prokurilo. Retejo en la oficeja loka reto ne aperas. Antaŭ ol ŝanĝi la URL-filtrilon, konstatigu ĉu la loka peto ĝenerale atingis la enirejon.
Por rekte konektita IPv4-celo, la kliento povas solvi la ligtavolan adreson de la celo kaj sendi al ĝi sur la loka segmento. Ĝia implicita enirejo ne estas aŭtomate sur tiu vojo. Travidebla interkapta regulo sur la enirejo ne povas redirekti pakaĵojn, kiujn la enirejo neniam ricevas.
Ekzemple, du gastigantoj en la sama rekte ligita subreto povas interŝanĝi trafikon per ŝaltilo, dum la prokurila maŝino estas konektita al alia ŝaltila pordo. Nur esti en tiu loka reto ne faras la prokurilon la plusenda punkto.
Elektu la celatan vojon
Eksplicita prokurila agordo povas sendi la peton de la partoprenanta aplikaĵo al la prokurilo eĉ kiam la cela retejo estas loka. Kontrolu ankaŭ preterpasajn regulojn kaj PAC-decidojn: ili povas intence elekti DIRECT por privataj nomoj aŭ adresoj.
Se interkapto necesas, la reto devas efektive meti la interkaptan punkton sur la vojon; sur Linux-enirejo distingigu lokajn kaj plusenditajn pakaĵvojojn. Vojo-bazita subreta apartigo aŭ intence enlinia ponto povas fari tion en taŭgaj projektoj, sed ĉiu ŝanĝas plusendan kaj malsukcesan konduton. Ponto aliloke en la loka reto ne estas aŭtomate enlinia.
Tenu la postulon pri la aplikaĵa protokolo aparte. Eĉ post kiam la trafiko trapasas la aparaton, la aŭskultanto devas subteni la interkaptan reĝimon. Movi la pakaĵojn ne estas permeso malĉifri HTTPS nek garantio, ke ordinara SOCKS-pordo povas akcepti ilin.
Registru la elektitan vojon de la kliento, la lokan segmenton kaj la faktan plusendan aparaton. Mankanta prokurila protokolo povas esti ĝusta priskribo de la topologio, ne registra fiasko.