HAProxy 302 դեպի մասնավոր հավելված. ո՞վ է բացում երկրորդ թռիչքը։

Ինչ-որ մեկը հանրային HAProxy հոսթը ուղղում է ներքին հավելվածին և հարցնում, թե ինչու դիտարկիչը չի կարող հետևել։ Ծրակալը VPN-ի միջոցով հասնում է հավելվածին, վերահղումը վերադարձնում է Location վերնագիր, և դիտարկիչն այնուհետև փորձում է հասցե, որը գոյություն ունի միայն թունելի ներսում։ Դրսից էջը պարզապես կախվում է։ Որոշումը այն մասին է, թե որ կողմն է բացում երկրորդ կապը, և դա է տարբերում վերահղումը backend-ից։

Երկու ուղի, որոնք կոնֆիգուրացիայում նման են երևում

Վերահղումը ավարտում է փոխանակումը պատասխանով։ Հաճախորդը կարդում է Location-ը և նոր հարցում սկսում այնտեղից, որտեղ գտնվում է, այսինքն այն ցանցից, որը դուք երբեք չեք վերահսկել։ Ծրակալն այլևս չի մասնակցում։ Ամեն ինչ հաջորդողը կախված է հաճախորդի սեփական DNS-ից, երթուղուց և վստահությունից, ուստի արդյունքը տարբերվում է՝ կախված նրանից, թե որտեղ է օգտատերը բացել դիտարկիչը:

GET /app        client -> proxy
302 Location    proxy  -> client   (http://10.40.0.20:8080/)
GET /app        client -> 10.40.0.20:8080   client network, no route

Ծրակալի backend-ը երկրորդ փուլը պահում է սերվերի կողմում։ Ծրակալը բացում է այն արդեն իսկ ունեցած ուղիով, և հաճախորդը շարունակում է խոսել մեկ հանրային անվան հետ։ Եթե թունելն ընկնի, հաճախորդը ստանում է սխալ այն URL-ի փոխարեն, որին չի կարող հետևել։ Այդ տարբերությունն է, որ խափանումը դարձնում է ախտորոշելի, որովհետև սխալը հայտնվում է այնտեղ, որտեղ տեղեկամատյաններն են:

GET /app        client -> proxy
GET /app        proxy  -> 10.40.0.20:8080   over the VPN
response        proxy  -> client

HAProxy-ի վերահղումների փաստաթղթերը գծում են հենց այդ սահմանը՝ հաճախորդին վերահղումով պատասխանելը տարբեր գործողություն է, քան հարցումը backend-ին փոխանցելը։ Երկու հրահանգները կոնֆիգուրացիայի ֆայլում մի քանի տող հեռավորության վրա են և բոլորովին այլ կերպ են վարվում։ Մեկը ավարտում է հարցումը, մյուսը սկսում է երկրորդը, որը պատկանում է ծրակալին։

Ինչ է պետք դիտարկիչին և ինչ չի տալիս նրան սերվերի VPN-ը

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

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

Երբ միայն ծրակալը կարող է հասնել հավելվածին

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

backend private_app
    mode http
    option httpchk GET /health
    server app1 10.40.0.20:8080 check

Կարդացեք այդ բլոկը որպես հայտարարություն ծրակալի երթուղային աղյուսակի մասին՝ 10.40.0.20-ը պետք է հասանելի լինի հենց ծրակալի հոսթից, ինչը այստեղ նշանակում է VPN ինտերֆեյսով, այլ ոչ թե լռելյայն երթուղով։ check բառը միայն հաղորդում է, թե ինչ է անում այդ երթուղին, և առողջության ուղին պետք է գոյություն ունենա հավելվածում, այլապես ամեն ստուգում սերվերը կնշի որպես անջատված։ Հաջող ստուգումը ոչինչ չի ապացուցում հաճախորդի մասին և չի փոխարինում այն քաղաքականությանը, որը որոշում է, թե ով կարող է օգտվել backend-ից։

Այս հատվածը ամբողջական frontend չէ։ Պահեք լսողին, նույնականացումը, թույլատրված հոսթի և ուղու ընտրությունը, և այն կանոնը, որը որոշում է, թե ով կարող է ընդհանրապես հասնել հավելվածին։ Համաձայնեցրեք նաև backend-ի արձանագրությունը, որովհետև HTTPS backend-ը պահանջում է վկայականի ստուգում և սերվերի ինքնության կարգավորում, և այդ ստուգումը բաց թողնելը մասնավոր կապը դարձնում է չստուգված։

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

Հավելվածի սեփական վերահղումները դեռ ներս են ցույց տալիս

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

Սահմանեք հավելվածի փաստաթղթավորված արտաքին URL-ը և դրա ծրակալի ընտրանքները, ապա Host վերնագիրը համաձայնեցրեք վիրտուալ հոսթի և վկայականի սպասումների հետ։ Ներքին անվանը սահմանափակված քուքին չի վերադառնա հանրային անվան միջով, և դրան հաջորդող մուտքի հանգույցը կարդացվում է որպես նույնականացման սխալ։ Նախ փոխեք արտաքին URL-ը, նորից փորձարկեք մաքուր դիտարկիչի պրոֆիլից և սպասեք, որ կիսով տեղափոխված կարգավորումները կստեղծեն հաջող մուտք և անմիջապես մահացող նստաշրջան։

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

Որոշեք, թե իրականում որ նախագիծն ունեք

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

Գործարկեք ստուգումը օգտատերերի ցանցում գտնվող մեքենայից և հետևեք դիտարկիչի յուրաքանչյուր թռիչքին, ոչ միայն առաջին պատասխանին։ Հետևեք հասցեի տողին և յուրաքանչյուր հաջորդ հարցմանը, որովհետև ռեսուրսային պիտակում մեկ բացարձակ URL-ը բավական է կոտրելու հոսքը, որն անցել էր առաջին թռիչքը։ Մուտքը պետք է աշխատի հանրային անվան միջով, և այն ռեսուրսները, որոնք պետք է մերժվեն, պետք է մերժված մնան։

Հակադարձ ծրակալ հրապարակելը առանձին հասանելիության որոշում է, ոչ թե ծրակալի սեփական VPN-ի թափանցիկ ընդլայնում բոլորի վրա, ով կարող է բեռնել նրա հանրային URL-ը։ Երկուսը դիագրամում նույնն են թվում և տարբերվում են նրանով, թե ում է թույլատրվում ներս մտնել։ Այդ հարցը տեղակայումից հետո որոշելն է այն ուղին, որով ներքին հավելվածը պատահաբար դառնում է հանրային։

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