Ինչու է Port-Share-ը բոլոր կայքի այցելուներին ցույց տալիս որպես localhost

Մուտքի մատյանի յուրաքանչյուր տող ցույց է տալիս նույն loopback հասցեն, մինչդեռ էջն ինքը բեռնվում է, և վկայագիրը ճիշտ է ստուգվում։ Ոչինչ կոտրված չէ անհասանելիության իմաստով, և հենց դրա համար է այս վիճակը պահպանվում ամիսներով։ Կոտրվել է վերագրումը. վեբ բեքենդը գրանցում է այն թռիչքի հասցեն, որը փոխանցել է կապը, և մատյանին վստահած յուրաքանչյուր հետագա որոշում ժառանգել է նույն սխալ պատասխանը։

Ստորև բերված ստուգումները գնում են մալուխից դեպի ներս։ Կանգ առեք առաջինի մոտ, որը բացատրում է ձեր տեսած արժեքը, քանի որ յուրաքանչյուր հաջորդ քայլ ենթադրում է, որ նախորդներն արդեն ճշմարիտ են։ Դրանցից ոչ մեկը չի պահանջում գուշակել ճակատային մասի կարգավորումը։

Հետևեք երկու կապերին, ոչ թե մատյանի տողին

Port-Share-ը մուլտիպլեքսում է երկու արձանագրություն մեկ TCP լսողի վրա։ OpenVPN-ը զննում է մուտքային կապի առաջին բայթերը, պահում է այն, երբ այն նման է իր արձանագրությանը, և մնացած ամեն ինչ փոխանցում է երկրորդ նպատակակետին։ Այդ նպատակակետը սովորաբար նույն հոսթի վեբ սերվերն է, ուստի վեբ սերվերի ընդունված սոքեթի զույգը OpenVPN գործընթացն է։

ss -ltnp 'sport = :443'
ss -tnp 'dport = :8080'

Առաջին հրամանը ցույց է տալիս, թե ում է պատկանում հանրային լսողը։ Երկրորդը ցույց է տալիս բեքենդի պորտին հասնող կապերը, և դրանց զույգի հասցեն այն է, ինչ տպելու է մուտքի մատյանը։ Եթե այդ զույգը loopback է, մատյանը ճշգրիտ է, և տեղեկությունը կորել է մեկ շերտ ավելի վաղ։ Մատյանի դաշտը վերանվանելը կամ հաճախորդի IP մոդուլը միացնելը չի վերականգնի հասցե, որը կապը երբեք չի կրել։

Սա այն ստուգումն է, որը որոշում է մնացած ամեն ինչ։ Եթե բեքենդի զույգը դիտարկիչի հասցեն է, ապա պորտի բաժանումը ձեր խնդիրը չէ, և մատյանի ձևաչափն է։

Տրանսպորտի փոխանցումը վերնագրի ներարկում չէ

Փոխանցողը տեղափոխում է բայթեր։ Այն չի վերլուծում HTTP, ուստի չի կարող վերնագիր մտցնել հարցման մեջ, որը երբեք չի կարդում որպես հարցում, և չի կարող որևէ բան ավելացնել TLS հոսքին, որը անցկացնում է անձեռնմխելի։ Պրոքսի վերնագիր սպասող մոդուլը կշարունակի սպասել մեկին, որը ոչ մի բաղադրիչ չի արտադրում։

Երկու մեխանիզմ կարող են կրել բնօրինակ հասցեն, և երկուսն էլ պահանջում են համաձայնություն երկու ծայրերում։ PROXY արձանագրությունը կապի սկզբում ավելացնում է փոքր վերնագիր, և բեքենդը պետք է կարգավորված լինի դրան սպասելու համար. բեքենդը, որը դրան չի սպասում, այդ բայթերը կընդունի որպես հարցման սկիզբ և կձախողվի շփոթեցնող ձևով։ Վստահելի պրոքսի վերնագրերը, ինչպիսին է X-Forwarded-For-ը, աշխատում են, երբ HTTP-ը հասկացող պրոքսին դրանք սահմանում է, և բեքենդին ասվում է, թե որ զույգերն իրավունք ունեն հաստատել դրանք։

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

curl -sS -H 'X-Forwarded-For: 127.0.0.1' https://site.example.com/health
grep -F '127.0.0.1' /var/log/nginx/access.log | tail -n 3

Ընտրովի աղբյուրի քարտեզագրման գրացուցակը

Պորտի բաժանումն ունի ընտրովի գրացուցակի արգումենտ, որը գրանցում է քարտեզագրում բնօրինակ աղբյուրի հասցեի և փոխանցող կապի միջև այն հարթակներում, որտեղ այդ հատկությունը ներդրված է։ Ակնկալվում է, որ վեբ կողմը կդիմի այդ քարտեզագրմանը. դա վերնագիր չէ և չի ներարկվում հարցման մեջ։

Այդ ձևավորումն արժե իմանալ, քանի որ այն բացատրում է, թե ինչու որոշ տեղակայումներ հաղորդում են իրական հասցեներ, իսկ մյուսները՝ ոչ, արտաքինից նույնական ճակատային կարգավորումով։ Տարբերությունը ստացող կողմում է, և սովորաբար ապրում է մի մոդուլում կամ կարկատանում, որը փաթեթավորված վեբ սերվերների մեծ մասը լռելյայն չի միացնում։ Կարդացեք ձեր վեբ սերվերի փաստաթղթերում այն ճշգրիտ կեռիկի մասին, որը նա առաջարկում է, և հաստատեք, որ մոդուլը բեռնված է, այլ ոչ թե ենթադրեք դա։

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

Որոշեք, թե որ բաղադրիչն է երաշխավորում հասցեն

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

Երեք ձևավորում ծածկում են կարիքների մեծ մասը։ Առանձին պահեք հանրային լսողն ու վեբ լսողը, որպեսզի վեբ սերվերը տեսնի իրական զույգերի և վերագրման խնդիր չլինի։ Առջևում դրեք HTTP-ը հասկացող հակադարձ պրոքսի, հարցումն այնտեղ ավարտեք կամ վերլուծեք, և թույլ տվեք, որ այն փոխանցված վերնագիր սահմանի մի բեքենդի համար, որը վստահում է միայն այդ պրոքսիին։ Կամ պահեք պորտի բաժանումը և ընդունեք, որ մատյանները ցույց են տալիս թռիչքը, իսկ մուտքի կանոնները գրված են հավելվածի ինքնության դեմ, ոչ թե հասցեի։

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

Փորձարկեք կանոնը, ոչ թե էջը

Բեռնվող էջը ապացուցում է, որ փոխանցման ուղին աշխատում է, և ոչինչ չի ասում վերագրման մասին։ Փորձարկեք հասցեի սպառողին. մուտքի կանոնը, արագության սահմանը, աուդիտի գրառումը, աշխարհագրական որոնումը։

curl -sS -o /dev/null -w '%{http_code}\n' https://site.example.com/
tail -n 5 /var/log/nginx/access.log
grep -c '' /var/log/nginx/access.log

Համեմատեք թույլատրված արտաքին հարցումը և՛ ճակատային, և՛ բեքենդի գրառումների հետ և հաստատեք, որ մերժելու ենթակա կանոնը դեռ մերժում է, և թույլատրելու ենթակա կանոնը դեռ թույլատրում է։ Եթե մատյանի տողը ճիշտ է, բայց կանոնը դեռ վարվում է այնպես, կարծես բոլորը տեղական են, ապա կանոնը կարդում է այլ դաշտ, քան ձեր ուղղածը։

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