Նվիրված VPN IP-ն չի հրապարակում ձեր կայքը
Նվիրված ելքի հասցեն ոչինչ չի ասում ներմուծվող առաքման մասին։ Ստուգեք փոխանցման պայմանագիրը, ավարտեք սկզբնաղբյուրի կողմը և հետո հրապարակեք բարձր պորտ։
VPN մատակարարից նվիրված IP գնելը նման է մուտքի դուռ գնելուն։ Հասցեն կայուն է, թունելը աշխատում է, բայց կայքը դրսից ոչ մեկի մոտ չի բացվում։ Այն, ինչ գնել եք, հասցեի հատկացում է, ոչ թե ներմուծվող փոխանցման կանոն։ Երկուսն էլ վաճառվում են նույն խանութում և կարգավորվում են բոլորովին տարբեր տեղերում։
Հասցեն հատկացում է, ոչ թե փոխանցման կանոն
Գրանցեք ներմուծվող հանրային հասցեն կամ հոսթի անունը, թույլատրված տրանսպորտը, հատկացված արտաքին պորտը և այն հաճախորդային նպատակակետը, ուր մատակարարը առաքում է։ Ապա հաստատեք, որ ձեր ընտրած սերվերը, արձանագրությունը և հաշվի գործառույթը իրոք աջակցում են փոխանցմանը, և որ մատակարարը թույլատրում է հոսթինգ այնտեղ։
Նվիրված բառը նկարագրում է հասցեի հատկացումը։ Այն չի նշանակում, որ չպահանջված ներմուծվող երթևեկությունը թույլատրված է, և նույն օպերատորի տարբեր հավելումները կարող են տարբեր հնարավորություններ ունենալ։ Նվիրված հասցեն և նվիրված սերվերի արտադրանքը երկու պիտակներն են, որոնք ամենից հաճախ շփոթում են, և աջակցության էջերը սովորաբար պարզաբանում են, թե որն է փոխանցում։
| What you have | What it gives you | What it does not |
|---|---|---|
| Dedicated exit address | A stable source address for outbound traffic | Any inbound delivery at all |
| Port-forwarding add-on | A provider-side mapping to your session | Permanence across reconnects |
| Local DNAT rule | Handling for packets that arrive | Making packets arrive |
Օրինակելի պայմանագիրն այսպիսի տեսք ունի. մատակարարը TCP 203.0.113.60:45000 փոխանցում է ձեր միացված սարքի HTTPS ծառայությանը 8443 պորտով։ Սա ուրիշի կողմից կարգավորված քարտեզագրման նկարագրություն է, ոչ թե կանոն, որը կարող եք ստեղծել նրանց եզրում՝ մուտքագրելով այն ձեր սեփական հրապատին։
Ավարտեք սկզբնաղբյուրի կողմը
Եթե վեբ հավելվածը աշխատում է հենց VPN հաճախորդի վրա, նրան անհրաժեշտ է լսող առաքված պորտի վրա և սահմանափակ տեղական մուտքի թույլտվություն այդ պորտի համար։ Եթե հաճախորդը քարտեզագրված կապը փոխանցում է այլ հոսթի, նրան անհրաժեշտ են նպատակակետի թարգմանություն, փոխանցման քաղաքականություն և պատասխանի ուղի, որը դիմանում է գնալ-գալուն։
Մուտքի կանոնները ձևավորեք այն աղբյուր հասցեի շուրջ, որը մատակարարի ուղին իրականում ներկայացնում է։ Դա միշտ չէ սկզբնական այցելուն, և միշտ չէ նաև VPN սերվերը, ինչը կարևոր է, երբ գրում եք կանոն, որին կհամապատասխանի այդ հասցեներից միայն մեկը։
Պորտի թարգմանությունը նույնպես HTTP-ն HTTPS չի դարձնում։ Հանրային պորտը և տեղական հավելվածի պորտը կարող են ազատ տարբերվել, բայց սխեման, վկայագրի ինքնությունը և վերահղումները դեռ պետք է համապատասխանեն այն ծառայությանը, ուր մարդիկ իրականում հասնում են։ Եթե վկայագիրը նշում է հանրային հոսթը, պահեք այդ անունը ամեն քայլին։ Այստեղ անհամապատասխանությունը երևում է որպես դիտարկիչի նախազգուշացում, ոչ թե երթուղման ձախողում, ինչը մարդկանց մեկ ժամով ուղարկում է սխալ մատյաններ։
Հրապարակեք բարձր պորտը ազնվորեն
Եթե այցելուները միանում են ուղղակիորեն, և մատակարարը հատկացրել է բարձր պորտ, տվեք նրանց ամբողջական URL-ը։ Սովորական DNS հասցեի գրառումը չի կարող պորտ ավելացնել HTTPS հարցմանը, որն ըստ լռելյայն օգտագործում է 443, և TTL-ի ոչ մի կարգավորում դա չի փոխում։
Վեբ ֆրոնտենդը կարող է լուծել սա՝ ընդունելով այցելուներին սովորական պորտում և ինքնուրույն միանալով փոխանցված սկզբնաղբյուրի պորտին։ Սակայն Cloudflare-ի լռելյայն պրոքսի պորտերը սահմանված ցանկ են, և կամայական հատկացված պորտը չի դառնում աջակցվող եզրային պորտ միայն այն պատճառով, որ դուք ավելացրել եք պրոքսավորված DNS գրառում։
Սկզբնաղբյուրի նպատակակետ պորտը փոխելը տարբեր գործողություն է, քան այցելուի պորտը փոխելը։ Cloudflare-ի Origin Rules փաստաթղթավորում են նպատակակետ պորտի վերագրանցում backend կապի համար՝ սահմանափակված աջակցվող կանոնով, սխեմայով և հոսթի անունով։ Պորտի վերագրանցումը ընդհանուր ռելե չէ կամայական UDP-ի կամ այլ արձանագրությունների համար։
Երբ ֆրոնտենդը ավարտում է TLS-ը, վավերացրեք երկու քայլերը՝ դիտարկիչից ֆրոնտենդ վկայագիրը և ֆրոնտենդից սկզբնաղբյուր կապը։ VPN քայլը չի փոխարինում երկու ստուգումներից ոչ մեկին, և ներքին հասցեի արտահոսքը վերահղումների կամ քուքիների մեջ սովորական նշան է, որ երկուսից միայն մեկն է կարգավորվել՝ նկատի ունենալով հանրային անունը։
Պահեք քարտեզագրումը կենդանի
Որոշ մատակարարներ վերամիացումից հետո այլ պորտ են հատկացնում, և վարձակալված քարտեզագրումը կարող է պահանջել նորացում մատակարարի կողմի գործողությամբ։ Հետևեք այն մեխանիզմին, որը փաստաթղթավորում է ձեր մատակարարը, և թարմացրեք լսողին, տեղական կանոնները, DNS-ը կամ ֆրոնտենդի կանոնը միայն այնտեղ, որտեղ դա պահանջում է ընթացիկ պայմանագիրը։
Ստատիկ հանրային հասցեն պորտի վարձակալությունը ստատիկ չի դարձնում։ Վահանակում դեռ ցուցադրվող հասցեն և պորտը ապացույց չեն, որ ակտիվ նստաշրջանը տիրապետում է քարտեզագրմանը, դրա համար էլ փորձարկումը դրսից արված նոր հարցում է, ոչ թե էկրանի պատկեր։
Ապա կրկնեք այն դեպքերը, որոնք սպասում եք՝ սովորական վերամիացում և VPN կորուստ։ Եթե կորուստը պետք է սկզբնաղբյուրը դարձնի անհասանելի, թույլ չտաք թարմացնողին լուռ վերահրապարակել ուղիղ ISP ուղին ֆոնում։ Եվ եթե փոխանցման պայմանագիրը չի կարող բավարարել կայքի կայունության պահանջները, ընտրեք հրապարակման այլ դասավորություն՝ փոխարենը նոր հասցեի պիտակ գնելու և սերվերի պես վարվելու հույս ունենալու։