Մեկ ցանցային քարտը բավական է բացահայտ պրոքսիի համար

Մասնավոր forward proxy-ն պարտադիր չէ, որ ֆիզիկապես գտնվի նոութբուքի և երթուղիչի միջև։ Այն կարող է լինել նույն LAN-ի մեկ այլ մեքենա՝ օգտագործելով մեկ ցանցային ինտերֆեյս։

Նոութբուքը միանում է պրոքսիի հասցեին և լսող պորտին։ Պրոքսիի գործընթացը բացում է առանձին կապ դեպի կայքը կամ դրա ծնողը։ Նույն ինտերֆեյսը կարող է կրել երկու զրույցները, իսկ հոսթի երթուղային աղյուսակը ընտրում է հաջորդ քայլը։

client → proxy listener
proxy → existing router → destination

Դա բավական է այն հավելվածի համար, որը բացահայտ ընտրել է պրոքսին։ Linux-ում այս սովորական կարգավորումը չի պահանջում IP փոխանցման միացում միայն հավելվածի հարցումները փոխանցելու համար։

Լռելյայն դարպասը պատասխանում է այլ հարցի

Հաճախորդի լռելյայն դարպասը մշակում է այն փաթեթները, որոնք հաճախորդն ուղարկում է դեպի այլ ցանցեր։ Այդ կարգավորումը փոխելը չի ստիպում դիտարկիչին ուղարկել HTTP պրոքսի հարցումներ կամ SOCKS բանակցություն։ Նույն կերպ, դիտարկիչում պրոքսի մուտքագրելը չի ուղղորդում յուրաքանչյուր այլ հավելված այդ մեքենայով։

Հոսթը կարող է կատարել երկու աշխատանքն էլ, բայց այդ դեպքում ունի երկու կոնֆիգուրացիա՝ պրոքսի ծառայությունը և երթուղման կամ firewall-ի ֆունկցիան։ Ավելի շատ ինտերֆեյսներ կարող են հեշտացնել ցանցերի բաժանումը։ Դրանք տոպոլոգիայի ընտրություն են, ոչ թե բացահայտ HTTP պրոքսիի պարտադրած նախապայման։

Այս տարբերությունը բացատրում է նաև հաճախ ձախողվող փորձը․ պրոքսի սերվերի փոխանցման կանոնները խմբագրելը ոչ մի ազդեցություն չունի մեկ այլ երթուղիչով անցնող ուղիղ հաճախորդային կապի վրա։ Փաթեթները երբեք չեն անցել այդ սերվերով։

Եթե պահանջը պարտադիր օգտագործումն է, որոշեք, թե որտեղ կարելի է վերահսկել այլընտրանքային ելքային տրաֆիկը։ Մեկ ինտերֆեյսով բացահայտ պրոքսին կարող է վավեր ծառայություն լինել, մինչ առանձին դարպասը կիրառում է ցանցային քաղաքականությունը։ Տեղադրեք կիրառումը այնտեղ, որտեղ փաթեթներն իսկապես անցնում են։