VPN VPC-ში მუშაობს, მაგრამ მართული სერვისი დროში იწურება
გვირაბი თქვენს კიდეზე მთავრდება და არა პროვაიდერის შესასვლელ კართან. სანამ მარშრუტს შეცვლით, სამიზნე დაახარისხეთ როგორც VM-ზე განლაგებული, VPC-ზე მიმაგრებული ან მხოლოდ საჯარო.
მართულ მონაცემთა ბაზაზე VPN-ით მიღწევა ჩვეულებრივ იმ მიზეზით ვერ ხერხდება, რომელიც არავის ჩაუწერია სახელმძღვანელოში: გვირაბი თქვენი ქსელის კიდეზე მთავრდება, სერვისი კი არასდროს ყოფილა მის თქვენს მხარეს. მარშრუტების ცხრილი სწორად გამოიყურება, გვირაბი აქტიურობას აცხადებს და კავშირი მაინც დროში იწურება. შეასრულეთ ქვემოთ მოცემული ოთხი შემოწმება თანმიმდევრობით და გაჩერდით პირველზე, რომლის წარმატების პირობაც არ სრულდება, რადგან მის შემდეგ ყოველი შემოწმება ვარაუდობს, რომ წინები გაიარა.
შემოწმება პირველი: სად ცხოვრობს სინამდვილეში საბოლოო წერტილი?
VPN კარიბჭე აერთიანებს ორ ქსელს, რომელთა მისამართებსაც თქვენ აკონტროლებთ. მართული სერვისი პროვაიდერის საკუთარი შესასვლელი კარის უკან მუშაობს და ეს კარი პროდუქტის მიხედვით სამი ფორმიდან ერთს იღებს. თუ არ იცით, რომელ ფორმასთან გაქვთ საქმე, ვერც ერთი მარშრუტული სამუშაო ვერ დაგეხმარებათ, რადგან ხარვეზი შეიძლება საერთოდ არ იყოს მარშრუტის ხარვეზი.
| Shape | What it means | Pass condition |
|---|---|---|
| Software on your VM | Ordinary subnet addressing | Route and security group permit the client |
| Attached to your VPC | Private, but only inside that VPC | Endpoint associated, source allowed, route present |
| Provider-hosted, public endpoint | Optional private link, not private by default | A private endpoint exists and DNS points at it |
დაკარგული შუადღეების უმეტესობა ამ კლასიფიკაციის გამოტოვებით და პირდაპირ მარშრუტების ცხრილზე გადასვლით მიიღება. პროვაიდერთან განლაგებული საჯარო საბოლოო წერტილის მქონე სერვისი თქვენი გვირაბის უკან არ არის, რაც არ უნდა თქვას დიაგრამამ, ხოლო VPC-ზე მიმაგრებული საჯარო DNS პასუხში არასდროს გამოჩნდება.
შემოწმება მეორე: VPC-ზე მიმაგრებული სერვისი, მაგალითად ElastiCache
ამ ტიპის ქეშები თქვენივე VPC-ის შიგნით მისამართდება და საერთოდ არ აქვთ ინტერნეტისკენ მიმართული მსმენელი. იმავე VPC-ში დასრულებულ კლიენტურ VPN-ს შეუძლია მათზე მიღწევა, მაგრამ მხოლოდ მაშინ, როცა სამი პირობა ერთდროულად დაემთხვევა. ქეშის საბოლოო წერტილი უნდა იყოს დაკავშირებული ქვექსელებთან, რომლებსაც თქვენი გვირაბი ხედავს, მისი უსაფრთხოების ჯგუფი უნდა უშვებდეს იმ მისამართს, საიდანაც თქვენი კლიენტები მოდიან, და კლიენტის მხარეს სჭირდება მარშრუტი, რომელიც ფარავს ქეშის ქვექსელებს.
გავრცელებული შეცდომაა ვივარაუდოთ, რომ სადღაც ახლოს არსებული კავშირი ითვლება. VPN-ის სხვა VPC-ზე მიმაგრება ან მხოლოდ peering-ზე დაყრდნობა არ ავრცელებს ქეშის უსაფრთხოების ჯგუფს ან მისი ქვექსელის მარშრუტების ცხრილს თქვენს კლიენტებზე. როცა არსებული გვირაბი სხვაგან მთავრდება, ჩვეულებრივი სარეზერვო გამოსავალია გადახტომის ჰოსტი ან იმ VPC-ის შიგნით განთავსებული VPN სერვერი. ასეთი სარეზერვო გამოსავალი შემოვლითი გზაა და არა დიზაინი, და სახელმძღვანელოში ისე უნდა აღინიშნოს.
შემოწმება მესამე: PaaS საბოლოო წერტილი საჯარო სახელით
Azure Database for PostgreSQL წარმოადგენს საჯარო სერვერის სახელს. ის არ გაძლევთ პირად მისამართს, რომელსაც hosts ფაილში ჩაამაგრებთ და კარიბჭის გავლით გაამარშრუტებთ. ვირტუალური ქსელის სერვისის საბოლოო წერტილები ზღუდავს, რომელ ქვექსელებს შეუძლიათ რესურსზე მიღწევა; ისინი არ ანიჭებენ უფლებას VPN-ით მოსულ ლოკალურ კლიენტს.
პირადი წვდომის მიღება ნიშნავს პირადი საბოლოო წერტილის ან პირადი კავშირის დიზაინის შემოღებას, შემდეგ პირადი DNS ზონის დამატებას, რათა საჯარო სახელი ინტერნეტის ნაცვლად იმ წერტილით უპასუხოს. VPN სერვისის საბოლოო წერტილის წესთან ერთად სხვა არქიტექტურაა, რომელიც მხოლოდ დიაგრამაზე გამოიყურება მსგავსად. App Service იგივე ლოგიკას საპირისპირო მიმართულებით მიჰყვება: VNet ინტეგრაცია აპლიკაციას საშუალებას აძლევს გააკეთოს გამავალი ზარები VNet-ში და არ ქმნის თქვენი გვირაბიდან შემომავალ პირად გზას. ამიტომ შემომავალი პირადი წვდომა მოითხოვს პირად საბოლოო წერტილს, App Service გარემოს ან აპლიკაციის წინ განთავსებულ კარიბჭეს, და რომელი მათგანი შეგიძლიათ გამოიყენოთ, გეგმაზეა დამოკიდებული.
შემოწმება მეოთხე: პროდუქტები საკუთარი შესასვლელი კარით
Firebase Hosting ვერ დაუკავშირდება Cloud VPN-ს, რადგან ჰოსტინგის ფენა გლობალური წინა ნაწილია და არა რაღაც პროექტის VPC-ის შიგნით. დოკუმენტირებული ალტერნატივაა კონტროლირებადი შესვლის წერტილი თავად ააშენოთ, პროქსი ინსტანსით ან თაიგულით დაფუძნებული დატვირთვის გამანაწილებლით. ნებისმიერ შემთხვევაში საიტი წყვეტს წმინდა ჰოსტინგ პროდუქტობას და ხდება ინფრასტრუქტურა, რომელსაც ახლა თქვენ მართავთ. ღირს ამ გაცვლის დასახელება მანამ, სანამ ვინმე დაჰპირდება, რომ გვირაბი მას დაფარავს.
Private API Gateway VPC სერვისების მხარეს უფრო ახლოს დგას: interface ტიპის VPC საბოლოო წერტილი აქვეყნებს ჰოსტის სახელს, რომლის პასუხებიც პირადი მისამართებია, და თქვენი ობიექტიდან ტრაფიკი გვირაბით ან გამოყოფილი ურთიერთკავშირით მოდის. საბოლოო წერტილი API-ზე უნდა იყოს მიმაგრებული, ხოლო სერტიფიკატი და ჰოსტის სახელი უნდა შეესაბამებოდეს იმ მორგებულ დომენს, რომელსაც გამომძახებლები იყენებენ.
Google Cloud VPN გვირაბები პარტნიორ IP მისამართებზე იკავშირებენ, არა სახელებზე. DNS გადაგზავნა ცალკე კონფიგურირდება, ამიტომ გვირაბი შეიძლება სრულიად ჯანმრთელი იყოს, მაშინ როცა შორეულ პირად ზონაში ძიებები კვლავ ვერ ხერხდება.
შემდეგ იპოვეთ საზღვარი
გაუშვით იგივე კავშირი VPC-ის შიგნით არსებული VM-იდან. როცა იქ წარმატდება, VPN კლიენტიდან კი ვერ ხერხდება, სხვაობა კლიენტის გზასა და სერვისის საბოლოო წერტილს შორისაა: მარშრუტი, უსაფრთხოების ჯგუფი, საბოლოო წერტილის პოლიტიკა ან სახელი. როცა ორივე ცდა ვერ ხერხდება, ამ ქსელში ვერაფერი ვერ აღწევს სერვისამდე და VPN არასდროს ყოფილა დაბრკოლება.
getent hosts db.internal.example
nc -vz db.internal.example 5432სახელის ძიება და პორტის შემოწმება ცალ-ცალკე შეასრულეთ, რადგან ისინი სხვადასხვა მიზეზით ვერ ხერხდება და წყვილი გეუბნებათ, გზის რომელი ნახევარია გატეხილი. საჯარო მისამართად გადაქცეული სახელი გეუბნებათ, რომ პირადი DNS ზონა მოქმედებაში არ არის.