OpenVPN კლიენტების Cloudflare-ით მარშრუტიზაცია? ჯერ როლი შეამოწმეთ
მოწყობილობის კლიენტი როუტერი არ არის. დაადასტურეთ, რომ Cloudflare-ის როლი სხვა ჰოსტების პაკეტებს გადაამისამართებს, შემდეგ სერვერის საკუთარი გვირაბი ძველ გზაზე დატოვეთ.
გაქვთ მომუშავე OpenVPN სერვერი და ჰოსტი, რომელიც ასევე უშვებს Cloudflare-ის მოწყობილობის პროგრამულ უზრუნველყოფას, და შემდეგი აშკარა ნაბიჯი კლიენტების ტრაფიკის იქით მიმართვად გამოიყურება. ორი მომუშავე კავშირი ერთ მანქანაზე ტრანზიტულ კარიბჭეს არ ქმნის. რაც აკლია, არის სხვის კუთვნილი პაკეტების გადასამისამართებლად დოკუმენტირებული როლი და პოლიტიკა, რომელიც ამ პაკეტებს ჩამოსვლისას ახარისხებს.
ნებისმიერ წესამდე ოთხი კითხვაა: რომელი ტრაფიკი შემოდის, სად მიდის შემდეგ, როგორ პოულობს პასუხები უკანა გზას და რას აკეთებს დიზაინი, როცა ეს მეორე გზა ვერ მუშაობს. პირველი ორი შესაძლებლობის კითხვაა.
ორი სერვისი ერთ ჰოსტზე ტრანზიტული გზა არ არის
მოწყობილობის კლიენტი იმ მანქანაზე წარმოქმნილი ტრაფიკის დასამუშავებლადაა შექმნილი, სადაც თავად მუშაობს. ის იჭერს სახელების გარჩევას ან შერჩეულ აპლიკაციურ ტრაფიკს და საკუთარი გვირაბით აგზავნის, ხოლო მისი პოლიტიკა ამ მოწყობილობის მომხმარებლისა და ამ მოწყობილობის პროცესებისთვისაა დაწერილი. OpenVPN კლიენტიდან გადამისამართებული პაკეტი ლოკალური გამომავალი არ არის, ამიტომ იგივე წესები მას არ ახარისხებს. ეს არ არის კონფიგურაციის ისეთი დეტალი, რომელიც უფრო ფართო წესით დაიფარება, რადგან ის წყვეტს, პროგრამული უზრუნველყოფა საერთოდ ხედავს ამ პაკეტს თუ არა.
ამიტომ დიზაინის კითხვა შესაძლებლობის კითხვაა. ან დაყენებულ პროდუქტს აქვს დოკუმენტირებული როლი, რომელიც სხვა ქსელებისთვის ტრაფიკს გადაამისამართებს, ან ტრანზიტის ფუნქცია სრულიად სხვა ადგილს ეკუთვნის.
Cloudflare-ის რომელ როლს აქვს გადამისამართების უფლება
Cloudflare-ის მოწყობილობის კლიენტი გთავაზობთ რეჟიმებს, რომლებიც მოცულობით განსხვავდება: მხოლოდ სახელების გარჩევა, ტრაფიკი მოწყობილობიდან და ზოგჯერ ორივე. ამ რეჟიმებიდან არცერთი არ აქცევს ჰოსტს როუტერად იმ პირადი დიაპაზონისთვის, რომელიც სხვა გვირაბით მოდის. გამოყოფილი მარშრუტიზაციის როლი ცალკე პროდუქტია საკუთარი კონექტორით, რეგისტრაციითა და ქსელური მოდელით.
| Question | What has to answer it |
|---|---|
| Does the installed product forward packets from other hosts? | A documented routing or connector role, not a device mode |
| Which prefixes does the connector advertise? | Its own configuration and status output |
| Does the server's own transport still take the old path? | ip route get for the endpoint, before and after |
| Do replies return through the same path? | Connection tracking counters on the forward rule |
შეამოწმეთ დაყენებული როლი, სანამ მის გარშემო მარშრუტებს შეადგენთ. წაიკითხეთ, რომელ ინტერფეისს ქმნის კონექტორი, აცხადებს თუ არა კონკრეტულ პრეფიქსებს ან ნაგულისხმევ მარშრუტს და ვრცელდება თუ არა ლოკალური პოლიტიკა გადამისამართებულ პაკეტებზეც, როგორც ლოკალურებზე. თუ მხოლოდ ლოკალური ტრაფიკი მუშავდება, OpenVPN სერვერი ვერ იქნება ტრანზიტის წერტილი, როგორც არ უნდა იყოს დაწერილი თარგმანის წესი.
აქვე უნდა ჩამოყალიბდეს ზუსტად საჯარო გასასვლელის მოთხოვნა. Cloudflare-ის მიერ გადამისამართებული კლიენტური ტრაფიკისთვის მოწოდებული გასასვლელი კონკრეტული გამოყენების შემთხვევაა და ის უნდა დადასტურდეს იმ სერვისის მიმართ, რომელიც რეალურად გაქვთ.
გარე გვირაბი ახალი მარშრუტისგან დამოუკიდებლად შეინარჩუნეთ
იმ წუთს, როცა ახალი ინტერფეისისკენ ნაგულისხმევ მარშრუტს დაამატებთ, სერვერის საკუთარი გამავალი ტრაფიკი მისთვის კონკურენციას იწყებს და ეს მოიცავს OpenVPN კლიენტებისთვის პასუხებს და თქვენს SSH სესიას მანქანასთან. ჩვეულებრივი სიმპტომია გვირაბი, რომელიც დამყარდება და შემდეგ კვდება, ან ადმინისტრატორი, რომელიც გარეთ იკეტება, მაშინ როცა ცვლილება თითქოს იმუშავა. შეადარეთ ip route get საბოლოო წერტილისთვის ცვლილებამდე და შემდეგ, და გამოიყენეთ პოლიტიკაზე დაფუძნებული მარშრუტიზაცია ან ჰოსტის მარშრუტი, რომ სერვერის საკუთარი ტრანსპორტი იქ დარჩეს, სადაც იყო. ეს შედარება თავად მანქანიდან გაუშვით, რადგან სერვერის საკუთარი ხედვა თავის მარშრუტზე არის ის, რაც მნიშვნელოვანია.
სერვერის საჯარო მისამართისთვის გამონაკლისი თავისთავად საკმარისი არ არის, რადგან ყოველი დისტანციური ადმინისტრატორის დაბრუნების გზა განსხვავებული ნაკადია. გადაწყვიტეთ, ამ ნაკადებიდან რომელმა უნდა გადაიტანოს ცვლილება, შემდეგ თითოეული შეამოწმეთ იმის ნაცვლად, რომ ჩათვალოთ, პირველი დანარჩენებს ფარავს.
გადამისამართება და თარგმანი ერთ ნაკადამდე შეზღუდეთ
მიღებული პაკეტები გადამისამართების გზას მიჰყვება და არა ლოკალური გამომავლის გზას, ამიტომ მთავარი წესი forward-კაუჭში ცხოვრობს. სადაც შემდეგ ინტერფეისს თარგმანი სჭირდება, შეზღუდეთ წყარო კლიენტთა აუზით, დანიშნულება დაშვებულით და გასასვლელი იმ ერთი ინტერფეისით. მხოლოდ ინტერფეისზე მიბმული masquerade წესი თავისთავად მარშრუტს არ ირჩევს და სხვა რომელიმე ფილტრს არ აცდენს გადამისამართებას.
მარცხისას დახურვის ქცევა წინასწარ გადაწყვიტეთ, შემდეგ გამოსცადეთ. გააჩერეთ შემდეგი გზა და დაადასტურეთ, რომ კლიენტები კარგავენ განზრახ გასასვლელს და არა ჩუმად უბრუნდებიან ჩვეულებრივ აღმავალ არხს, რადგან ეს არის ის შედეგი, რომელსაც ვერავინ ამჩნევს, ვიდრე ტრაფიკი არასწორი კარიდან გავა. გაიმეორეთ შემოწმება სახელების გარჩევისა და IPv6-ისთვის, რადგან მხოლოდ v4-ის წესების ნაკრები v6 გზას ღიად ტოვებს.
ჩაწერეთ ის ოთხი პასუხი, რომლებზეც შეჩერდით და დაკვირვება, რომელიც თითოეულს ადასტურებს. ტრანზიტული გზა, რომელსაც აღწერთ, არის ის, რომელსაც შემდეგ ინციდენტის განხილვაზე დაიცავთ.