ვის ენდობით, როცა VPN სერვერს თავად ამუშავებთ

თვითჰოსტინგი ოპერატორის როლს გაძლევთ: პროგრამულ უზრუნველყოფას, კონფიგურაციას, განახლების განრიგს და იმას, რასაც თქვენი სერვისი აღრიცხავს, თქვენ ირჩევთ. რასაც ის არ აკეთებს, არის სხვა მხარეების კავშირიდან მოცილება. თქვენი წვდომის ქსელი კვლავ ატარებს პაკეტებს, ჰოსტინგის პროვაიდერი კვლავ მართავს მანქანას, ამომხსნელი კვლავ პასუხობს მოთხოვნებს და დანიშნულება კვლავ ხედავს მოთხოვნას. იმის ცოდნა, რომელი მათგანი შეცვალეთ სინამდვილეში, მთელი სავარჯიშოა.

ნაბიჯი 1: მხარეების ინვენტარიზაცია

ჩამოთვალეთ ყოველი მხარე რეალურ განლაგებაში: თქვენი მოწყობილობა, ქსელი, რომელსაც უერთდებით, VPN ჰოსტი, DNS ამომხსნელი და დანიშნულების სერვისი. თითოეულისთვის აღნიშნეთ, რას შეიძლება დააკვირდეს და რომელი პარამეტრებით თქვენ მართავთ.

ეს ცხრილი უფრო სასარგებლოა, ვიდრე ნებისმიერი განცხადება ანონიმურობაზე, რადგან აჩვენებს, სად შეიცვალა კონტროლი სინამდვილეში. თქვენ მართავთ ჰოსტის კონფიგურაციას და ჟურნალებს. თქვენ არ მართავთ წვდომის ქსელის ხედს თქვენს კავშირზე და არ მართავთ იმას, რასაც დანიშნულება აღრიცხავს თქვენს ანგარიშზე.

სახლის საბოლოო წერტილისთვის დაფარული ტრაფიკი ჩვეულებრივ გადის იმ სახლის წვდომის კავშირით. გამოსვლის მისამართი, რომელსაც თქვენი დანიშნულება ხედავს, არის შინამეურნეობის მისამართი, რაც ტოპოლოგიის ფაქტია და არა შეცდომა პროგრამაში. თუ სწორედ ეს მისამართი გინდოდათ შეცვლა, სახლის სერვერი ამას ვერ შეძლებს. გჭირდებათ გასასვლელი სხვაგან.

ნაბიჯი 2: ჩაწერეთ, რაც მოიგეთ

შეგიძლიათ გადახედოთ განლაგებულ კონფიგურაციას, გადაწყვიტოთ, რომელ მოწყობილობებს შეუძლიათ შეერთება, დააწესოთ დიაგნოსტიკის პოლიტიკა და აწარმოოთ თქვენ მიერ არჩეული ჩანაწერები. ეს ნამდვილი კონტროლია, როცა მათ ინარჩუნებთ, და ეს არის თვითჰოსტინგის პატიოსანი მიზეზი.

ისინი პირობითიც არიან. გამოუყენებელი ნაგულისხმევი პარამეტრი და შეუმოწმებელი სარეზერვო ასლი არ არის თვისებები, რომლებსაც პროტოკოლი გაძლევთ; ეს განზრახვებია. ჩაწერეთ კონტროლი იმ ტესტთან ერთად, რომელიც მას ამტკიცებს, თორემ ის არ ჩაითვლება.

ნაბიჯი 3: მიიღეთ ტექნიკური მომსახურების სია

სია მოკლე და ულმობელია: დაიცავით ადმინისტრატორის ანგარიში, დაიცავით სერვერის გასაღებები, გასცეთ და გააუქმეთ კლიენტების იდენტობები, შეინახეთ სარეზერვო ასლები, წაშალეთ დაკარგული მოწყობილობები და შეინარჩუნეთ აღდგენის გზა, რომელიც არ არის დამოკიდებული წარუმატებელ გვირაბზე.

გაუქმება ცალკე ხაზს იმსახურებს. მოწყობილობა, რომელიც კონფიგურაციიდან ამოიღეთ, მაგრამ არასოდეს გააუქმეთ, კვლავ ფლობს მოქმედ სარეგისტრაციო მონაცემებს და განსხვავება მხოლოდ მაშინ ჩნდება, როცა ვინმე მათ იყენებს. შეამოწმეთ წაშლა ძველი მასალით დაკავშირების მცდელობით.

სარეზერვო ასლებს იგივე მოპყრობა სჭირდება. აღადგინეთ ერთი სარეზერვო ჰოსტზე და დაადასტურეთ, რომ გვირაბი იმავე იდენტობებით ადის. სარეზერვო ასლი, რომელიც არასოდეს აღადგინეთ, ფაილია და არა აღდგენის გეგმა.

ნაბიჯი 4: თქვით უარი ანონიმურობის დაშვებას

სერვერის მუშაობა თქვენს ბრაუზერს ანონიმურს არ გახდის. საიტები კვლავ იღებენ ანგარიშის ინფორმაციას და ქუქიებს, ხოლო HTTPS იცავს აპლიკაციის მონაცემებს თავის გზაზე გვირაბისგან დამოუკიდებლად.

უფრო დახვეწილი ეფექტიც არსებობს: მისამართი, რომელსაც მხოლოდ თქვენ იყენებთ, შეიძლება გახდეს სტაბილური სიგნალი, რომელიც დაკავშირებულია თქვენს გამოყენებასთან. კომერციული გასასვლელი უცხო ადამიანებთან იზიარება, რაც კონფიდენციალურობისთვის ერთი მხრივ ცუდია და მეორე მხრივ კარგი. თქვენი საკუთარი მისამართი უნიკალურია და ეს აბრუნებს იმ გაცვლას.

თუ მიზანია, რომ თქვენი დაკავშირება რთული იყოს, თვითჰოსტინგმა შეიძლება ეს გააადვილოს და არა გაართულოს. გადაწყვიტეთ, რომელი თვისება გინდათ სინამდვილეში, სანამ ამაზე საღამოს დახარჯავთ. უნიკალურობა ხარჯია და არა უპირატესობა, და ის თვითჰოსტინგის შესახებ უმეტეს ტექსტებში არ ჩნდება. ჩაწერეთ ის ნაბიჯ 1-ის მხარეების ცხრილში და გაცვლა გახდება ხილული.

ნაბიჯი 5: აირჩიეთ ის დასახელებული მიზეზით

საკუთარ ქსელზე პირადი წვდომა, კონფიგურაციის კონტროლი, კონკრეტული მარშრუტიზაციის მოთხოვნა ან პროვაიდერის პოლიტიკისგან დამოუკიდებლობა — ყველა კარგი მიზეზია. ჩაწერეთ ის, რომელიც ეხებათ, და დააპროექტეთ ტესტი, რომელიც აჩვენებდა, რომ ის მუშაობს.

შემდეგ შეამოწმეთ მოსაწყენი ნაწილები: განახლებულია ჰოსტი, გაქრნენ ძველი გასაღებები, შენახვა შეესაბამება თქვენს დოკუმენტაციას და შეგიძლიათ სერვისის აღდგენა ხარვეზის შემდეგ? ეს ოთხი პასუხი ბევრად უკეთ აღწერს ნდობის მოდელს, ვიდრე პროტოკოლის სახელი.

ნაბიჯი 6: დაგეგმეთ გასვლა

წინასწარ გადაწყვიტეთ, როგორ გადახვიდეთ ჰოსტიდან: სად ცხოვრობს კონფიგურაცია, როგორ გაიცემა ხელახლა კლიენტის პროფილები და რა მოუვა შენახულ ჩანაწერებს. გასვლის გეგმის გარეშე თვითდაჰოსტილი სერვისი ხდება დამოკიდებულება, რომელსაც ვერ მოიშორებთ.

AWS-ის საერთო პასუხისმგებლობის მოდელი სასარგებლო შაბლონია AWS-ის გარეთაც, რადგან აიძულებს იმავე კითხვას: რომელი ფენა თქვენია და რომელი სხვას ეკუთვნის. უპასუხეთ მას ნაბიჯ 1-ის ყოველი მხარისთვის და ნდობის მოდელი შეწყვეტს ლოზუნგობას.