OpenVPN iroute და ბირთვის მარშრუტი: რომელი აკლია?

10.77.20.0/24-ის პაკეტი OpenVPN სერვერზე ორ ცალკე გადაწყვეტილებას იღებს: ოპერაციულმა სისტემამ ის VPN-ინტერფეისს უნდა გადასცეს, და OpenVPN-მა უნდა იცოდეს, რომელი დაკავშირებული კლიენტი ფლობს ამ პრეფიქსს. ბირთვის მარშრუტის არარსებობა მას გვირაბამდე ყრის, ხოლო თანატოლის მარშრუტის არარსებობა — მის შემდეგ. ორივე ჩავარდნა შორეული LAN-იდან ერთნაირად გამოიყურება, და იმის დიაგნოსტიკას, რომელი გაქვთ, თითო ბრძანება სჭირდება ყოველ მხარეს.

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

ორი გადაწყვეტილება, არა ერთი მარშრუტი

წარმოიდგინეთ უბან-უბან კავშირი, სადაც 10.77.20.0/24 ერთი კლიენტის უკანაა. სერვერის ბირთვის მარშრუტი, მაგალითად ip route add 10.77.20.0/24 dev tun0, შესაბამის პაკეტებს გვირაბის მოწყობილობას უგზავნის. შემდეგ OpenVPN თავის შიდა ცხრილს ათვალიერებს, რომელიც კლიენტის კონფიგურაციის საქაღალდეში არსებული iroute ჩანაწერებიდანაა აწყობილი, რათა გადაწყვიტოს, რომელი თანატოლის კავშირი მიიღებს მათ. ბირთვის მარშრუტის გარეშე პაკეტი პროცესამდე არასოდეს აღწევს, ხოლო თანატოლის მარშრუტის გარეშე ის პროცესამდე აღწევს და არსად მიდის.

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

სად უნდა იყოს iroute და რას ამბობს ის

ჩანაწერი მიდის კლიენტის common_name-ის მიხედვით დასახელებულ თითო კლიენტის ფაილში, client-config-dir-ის ქვეშ, როგორც iroute 10.77.20.0/24. ფაილის სახელის დამთხვევა კოსმეტიკური არ არის: OpenVPN ავთენტიფიცირებულ იდენტობას ეძებს და კითხულობს ფაილს ზუსტად ამ სახელით, ამიტომ site-a სახელის ფაილი მოქმედებს მხოლოდ იმ კლიენტზე, რომლის საერთო სახელი site-a არის. დაამატეთ ccd-exclusive, თუ ასეთი ფაილის გარეშე კლიენტები საერთოდ უნდა იქნას უარყოფილი, რაც სწორი პარამეტრია, როცა ყოველი კლიენტი უბნის კარიბჭეა. შეინახეთ ერთი ფაილი თითო კარიბჭეზე და დაარქვით იმ სერთიფიკატის სუბიექტის სახელი, რომელსაც რეალურად გასცემთ.

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

ხაფანგი: ფაილი არსებობს, იდენტობა არასწორია

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

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

დაასრულეთ გზა თანატოლის მიღმა

თანატოლის საკუთრება გზის შუა ნაწილია და არა დასასრული. კლიენტმა პაკეტები გვირაბიდან თავის LAN-ში უნდა გადააგზავნოს, რაც ნიშნავს, რომ ამ ჰოსტზე IP გადაგზავნა ჩართულია და firewall-ის წესი გავლის ნებას იძლევა. შორეული LAN-ის ჰოსტებს გვირაბის მისამართისთვის დაბრუნების გზა სჭირდებათ: ან კარიბჭისკენ მიმართული მარშრუტი, ან კლიენტის მხარეს განზრახ დაპროექტებული NAT. დაადასტურეთ გადაგზავნის პარამეტრი კლიენტზე sysctl net.ipv4.ip_forward-ით, ნაცვლად დისტრიბუტივის ნაგულისხმევი მნიშვნელობის დაშვებისა.

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

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