გამოყოფილი 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 პორტზე. ეს სხვის მიერ კონფიგურირებული დაკავშირების აღწერაა და არა წესი, რომლის შექმნაც მათ კიდეზე შეგიძლიათ საკუთარ Firewall-ში აკრეფით.
დაასრულეთ წყაროს მხარე
თუ ვებ აპლიკაცია თავად VPN კლიენტზე მუშაობს, მას სჭირდება მსმენელი მიწოდებულ პორტზე და ამ პორტისთვის შეზღუდული ლოკალური შეყვანის ნებართვა. თუ კლიენტი დაკავშირებულ კავშირს სხვა ჰოსტზე გადასცემს, მას სჭირდება დანიშნულების თარგმნა, გადაცემის პოლიტიკა და პასუხის გზა, რომელიც ორმხრივ მოგზაურობას უძლებს.
წვდომის წესები ააგეთ იმ წყარო მისამართის გარშემო, რომელსაც პროვაიდერის გზა რეალურად წარმოადგენს. ეს ყოველთვის თავდაპირველი ვიზიტორი არ არის და ყოველთვის VPN სერვერიც არ არის, რაც მნიშვნელოვანია, როცა წესს წერთ, რომელსაც მხოლოდ ერთი ამ მისამართიდან დაემთხვეოდა.
პორტის თარგმნა ასევე არ აქცევს HTTP-ს HTTPS-ად. საჯარო პორტი და ლოკალური აპლიკაციის პორტი თავისუფლად შეიძლება განსხვავდებოდეს, მაგრამ სქემა, სერტიფიკატის იდენტობა და გადამისამართებები მაინც უნდა შეესაბამებოდეს იმ სერვისს, სადაც ხალხი რეალურად აღწევს. თუ სერტიფიკატი საჯარო ჰოსტს ასახელებს, შეინარჩუნეთ ეს სახელი ყოველ ნაბიჯზე. აქ არსებული შეუსაბამობა ბრაუზერის გაფრთხილებად ჩნდება და არა მარშრუტიზაციის ჩავარდნად, რაც ხალხს საათით არასწორ ჟურნალებში აგზავნის.
გამოაქვეყნეთ მაღალი პორტი პატიოსნად
თუ ვიზიტორები პირდაპირ უკავშირდებიან და პროვაიდერმა მაღალი პორტი მიუნიჭა, მიეცით მათ სრული URL. ჩვეულებრივი DNS მისამართის ჩანაწერი ვერ დაამატებს პორტს HTTPS მოთხოვნას, რომელიც ნაგულისხმევად 443-ს იყენებს, და TTL-ის არც ერთი შეცვლა ამას არ ცვლის.
ვებ ფრონტენდს შეუძლია ამის გადაჭრა ვიზიტორების ჩვეულებრივ პორტზე მიღებით და გადაცემულ წყაროს პორტთან საკუთარი კავშირის შექმნით. თუმცა Cloudflare-ის ნაგულისხმევი პროქსი პორტები განსაზღვრული სიაა და თვითნებურად მინიჭებული პორტი არ ხდება მხარდაჭერილი კიდის პორტი მხოლოდ იმიტომ, რომ პროქსირებული DNS ჩანაწერი დაამატეთ.
წყაროს დანიშნულების პორტის შეცვლა სხვა ოპერაციაა, ვიდრე ვიზიტორის პორტის შეცვლა. Cloudflare-ის Origin Rules აღწერს ბექენდ კავშირის დანიშნულების პორტის გადაფარვას, შეზღუდულს მხარდაჭერილი წესით, სქემით და ჰოსტის სახელით. პორტის გადაფარვა არ არის ზოგადი რელე თვითნებური UDP-სთვის ან სხვა პროტოკოლებისთვის.
როცა ფრონტენდი ამთავრებს TLS-ს, გადაამოწმეთ ორივე ნაბიჯი: სერტიფიკატი ბრაუზერიდან ფრონტენდამდე და კავშირი ფრონტენდიდან წყარომდე. VPN ნაბიჯი არც ერთ შემოწმებას არ ცვლის, და შიდა მისამართის გადინება გადამისამართებებში ან ქუქიებში ჩვეულებრივი ნიშანია იმისა, რომ ორიდან მხოლოდ ერთი იყო კონფიგურირებული საჯარო სახელის გათვალისწინებით.
შეინარჩუნეთ დაკავშირება ცოცხალი
ზოგი პროვაიდერი ხელახალი დაკავშირების შემდეგ სხვა პორტს ანიჭებს, და იჯარით აღებულმა დაკავშირებამ შეიძლება მოითხოვოს განახლება პროვაიდერის მხრიდან მოქმედებით. მიჰყევით იმ მექანიზმს, რომელსაც თქვენი პროვაიდერი აღწერს, და განაახლეთ მსმენელი, ლოკალური წესები, DNS ან ფრონტენდის წესი მხოლოდ იქ, სადაც მიმდინარე ხელშეკრულება ამას მოითხოვს.
სტატიკური საჯარო მისამართი პორტის იჯარას სტატიკურს არ ხდის. მისამართი და პორტი, რომლებიც ჯერ კიდევ პანელში ჩანს, არ არის მტკიცებულება, რომ აქტიური სესია ფლობს დაკავშირებას, ამიტომ ტესტი გარედან ახალი მოთხოვნაა და არა ეკრანის სურათი.
შემდეგ გაიმეორეთ ის შემთხვევები, რომლებსაც ელით: ჩვეულებრივი ხელახალი დაკავშირება და VPN-ის დაკარგვა. თუ დაკარგვამ წყარო მიუწვდომელი უნდა გახადოს, ნუ მისცემთ განახლების ხელსაწყოს ფონზე ჩუმად ხელახლა გამოაქვეყნოს პირდაპირი ISP გზა. და თუ გადამისამართების ხელშეკრულება ვერ აკმაყოფილებს საიტის სტაბილურობის მოთხოვნებს, აირჩიეთ გამოქვეყნების სხვა წყობა იმის ნაცვლად, რომ კიდევ ერთი მისამართის იარლიყი იყიდოთ და იმედი ჰქონდეთ, რომ სერვერივით მოიქცევა.