შეუძლიათ თუ არა ორი OpenVPN სერვერის კლიენტებს ერთმანეთამდე მიღწევა?

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

მითი: ერთი ანგარიშების სია, ერთი ქსელი

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

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

მიეცით თითოეულ კარიბჭეს საკუთარი აუზი და ტრანზიტული მისამართი

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

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

დააყენეთ მარშრუტი ორივე მხარეს

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

sysctl net.ipv4.ip_forward
ip route add 10.64.20.0/24 via 172.28.44.2 dev transit0
ip route get 10.64.20.37

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

გაუშვით კლიენტის მარშრუტი მფლობელობის გაყალბების გარეშე

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

push "route 10.64.20.0 255.255.255.0"

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

დაამტკიცეთ ერთი მოთხოვნა და უარყავით მეორე

აირჩიეთ რეალური ოპერაცია, მაგალითად HTTPS 10.64.10.21-ის კლიენტიდან 10.64.20.37-ის სერვისამდე, და დაუშვით ზუსტად ეს ორივე ჰოსტზე. თითოეული ბარიერი იღებს მოთხოვნას შემომავალ მხარეს და თვალთვალის ქვეშ მყოფ პასუხს დაბრუნების მხარეს; დანიშნულების საკუთარ სერვისის პოლიტიკამაც უნდა მიიღოს ის.

iptables -A FORWARD -i tun0 -o transit0 -s 10.64.10.21 -d 10.64.20.37 -p tcp --dport 443 -j ACCEPT
iptables -A FORWARD -i transit0 -o tun0 -d 10.64.10.21 -s 10.64.20.37 -p tcp --sport 443 -m conntrack --ctstate ESTABLISHED -j ACCEPT

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

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