იგივე სერვერის IP, ორი გზა: OpenVPN-ის გარე ნაკადის მონიშვნა

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

დაიწყეთ იმ ორი ნაკადით, რომელთა გაყოფაც გსურთ

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

ამ მიმოხილვისთვის ჩათვალეთ კლიენტი 10.90.0.10-ზე tun1-ის გავლით, სერვერის საჯარო მისამართი 198.51.100.25 და ხელუხლებელი მთავარი ცხრილი, რომლის ნაგულისხმევი მარშრუტი ჩვეულებრივ uplink-ზე მიუთითებს. სერვერის მხარემაც უნდა მიიღოს ვებ სერვისი შიდა გზაზე და ტრაფიკი დააბრუნოს გვირაბის წყაროსთან; პაკეტის საჯარო მისამართზე გაგზავნა არ აუქმებს სერვერის მსმენელს ან firewall-ის პოლიტიკას.

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

მონიშნეთ სოკეტი, რომელიც კონვერტს ატარებს

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

mark 42
route-noexec
disable-dco

ათობითი 42 არის თექვსმეტობითი 0x2a და სწორედ თექვსმეტობით ფორმას დაემთხვევა მარშრუტიზაციის წესები. link-options-ის ცნობარი mark-ს აღწერს როგორც რაღაცას, რაც Linux-ზე დაშიფრულ გამავალ პაკეტებს ეხება, ანუ ზუსტად იმ სოკეტს, რომლის გზაც უნდა აკონტროლოთ. მონაცემთა არხის გადმოტვირთვის გამორთვა ამ მაგალითს მომხმარებლის სივრცის გზაზე ტოვებს, სადაც ნიშნის ქცევა აღწერილია.

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

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

დანარჩენი ყველაფერი გაუშვით გვირაბის ცხრილში

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

ip -4 route add default dev tun1 src 10.90.0.10 table 47100
ip -4 rule add priority 20000 lookup main suppress_prefixlength 0
ip -4 rule add priority 20001 not fwmark 0x2a lookup 47100
ip -4 rule add priority 20002 not fwmark 0x2a unreachable

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

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

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

დაუშვით, რომ დაბრუნების გზამ იგივე ნიშანი დაინახოს

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

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

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

დაამტკიცეთ ეს ორი მარშრუტის ძიებით

შეადარეთ, რას წყვეტს ბირთვი ორი კონტექსტისთვის, და წაიკითხეთ dev და src ველები და არა გასვლის სტატუსი:

ip -4 route get 198.51.100.25
ip -4 route get 198.51.100.25 mark 0x2a

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

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