IP გადაცემის ჩართვა არსებულ GCE VPN კარიბჭეზე

VM შეიქმნა IP გადაცემის გარეშე, ის უკვე ამუშავებს VPN პროგრამულ უზრუნველყოფას, და ინსტინქტი გვკარნახობს, რომ ის თარგიდან ხელახლა ავაწყოთ დროშის ჩართვით. ეს ხელახლა აწყობა ზედმეტია. Compute Engine წარმოადგენს canIpForward-ს როგორც განახლებად თვისებას, და დოკუმენტირებული განახლების გზა მას იყენებს refresh-ით და არა გადატვირთვით. ის, რასაც დროშა რეალურად აკონტროლებს, ვიწროა: მის გარეშე პლატფორმა უგულებელყოფს პაკეტებს, რომლებიც ინსტანსამდე აღწევს, მაგრამ არ არის მიმართული თავად ინსტანსის საკუთარ მისამართზე. კარიბჭე, რომელიც სხვა მანქანების ტრაფიკს გადასცემს, ზუსტად ამას აკეთებს, ამიტომ დროშა ჩართული უნდა იყოს. ყველაფერი ამის შემდეგ სტუმრის კონფიგურაცია და მარშრუტიზაციაა, რომლებსაც დროშა არ ეხება.

რას უშვებს დროშა და რას არა

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

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

წაიკითხეთ მიმდინარე თვისება

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

gcloud compute instances describe VM_NAME --project PROJECT_ID --zone ZONE --format='value(canIpForward)'

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

განაახლეთ არსებული ინსტანსი

Google-ის ინსტანსის თვისებების განახლების პროცედურა გაიტანს მიმდინარე რესურსს, ცვლის თვისებას და წარუდგენს შედეგს. ეს სხვა სამუშაო ნაკადია, ვიდრე შექმნის დროის --can-ip-forward დროშა, და სწორედ ის მუშაობს გაშვებულ VM-ზე.

ჯერ გაიტანეთ განსაზღვრება ლოკალურ ფაილში, და შეინახეთ უცვლელი ასლი შედარებისთვის:

gcloud compute instances export VM_NAME --project PROJECT_ID --zone ZONE --destination=instance.yaml

იმ გატანილ ფაილში დააყენეთ თვისება და სხვა არაფერი შეცვალოთ:

canIpForward: true

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

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

gcloud compute instances update-from-file VM_NAME --project PROJECT_ID --zone ZONE --source=instance.yaml --most-disruptive-allowed-action=NO_EFFECT

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

გამოიყენეთ გადამოწმებული ფაილი refresh-ის შეზღუდვით:

gcloud compute instances update-from-file VM_NAME --project PROJECT_ID --zone ZONE --source=instance.yaml --most-disruptive-allowed-action=REFRESH

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

სტუმარმა მაინც უნდა დაამარშრუტოს პაკეტი

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

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

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

Linux კარიბჭეზე ბირთვის გადაცემა სტუმრის კონფიგურაციის ნაწილია. pfSense მოწყობილობას აქვს საკუთარი ეკვივალენტი, და მასში Linux sysctl ბრძანების კოპირება შესაბამისი ნაბიჯი არ არის.

გადაამოწმეთ იმ კლიენტიდან, რომელსაც წვდომა სჭირდება

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

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

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