VPN კარიბჭე Raspberry Pi-ზე: ერთი ქსელის ბარათი თუ ცალკე კლიენტის პორტი
Pi-ის ერთი პორტი შერჩეულ კლიენტებს მოემსახურება, ან მეორე პორტი მოწყობილობებს შიგნით ჩაკეტავს. აირჩიეთ სქემა იზოლაციის, უკუქცევის პოლიტიკისა და იმის მიხედვით, ვის ეკუთვნის DNS.
გაქვთ ერთი Pi, ერთი მუშა გამავალი VPN პროფილი და ორი მოწყობილობა, რომლებმაც მის გავლით ინტერნეტს უნდა მიაღწიონ. კითხვა, რომელიც მთელ აწყობას წყვეტს, არ არის რომელ სახელმძღვანელოს მივყვეთ, არამედ ის, რამდენი იზოლაცია გჭირდებათ. ერთი პორტი Pi-ს საშუალებას აძლევს იმ მოწყობილობების გვერდით დადგეს როუტერის LAN-ზე და დამატებითი კარიბჭის როლი შეასრულოს; მეორე პორტი საშუალებას გაძლევთ ისინი სეგმენტში მოათავსოთ, სადაც Pi ერთადერთი გასასვლელია. ამ არჩევანის შემდეგ ყველაფერი — DHCP, firewall-ის მოცულობა, DNS, გათიშვის შემთხვევა — მისგან გამომდინარეობს.
რით განსხვავდება ორი სქემა სინამდვილეში
ორივე ნახაზი მარშრუტიზაციას აკეთებს. განსხვავება იმაშია, კიდევ ვინ დგას კაბელზე და რა ხდება, როცა თქვენი პოლიტიკა არასწორია.
| Layout A: Pi on the ISP LAN | Layout B: dedicated client port | |
|---|---|---|
| Cabling | One Ethernet port, existing switch port | Two interfaces: uplink plus a separate LAN port |
| Can a client bypass the Pi? | Yes, by using the ISP router as its gateway | No, unless the device has another radio or link |
| Who hands out addresses | The ISP router, with a per-client setting or a DHCP option | The Pi, on its own LAN interface only |
| Blast radius of a mistake | Any LAN host, if a rule is too broad | The attached segment |
| Good fit for | One laptop, a console, a temporary test client | Appliances, always-on boxes, untrusted devices |
ნამდვილი ღერძი იზოლაციაა. A სქემა სათათბიროა: მოწყობილობა, რომელიც DHCP-ის მიერ მიცემულ კარიბჭეს უგულებელყოფს და როუტერს ირჩევს, მაინც მუშაობს, ოღონდ დაშიფვრის გარეშე. B სქემა ტოპოლოგიითაა ნაძალადევი, რადგან ასარჩევი სხვა მომდევნო ნაბიჯი არ არსებობს.
A სქემა: Pi როგორც დამატებითი კარიბჭე არსებულ LAN-ზე
დავუშვათ, ISP-ის როუტერი 192.168.50.1-ია, Pi — 192.168.50.2, ხოლო შერჩეული კლიენტები Pi-სკენ მიუთითებენ. მთავარია, რომ ორი სხვადასხვა პაკეტის ნაკადი ერთ კაბელს იზიარებს. კლიენტის შიდა პაკეტი Pi-მდე აღწევს და გვირაბიდან უნდა გავიდეს; Pi-ის საკუთარი დაშიფრული პაკეტი VPN-ის პარტნიორისკენ იმავე კაბელიდან როუტერისკენ უნდა გავიდეს. ისინი საპირისპირო მიმართულებებით მოძრაობენ ერთსა და იმავე ინტერფეისზე და სხვადასხვა მოპყრობა სჭირდებათ.
მიეცით Pi-ს მისი მისამართი დაყენებული ქსელის მენეჯერის მეშვეობით და არა ძველი ინტერფეისის ფაილის რეცეპტით, რომელიც მასთან მოწყობილობისთვის იბრძვის. შემდეგ დააყენეთ კლიენტები: სტატიკური კარიბჭე ერთ მოწყობილობაზე, ან DHCP-ის ჯავშანი, რომელიც 192.168.50.2-ს როუტერად აძლევს. ნუ შეცვლით როუტერის მთელ DHCP დიაპაზონს ორი მოწყობილობის გამო და ნუ ჩათვლით, რომ კლიენტი ამ პარამეტრს პატივს სცემს — შეამოწმეთ.
სისუსტე სტრუქტურულია და არა გამოსწორებადი. ამ სეგმენტის ნებისმიერ კლიენტს შეუძლია 192.168.50.1-ზე მიუთითოს და ღიად გავიდეს, ხოლო მეორე ინტერფეისის ან მობილური რადიოს მქონე მოწყობილობა თქვენს აღსრულების გზას სრულად ტოვებს. თუ ეს წინადადება მოცემული მოწყობილობისთვის მიუღებელია, პასუხი უკვე გაქვთ: გამოიყენეთ B სქემა.
B სქემა: ცალკე პორტი მოწყობილობებს შიგნით ჩაკეტავს
აქ Pi ინარჩუნებს 192.168.50.2-ს აღმავალ კავშირზე 192.168.50.1 კარიბჭით და მეორე ინტერფეისზე იღებს 10.20.0.1/24-ს დაკავშირებული მოწყობილობებისთვის. ახლა Pi ორქსელიანი როუტერია, ხოლო დაკავშირებულ სეგმენტს ზუსტად ერთი გასასვლელი აქვს.
შეამოწმეთ დიაპაზონი ყველა დანარჩენთან ვალდებულების აღებამდე: თავად გვირაბის ქვექსელი, სხვა საიტთაშორისი პრეფიქსები და ყველაფერი, რაც VPN-ით ხელმისაწვდომია. 10.20.0.0/24, რომელიც შორეულ LAN-ს ეჯახება, იმ ნახევრადმომუშავე შედეგს იძლევა, რომლის დიაგნოსტიკა მთელ საღამოს იკავებს. თუ მეორე პორტი USB ადაპტერია, დაადასტურეთ, რომ მხარდაჭერილია, და ჩაამაგრეთ მისი სახელი ქსელის მენეჯერში, რომ გადატვირთვის შემდეგ გადაწყობამ თქვენი LAN მისამართი არ გადაადგილოს.
გაუშვით DHCP მსმენელი მხოლოდ იმ ინტერფეისზე. აღმავალ კავშირზე პასუხისმგებელი სერვერი ISP-ის როუტერს ეჯიბრება და თქვენი სეგმენტის მისამართებს სახლის დანარჩენ ნაწილს აძლევს. მიაბით ის LAN ინტერფეისს, შეზღუდეთ გამოცხადებული დიაპაზონით და Pi-ის საკუთარი მისამართი აუზის გარეთ შეინახეთ.
გადაგზავნა, თარგმანი და მარცხისას დახურვის წესი
ოთხი რამ ხშირად ერთად აღიწერება და ერთი არ არის. გადაგზავნის ჩართვა (net.ipv4.ip_forward=1) მხოლოდ ბირთვს ეუბნება, რომ მას პაკეტები ინტერფეისებს შორის გადაადგილება შეუძლია; თავისთავად ის არაფერს უშვებს და არცერთ გზას არ იძლევა გარანტიას. გასასვლელის არჩევა მარშრუტიზაციის გადაწყვეტილებაა. პაკეტის დაშვება forward ჯაჭვში პოლიტიკის გადაწყვეტილებაა. მისი წყაროს გადაწერა postrouting გადაწყვეტილებაა. აწყობა, რომელიც მხოლოდ პირველს აკეთებს, იმ Pi-ს იძლევა, რომელიც სიამოვნებით გადასცემს კლიენტის ტრაფიკს აღმავალი კავშირიდან გარეთ.
შეზღუდეთ ნებართვა განზრახ წყაროებით და იმ ინტერფეისით, რომელიც ტრაფიკმა უნდა გამოიყენოს, და ჩართეთ დაბრუნების გზა და Pi-ის საკუთარი საჭირო დანიშნულებები. შემდეგ თარგმნეთ გვირაბის გასასვლელზე, თუ პროვაიდერი თქვენს LAN პრეფიქსს თქვენკენ უკან არ მარშრუტიზაციას უკეთებს. nftables-ის სახელმძღვანელო გადაგზავნას, ლოკალურ გამოსავალს და წყაროს თარგმანს ცალკე ოპერაციებად განიხილავს, რაც აქ სწორი აზროვნების მოდელია.
გავრცელებული მარცხი ფიზიკურ ინტერფეისზე ფართო masquerade წესია. მაშინ ტრაფიკი ინტერნეტს ISP-ის გზით აღწევს, მაშინ როცა კლიენტის მხრიდან ის ზუსტად მომუშავე VPN-ს ჰგავს. ეს არაფერს ამტკიცებს. შეინახეთ თარგმანი გამოცხადებულ გასასვლელზე მიბმული და შეინახეთ წესები firewall-ში, რომელსაც ჰოსტი უკვე იყენებს, ნაცვლად იმისა, რომ დაამატოთ კონკურენტი წესების ნაკრები, რომელიც საერთო postrouting ჯაჭვს აცარიელებს.
შემდეგ გაუმკლავდით გვირაბის არარსებობას. ფართო ნაგულისხმევ მარშრუტს რომ აყენებს კლიენტის პროფილი, ეს ასევე ნიშნავს, რომ როცა გვირაბი ცვივა, ჩვეულებრივი ნაგულისხმევი შეიძლება დაბრუნდეს და კლიენტის ტრაფიკი ჩუმად ბრუნდება აღმავალ კავშირზე. იქ, სადაც ღია ტექსტზე უკუქცევა მიუღებელია, forward პოლიტიკამ უნდა უარყოს კლიენტიდან აღმავალ კავშირზე ტრაფიკი პირდაპირ, იმ მდგომარეობაში, როცა VPN მარშრუტი გაქრა. დაწერეთ ეს უარყოფის წესად და არა ვარაუდად. Pi-ის საკუთარი დაშიფრული ტრანსპორტი VPN პარტნიორისკენ ცალკე local-output ნაკადია და დაშვებული უნდა დარჩეს, თორემ გვირაბი ვერასოდეს დაბრუნდება.
DNS-ს და IPv6-ს თავისი პასუხი სჭირდება
თუ კლიენტები Pi-ს რეზოლვერად იყენებენ, ისინი ლოკალურ მსმენელს ხვდებიან და Pi ახალ მოთხოვნას იწყებს. ის აღმავალი მოთხოვნა Pi-ის საკუთარ მარშრუტს მიჰყვება და არა იმ forward წესს, რომელიც კლიენტებისთვის დაწერეთ, ამიტომ მხოლოდ გვირაბით მიმავალი კლიენტის გზა პლუს პირდაპირ გარეთ გამავალი რეზოლვერი არის გაჟონვა ყოველგვარი შეცდომის შეტყობინების გარეშე. გადაწყვიტეთ განზრახ: გვირაბით ხელმისაწვდომი რეზოლვერი, თუ ლოკალური, რომელსაც პირდაპირად მიიღებთ, და Pi-ის საკუთარი გამოსვლის პოლიტიკა ამ გადაწყვეტილებას შეუსაბამეთ.
IPv6 კვლავ ცალკე შემთხვევაა. IPv4-ის forward წესი IPv6-თან დაკავშირებით არაფერს ზღუდავს, ხოლო აღმავალ კავშირზე როუტერის განცხადებებმა შეიძლება Pi-ს და მის გავლით დაკავშირებულ სეგმენტს მისცეს მეორე ნაგულისხმევი, რომელიც თქვენს პოლიტიკას გვერდს უვლის. ან იმავე პრინციპით IPv6-ს მისცეთ საკუთარი დაცული გზა, ან ღიად შეზღუდეთ ის კლიენტის სეგმენტზე და თქვით ეს.
სანამ ენდობით, გამოსცადეთ საზღვარი
მიიღეთ ნახაზი მხოლოდ ოთხი ცალკე შემოწმების შემდეგ, რადგან ცდუნებამოწვევი ერთადერთი ტესტი — ბრაუზერის გახსნა ერთ კლიენტზე — რამდენიმე გატეხილ მდგომარეობაში გადის.
დაადასტურეთ, რომ ერთი რეალური კლიენტი ინტერნეტს გვირაბით აღწევს, შემდეგ დაადასტურეთ, რომ იგივე კლიენტი გვირაბის ჩამოშლისას ინტერნეტს ვერ აღწევს. დაადასტურეთ, რომ DNS ამოხსნა მუშაობს და მოთხოვნა იქიდან გადის, სადაც განიზრახეთ. დაადასტურეთ, რომ Pi-ის საკუთარი ტრანსპორტი გვირაბის გადატვირთვის შემდეგაც მუშაობს და აღდგენას მანქანის გადატვირთვა არ სჭირდება. ბოლოს შეამოწმეთ მოწყობილობა, რომელიც არ აგირჩევიათ: A სქემაში ის ჩვეულებრივ უნდა განაგრძოს მუშაობა, ხოლო B სქემაში ის საერთოდ არ უნდა არსებობდეს ამ სეგმენტზე.
- ორი პორტი და უარყოფის წესი აღსრულებას იძლევა; ერთი პორტი და DHCP პარამეტრი რჩევას იძლევა.
- თარგმანი არასწორ ინტერფეისზე წარმატებას ჰგავს და არც არის.
- Pi-ის საკუთარი ტრაფიკი, DNS და IPv6 თითოეული გადაწყვეტილებას მოითხოვს და არა დასკვნას.