Ինչու ձեր URL-ին պետք է մուտք 80 կամ 443 պորտով, ոչ թե 45000

Մուտքագրեք հոսթի անուն բրաուզերում, և սխեման որոշում է նպատակակետ պորտը՝ 80-ը http-ի համար, 443-ը https-ի համար։ DNS պատասխանում ոչինչ չի վերացնում դա, և ձեր մեքենայի ոչ մի վերահասցեավորման կանոն չի կարող հորինել լսող մատակարարի եզրին։ Երբ VPN մատակարարը ձեզ տալիս է բարձր հանրային պորտ, օրինակ 45000, բացահայտ URL-ը աշխատում է, իսկ մաքուրը՝ ոչ։ Բացը մուտքի կետում է, ոչ թե հավելվածի ներսում։

Անցեք բրաուզերից մինչև գործընթաց ուղին մեկ անգամ, և հրապարակման երեք տարբերակներն այլևս առեղծվածային չեն թվա։

Տեսեք, թե ուր է իրականում գնում հարցումը

Բրաուզերը լուծում է անունը հասցեի, ապա միանում այդ հասցեին սխեմայի լռելյայն պորտով, եթե URL-ը այլ պորտ չի նշում։ Ձեր մատակարարի եզրն է որոշում, թե ինչ է լինում ժամանող կապի հետ։ Եթե նրա վերահասցեավորման աղյուսակը միայն 45000-ն է քարտեզագրում ձեր ներքին հասցեին, ապա 80-ի կապը տեղ չունի գնալու և մերժվում կամ գցվում է նախքան ձեր մեքենան ընդհանրապես ներգրավվելը։

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

Ինչու տեղական կանոնը չի կարող շտկել եզրը

Վերահասցեավորումը կամ DNAT կանոնը հավելվածի հոսթի վրա ազդում է արդեն ժամանած փաթեթների վրա։ Մատակարարի մոտ 80 պորտ ուղարկված փաթեթները երբեք չեն ժամանում, ուստի կանոնը երբեք չի գնահատվում։ Սա ամբողջ խնդրում ամենահաճախ վատնված ժամն է։

DNS-ն նույնպես չի կարող կրել պորտը։ HTTP ճշգրտում-ը սահմանում է սխեմայի լռելյայնները, և A կամ AAAA գրառումը վերադարձնում է հասցե, մինչդեռ CNAME-ը վերադարձնում է այլ անուն։ Բրաուզերը դեռ միացնում է սխեմայի պորտը, ուստի նպատակակետը փոխում է միայն URL-ի բացահայտ պորտը։

Տարբերակ առաջին՝ պահել բացահայտ պորտը

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

Քանի դեռ այնտեղ եք, ստուգեք վերահասցեավորումները և քուքիների շրջանակը, որովհետև սեփական հոսթի անունը Location վերնագրում գրող backend-ը չեղարկում է այս կարգավորումը։

Տարբերակ երկրորդ՝ ստանալ իրական մուտք լռելյայն պորտով

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

Հաստատեք սեփականությունը և հասանելիությունը գրավոր, ներառյալ այն, թե ինչ է լինում մուտքի հետ, երբ թունելը կրկին միանում է այլ հասցեով։ Թունելի հետ շարժվող մուտքը ստեղծում է ընդհատումներ, որոնք նման են DNS խափանումների։

Տարբերակ երրորդ՝ առջևում դնել frontend

Հասանելի հասցեում հակադարձ պրոքսին կարող է 443-ում լսել և ավարտել TLS-ը և առանձին կապ բացել backend-ի հետ VPN-ի միջոցով։ Այցելուները տեսնում են frontend-ի անունը և լռելյայն պորտը, մինչդեռ frontend-ը ձեր անունից խոսում է backend-ի բարձր պորտի հետ։ Սա աշխատում է, որովհետև փոխում է ճարտարապետությունը՝ փոխարենը պայքարելու մուտքի կետի դեմ։ Այնուհետև backend-ին ընդհանրապես պետք չէ ներգնա պորտ հանրային ինտերնետում։

Սա նաև փոխում է այն, ինչ դուք շահագործում եք։ Frontend-ին պատկանում է հանրային TLS-ը, մուտքի քաղաքականությունը, մատյանները և հասանելիությունը, և այն պետք է սահմանի backend-ի ընտրությունը նախատեսված ծառայությամբ։ Եթե frontend-ից backend անցումը օգտագործում է HTTPS, պահեք վկայագրի վավերացումը այդ անցումում։

Պահեք մեկ ծագում

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

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