Listen, Bind և BindSame. ո՞ր հասցեն է հաղթում Tinyproxy-ում
Listen-ը ընտրում է այն հասցեն, որն ընդունում է հաճախորդներին, Bind-ը՝ ելքային կապերի աղբյուրը։ Ոչ մեկը երթուղի չի տեղադրում, ուստի ուղին ստուգեք առանձին։
Փրոքսին պատասխանում է, հարցումն ավարտվում է, և այնուամենայնիվ նպատակակետը դեռ գրանցում է տեղային ցանցի հասցեն։ Փրոքսիի մատյանում ոչինչ սխալ չի թվում, և ձեր փոխած տողը հենց այն տողն է, որը փաստաթղթերը խորհուրդ էին տալիս փոխել։ Այն հոսթում, որն ունի և՛ տեղային ցանցի հասցե, և՛ թունելի հասցե, երեք հրահանգ է որոշում, թե որ հասցեն որտեղ կհայտնվի, և դրանցից միայն մեկն է վերաբերում ելքային կողմին։ Սխալ հերթականությամբ կարդալու դեպքում դուք առանց պատճառի հայտնվում եք երթուղային աղյուսակում։
Ախտանիշը. նպատակակետը տեսնում է տեղային ցանցի հասցեն
Հաճախորդը միանում է փրոքսիին տեղային ցանցի հասցեով, և փրոքսին բացում է իր սեփական կապը դեպի նպատակակետը։ Այդ երկրորդ կապն ընտրում է աղբյուրի հասցեն ըստ միջուկի կանոնների, և լռելյայն դա այն է, ինչ ընտրում է երթուղու որոնումը։ Այդ պատճառով նպատակակետը գրանցում է հոսթի հիմնական հասցեն, թեև ամեն բայթ անցել է փրոքսիով։ Փոխանցման առումով ոչինչ կոտրված չէ, և դրա համար է, որ փրոքսիի մատյանն այս մասին ոչինչ չունի ասելու։
Այդ խափանքի հայելային պատկերն ավելի հեշտ է նկատել. ամրացրեք ելքային աղբյուրը թունելի հասցեին, և տեղային ցանցի հաճախորդները բոլորովին չեն հասնի լսողին։ Այդ տարբերակն ինքն է հայտնում իրեն, մինչդեռ առաջինը թաքնվում է աշխատող հարցման հետևում։ Երկուսն էլ առաջանում են մեկ հրահանգը երկու հարցերի պատասխանող համարելուց։
Երեք հրահանգ, երեք տարբեր հասցե
Listen-ը նշում է այն տեղական հասցեն, որն ընդունում է փրոքսիի հաճախորդներին։ Bind-ը տալիս է աղբյուրի հասցե այն կապերի համար, որոնք փրոքսին բացում է դուրս, իսկ BindSame-ը հրահանգում է նորից օգտագործել հենց նոր ընդունված կապի տեղական հասցեն։ Սրանք երեք առանձին հարցեր են, և մեկ տողը պատասխանում է միայն մեկին։ Դրանք շփոթելը սովորական պատճառն է, թե ինչու փոփոխությունը ոչինչ չի անում թվում։
| What you observe | Check first |
|---|---|
| A client cannot connect at all | Listen: the local address the listener binds |
| The request works but the far side logs the LAN address | Bind: the outgoing source is not being applied |
| A configured Bind appears to have no effect | BindSame yes: the accepted local address overrides the Bind list |
| The lookup names the LAN interface | The route, not the proxy: the source cannot reach that destination |
Կարդացեք տեղադրված տարբերակի հետ տրվող մեկնաբանված կարգավորումը, որովհետև լռելյայն արժեքները և ընդունված շարահյուսությունը փոխվում են թողարկումների միջև։ Նախագծի օրինակ կարգավորումը փաստագրում է յուրաքանչյուր հրահանգը մյուսների կողքին։ Համեմատեք այդ ֆայլը սկավառակի վրա եղածի հետ, ոչ թե այլ բաշխման համար գրված ուղեցույցի հետ։
Կարգավորեք լսողին և ելքային աղբյուրը անկախ
Վերցրեք հոսթ, որի տեղային ցանցի հասցեն 192.168.50.10 է, իսկ թունելի հասցեն՝ 10.90.0.3։ Եթե տեղային ցանցի հաճախորդները պետք է հասնեն փրոքսիին, մինչ դրանց հարցումները դուրս են գալիս թունելով, դրանք երկու անկախ որոշումներ են, և երկուսն էլ պետք է գրվեն։ Ստորև բերված հատվածն արտահայտում է հենց դա և ոչ այլ բան։
Listen 192.168.50.10
Bind 10.90.0.3
BindSame noՍա ամբողջական կարգավորում չէ, ուստի պահպանեք հաստատված պորտը, նույնականացումը, հաճախորդների մուտքի վերահսկումը և նպատակակետային սահմանափակումները։ Երկու հասցեներն էլ պետք է պատկանեն այս հոսթին Tinyproxy-ի ցանցային անվանատարածքի ներսում, որովհետև այն Bind արժեքը, որը գործընթացը չի կարող տիրել, ձախողվում է միանալիս, ոչ թե մեկնարկելիս։ BindSame yes-ը նկարագրում է այլ քաղաքականություն, որտեղ ընդունված կապի տեղական հասցեն դառնում է ելքային աղբյուր։ Ներկա թողարկումներում այդ ճյուղն առաջնահերթ է Bind ցանկի նկատմամբ, և այդպես է, որ կարգավորված աղբյուրը անհետանում է առանց սխալի։
Ստուգեք այն ուղին, որը ենթադրում է աղբյուրը
Աղբյուրի հասցե ընտրելը ուղի չի ստեղծում, ուստի հարցրեք միջուկին, թե ինչ կանի այդ աղբյուրի և այդ նպատակակետի հետ։ Այն որոնումը, որը նշում է թունելի ինտերֆեյսը, նվազագույն ապացույցն է, իսկ տեղային ցանցի ինտերֆեյսը նշողը նշանակում է, որ աղբյուրը չի կարող աշխատել գրվածի պես։ Որոնումը համատեքստային է. այն գնահատում է այդ անվանատարածքի համար գործող քաղաքականության կանոնները և աղյուսակը։ Այն կապ չէ և ոչինչ չի ասում այն մասին, թե ինչ կներկայացնի ներքևի NAT-ը ծառայությանը։
ip -4 route get 203.0.113.25 from 10.90.0.3Օրինակում օգտագործեք փաստաթղթային հասցե և փոխարինեք այն ծառայությամբ, որը ձեզ թույլատրված է փորձարկել։ Երբ փրոքսին աշխատում է կոնտեյներում, որոնումը կատարեք փրոքսիի անվանատարածքի ներսում, որովհետև հոսթի կանոնները այն կանոնները չեն, որ տեսնում է գործընթացը։ Երբ նախատեսված թունելային ուղին բացակայում է, թող ցանցի սեփականատերը ուղղի այն՝ փրոքսիի հոսթին նպատակակետային հատուկ կանոններ ավելացնելու փոխարեն։ Մի մաքրեք հոսթի երթուղիները և մի անջատեք սերվերի կողմից ուղարկվող երթուղիները, որպեսզի որոնումը հաջողի, նույնիսկ եթե հին ուղեցույցն այդպես է արել, որովհետև նման փոփոխությունները տեղափոխում են ամբողջ հոսթի հաստատված VPN վարքը՝ մեկ փրոքսի ուղի վերանորոգելու համար։
Հաստատեք աղբյուրը նպատակակետում
Կարդացեք աղբյուրը այնտեղ, որտեղ հարցումը հասնում է, ոչ թե որտեղից այն դուրս է գալիս։ Նպատակակետի հավելվածի մատյանը կամ դրա դիմացի եզրային սարքը գրանցում է այն հասցեն, որը նա իրականում տեսել է, մինչդեռ փրոքսին կարող է պատմել միայն իր մտադրության մասին։ Փոփոխությունից հետո նախատեսված լսողի միջով մեկ նոր հարցում արեք, որովհետև պահված կապը ոչինչ չի ապացուցում նոր կապակցման մասին։ Այնուհետև համեմատեք գրանցված հասցեն ձեր կարգավորած հասցեի հետ։
ss -ltnp | grep tinyproxy
curl -x http://192.168.50.10:8888 https://example.com -o /dev/null -sScurl-ը միայն երթևեկության գեներատորն է. ստուգման արժանի հասցեն այն է, որը գրանցել է հեռավոր կողմը, ոչ թե այն զուգընկերը, որին curl-ը պատահաբար միացել է։ Եթե երկուսը չեն համընկնում, որոշեք՝ տարբերությունը աղբյուրի ընտրությունից է, թե ավելի առաջ կատարվող փոխակերպումից, որովհետև դրանք տարբեր տեղերում են ուղղվում։ Պլանավորեք հասցեների փոփոխությունները և փրոքսիի վերագործարկումները միասին, որովհետև այն հասցեի կապակցումը, որը թունելն այլևս չունի, վերամիանալուց հետո լուռ ձախողվում է։ DNS-ի և IPv6-ի վարքը նույնպես սահմանեք առանձին, որովհետև վերևի IPv4 հատվածը ոչ մեկի մասին ոչինչ չի ապացուցում։