ერთი Pi, ორი OpenVPN ინსტანცია: რას კითხულობს თითოეული ერთეული
ორი OpenVPN დემონი ერთ Pi-ზე სხვადასხვა კონფიგურაციის ფაილს კითხულობს და სხვადასხვა hook-იდან გადის. ასახე თითოეული ინსტანცია, შემდეგ payload-ის გზა ცალკე შეამოწმე.
დათვალე OpenVPN პროცესები, სანამ პროფილს შეეხები. Pi, რომელიც roaming მომხმარებლებს იღებს და ამავე დროს upstream სერვისს უკავშირდება, ორ დემონს უშვებს და თითოეული მათგანი კითხულობს კონფიგურაციის ფაილს, რომელსაც შენ მიერ აკრეფილი ინსტანციის სახელი ირჩევს. პაკეტის შაბლონები შემდეგ თითოეულ დემონს აძლევს საკუთარ სამუშაო დირექტორიას, საკუთარ runtime სტატუსის ფაილს და საკუთარ tunnel მოწყობილობას. თუ ეს გაყოფა არასწორია, საღამოს დახარჯავ იმაზე, რომ სწორ პარამეტრს შეცვლი ფაილში, რომელსაც მომუშავე პროცესი არასოდეს ხსნის.
თითოეული ინსტანციის სახელი თავის ფაილს ირჩევს
OpenVPN 2.6-თან მოწოდებულ unit ფაილებში გაშვების არგუმენტები შეიცავს ინსტანციის placeholder-ს, რომელიც ივსება @ ნიშნის შემდეგ არსებული ტექსტით. სერვერის შაბლონი მუშაობს სერვერის კონფიგურაციის დირექტორიიდან და თავის არგუმენტს იქ არსებულ %i.conf-ზე ხსნის, კლიენტის შაბლონი კი იგივეს აკეთებს კლიენტის დირექტორიიდან. ასე რომ, [email protected] კითხულობს admits.conf-ს სერვერის დირექტორიაში, ხოლო [email protected] კითხულობს uplink.conf-ს კლიენტის დირექტორიაში, და არც ერთ სახელს მეორე დირექტორიაში არავითარი მნიშვნელობა არ აქვს.
დაადასტურე ეს დამთხვევა მანქანაზე და ნუ ჩათვლი, რომ პაკეტმა upstream-ის ნაგულისხმევები შეინარჩუნა. დისტრიბუტივის drop-in-ს უფლება აქვს მთლიანად შეცვალოს სამუშაო დირექტორია ან კონფიგურაციის არგუმენტი.
systemctl cat [email protected]
systemctl cat [email protected]წაიკითხე WorkingDirectory ხაზი და კონფიგურაციის არგუმენტი იმ გამოსავალში, რადგან გააქტიურებული unit ერთადერთია, რაც წყვეტს რომელი ფაილი ჩაიტვირთება. drop-in, რომელიც ExecStart-ს --config-ს უმატებს, შაბლონზე იმარჯვებს მაშინაც, როცა შაბლონის გზა სწორად გამოიყურება. მოითხოვე fragment-ისა და drop-in-ის გზები, როცა გინდა იცოდე, მოქმედებს თუ არა ლოკალური გადაფარვა. თუ ორივე როლი ერთ ფაილზე იშლება, გყავს ერთი პროცესი, რომელიც ცდილობს იყოს სერვერიც და კლიენტიც, და ამ ფაილში უფრო გვიან მდგარი ოფცია ჩუმად იმარჯვებს.
ლოკალური ტრანსპორტი და გადამისამართებული payload სხვადასხვა hook-ს ხვდება
სერვერის დაშიფრული კავშირი თითოეულ roaming მომხმარებელთან თავად Pi-ზე იქმნება, ამიტომ მისი გარე პასუხები ლოკალური output hook-იდან გადის. კლიენტის კავშირი upstream peer-თან ასევე ლოკალურად შექმნილი output-ია, თუმცა ის დისტანციურ ქსელს აღწევს. გადამისამართებული payload მესამე კატეგორიაა და ბირთვი მას მხოლოდ მას შემდეგ ადარებს, რაც უკვე აირჩია პაკეტისთვის გამავალი მოწყობილობა.
| Flow | Hook that sees it | What to inspect |
|---|---|---|
| Roaming user handshakes to the server | Local input and local output | Listener socket, bind address, rule admitting the UDP port |
| User payload leaving through the upstream tunnel | Forward | IPv4 forwarding switch, selected route, permission rule, any translation |
| Pi's own connection to the upstream peer | Local output | Underlay route to the provider endpoint, not the tunnel route |
წესი, რომელიც forward ჯაჭვში გამავალ ინტერფეისს ემთხვევა, შეუძლია დაუშვას ან ჩამოაგდოს პაკეტი, რომელიც მარშრუტიზაციამ უკვე ამ ინტერფეისს მიაკუთვნა, მაგრამ ის არასოდეს ირჩევს ინტერფეისს. როცა ერთი ჰოსტი ამთავრებს ერთ tunnel-ს და იწყებს მეორეს, პოლიტიკა, რომელიც მომხმარებლის payload-ს upstream tunnel-ში აგზავნის, და პოლიტიკა, რომელიც Pi-ის საკუთარ დაშიფრულ პასუხებს იცავს, ორი ცალკე გადაწყვეტილებაა. ისინი შემთხვევით ერთსა და იმავე ფიზიკურ NIC-ზე ხვდებიან, ამიტომაც ერევათ ერთმანეთში.
ეს განსხვავება ხსნის ხშირ ნახევრად წარუმატებლობას. მომხმარებლები უკავშირდებიან, handshake სრულდება და მათი ტრაფიკი მაინც არასწორი გზით გადის, რადგან handshake ლოკალური იყო, payload კი forward და ორიდან მხოლოდ ერთი შემოწმდა.
იმპორტირებულმა მარშრუტმა შეიძლება შენი მომხმარებლებისთვის პასუხები გადაყლაპოს
კლიენტის პროფილის უსაფრთხოების პარამეტრი წყვეტს, რისი გაგზავნა შეუძლია upstream-ს Pi-ის მარშრუტიზაციის ცხრილში, და ფართო redirect არის ის ოფცია, რომელიც მომუშავე ორროლურ ჰოსტს გატეხილად აქცევს. თუ გაგზავნილი მარშრუტი ფარავს roaming მომხმარებლების საჯარო მისამართებს, სერვერის მიერ მათკენ გენერირებული პასუხები შეიძლება ახალ მარშრუტს გაჰყვეს upstream tunnel-ში, ნაცვლად იმისა, რომ underlay-იდან გავიდეს. ადამიანები ხშირად ადასტურებენ, რომ პროვაიდერისკენ tunnel ჯერ კიდევ მუშაობს, და იქ წყვეტენ, რადგან ეს ტრაფიკი თავად tunnel-ის ტრანსპორტია და განაგრძობს დინებას, სანამ დანარჩენი ყველაფერი არასწორად იქცევა.
წყაროზე ან mark-ზე დაფუძნებული პოლიტიკა არის გზა, რომ ორი ნაკადი ერთმანეთისგან განცალკევდეს. OpenVPN-ის Linux mark ოფცია დემონის საკუთარ დაშიფრულ პაკეტებს firewall mark-ს აძლევს, რომელსაც მარშრუტიზაციის წესი შემდეგ გამოყოფილ ცხრილში აგზავნის. წყაროს მისამართებიც თანაბრად კარგად მუშაობს, როცა სერვერის გარე პასუხები ყოველთვის ერთი underlay მისამართიდან გადის. ორივე მიდგომას სჭირდება ვალიდური მარშრუტები არჩეულ ცხრილში და გამონაკლისი პროვაიდერის endpoint-ისთვის, თორემ თავად tunnel აღარ ადის.
სანამ რომელიმე წესს დაწერ, ჰკითხე ბირთვს, რომელ გზას გაივლის პასუხი სინამდვილეში. ქვემოთ მოცემული მისამართები placeholder-ებია Pi-ის underlay მისამართისა და ერთი roaming მომხმარებლის საჯარო მისამართისთვის.
ip rule show
ip route get 198.51.100.7 from 192.0.2.10შეამოწმე გაყოფა, შემდეგ თითო როლი ცალ-ცალკე გააჩერე
სამი ნაკადი ცალკე შეამოწმე, რადგან წარმატებული handshake დანარჩენ ორზე არაფერს ამტკიცებს. მიიღე ახალი შემავალი კავშირი, გაუშვი ერთი დაშვებული აპლიკაცია upstream-ის გასასვლელში და დაადასტურე, რომ ორივე პროცესი კვლავ აღწევს თავის peer-ს.
შემდეგ გააჩერე კლიენტის როლი და დააკვირდი, რას ინარჩუნებს სერვერის როლი. ეს არის ყველაზე იაფი გზა იმის აღმოსაჩენად, რომ მარშრუტის ან mark-ის წესი ერთი ინსტანციისთვის იყო განკუთვნილი და ორივეზე გავრცელდა.
systemctl stop [email protected]
systemctl status [email protected] --no-pager
ss -lunp | grep openvpn
journalctl -u [email protected] -n 20 --no-pagerრისი ნახვაც გინდა, არის ეს: listener კვლავ მიბმულია, tunnel მოწყობილობა კვლავ არსებობს და ლოგი თავისუფალია ახალი შეცდომებისგან, სანამ კლიენტის როლი გაჩერებულია. თუ კლიენტის გაჩერება ასევე წყვეტს სერვერის პასუხებს არსებულ მომხმარებლებზე, ორი როლი იზიარებს რაღაცას, რაც ერთ-ერთ მათგანზე უნდა ყოფილიყო შემოსაზღვრული. ჩაწერე, რომელ ინსტანციას, რომელ კონფიგურაციის ფაილს და რომელ ნაკადის მფლობელს შეეხო თითოეული ცვლილება, თორემ შემდეგი ადამიანი, ვინც ამ ჰოსტს დაახარვეზებს, იგივე აღმოჩენას ნულიდან გაიმეორებს.