ორი სერვისის მისამართი ერთ OpenVPN კლიენტზე: iroute და lo

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

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

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

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

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

დაამატეთ მისამართი კლიენტზე მუდმივად

განათავსეთ სერვისის მისამართი loopback-ზე ჰოსტის პრეფიქსით, რომ ჰოსტმა ის აღიქვას ლოკალურ შეყვანად და არა მისაწვდომ ქვექსელად. ip address add 10.66.0.10/32 dev lo ამას ერთი მისამართისთვის აკეთებს, და ბრძანების გამეორება მეორე მისამართისთვის ორ სერვისს მოდელირებს.

გაუშვით ეს ერთჯერად ტესტად, შემდეგ გადაიტანეთ იმაში, რაც ჰოსტის ქსელურ კონფიგურაციას ფლობს, რადგან გაშვების დროს დამატებული ქრება გადატვირთვისას და დუბლიკატები გროვდება ხელახალი დაკავშირებებს შორის. ქსელის შემდეგ დალაგებული systemd ერთეული ერთი ვარიანტია, ხოლო დისტრიბუციის ქსელის მენეჯერი მეორე. რომელსაც აირჩევთ, მისამართი უნდა არსებობდეს აპლიკაციის დაკავშირებამდე, თორემ სერვისი არასწორ სოკეტზე ამოვა. შეამოწმეთ ip address show dev lo-ით გადატვირთვის შემდეგ და არა ხელით ბრძანების შემდეგ.

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

მოითხოვეთ ის CCD ფაილში, რომელსაც ჰაბი ნამდვილად კითხულობს

სერვერზე საკუთრების დეკლარაცია გადადის კლიენტის ფაილში, რომელსაც ავტორიზებული საერთო სახელი ირჩევს, client-config-dir-ით დასახელებული დირექტორიის შიგნით. ხაზია iroute 10.66.0.10 255.255.255.255, ერთი თითო მისამართზე, და ის ეუბნება სერვერს, რომელი პირმა უნდა მიიღოს ტრაფიკი ამ დანიშნულებისთვის.

ორი დეტალი ჩუმად ამტვრევს ამას. ფაილის სახელი უნდა ემთხვეოდეს სახელს, რომელსაც სერვერი ნამდვილად იყენებს, და ის განსხვავდება, როცა თამაშშია username-as-common-name. და iroute ძალაში შედის მხოლოდ TUN რეჟიმში კლიენტის კონფიგურაციის დირექტორიით, ამიტომ იგივე ხაზი არაფერს აკეთებს ხიდურ განლაგებაში. ხაზები დაამატეთ არსებულ ფაილს და ნუ ჩაანაცვლებთ მას, რადგან მას უკვე შეიძლება ჰქონდეს ფიქსირებული მისამართი ან push ოფციები. OpenVPN 2.6-ის ცნობარი აღწერს როგორც დირექტორიას, ისე საკუთრების დირექტივას.

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

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

შეამოწმეთ შეყვანის პოლიტიკა და პასუხის გზა

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

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

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

გამოსცადეთ მისამართები და საკუთრება ცალ-ცალკე

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

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