Լինուքսի փաթեթային ո՞ր ուղին պետք է պարտադրի պրոքսիի օգտագործումը:

Լինուքս դարպասը կարող է գործարկել պրոքսիի պրոցեսը և միաժամանակ երթուղավորել երթևեկությունը դրա կողքով։ Սրանք նույն փաթեթային ուղին չեն։

Netfilter-ը տարբերում է մուտքային, փոխանցման և ելքային ուղիները։ Դարպասի սեփական պրոքսի լսիչի հասանելիությունը կարգավորող կանոնը ինքնաբերաբար չի սահմանափակում այդ մեքենայով անցնող յուրաքանչյուր երթուղավորված միացում։

Սահմանեք, թե ինչ պետք է պարտադրվի

Եթե հաճախորդները պարտավոր են օգտագործել հաստատված պրոքսին, ապա քաղաքականությունը պետք է անդրադառնա նաև նրանց այլընտրանքային ելքային ուղիներին՝ նախատեսված լսիչին թույլատրելու հետ մեկտեղ։ Ցանկացած հեռավոր ծառայության միացումներ թույլատրելը միայն այն պատճառով, որ այն օգտագործում է ծանոթ պրոքսի նավահանգիստը, նույնը չէ, ինչ թույլատրել միայն ձեր պրոքսի վերջնակետը։

Պրոքսիի սեփական հետագա հասանելիությունը առանձին պահեք։ Squid-ի դեպքում տարբերակեք տեղական սոքեթի սեփականությունը LAN օգտվողի ինքնությունից՝ նախքան ելքի թույլտվություն կիրառելը։ Պրոքսիի բոլոր օգտակար ելքային միացումների մերժումը անհրաժեշտ ուղին կդարձնի անհասանելի։ Կառավարման երթևեկությունը, անունների լուծումը և աջակցվող ոչ վեբ գործողությունները նույնպես տեղակայման քաղաքականության մեջ պահանջում են դիտավորյալ մշակում։

Արձանագրության շրջանակը կարևոր է։ TCP կանոնն ինքնին չի նկարագրում UDP երթևեկությունը, ներառյալ QUIC-ը։ Երթևեկության գաղտնալսումը այլ նախագիծ է. բացահայտ HTTPS պրոքսին կարող է տրամադրել CONNECT՝ առանց կայքի նստաշրջանը վերծանելու։

Քարտեզագրեք նախատեսված միացումները նախքան կանոնների հավաքածուն խմբագրելը։ Դիտարկիչի նախապատվությունը ընտրում է ուղի մասնակից հաճախորդների համար։ Ցանցային պարտադրումը որոշում է, թե որ այլ ուղիները կարող են հաջողվել։ Դրանցից ոչ մեկը չպետք է ենթադրվի միայն պրոքսիում հաջող մուտքից։