pfSense როგორც VPN სერვერი და კლიენტი: ორი გზა, ერთი მარშრუტიზატორი

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

დაასახელეთ ორი როლი, სანამ რომელიმე პარამეტრს შეეხებით

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

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

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

შეინარჩუნეთ სერვერის პასუხები WAN გზაზე

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

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

netstat -rn | head -20
pfctl -sr | grep -i vpn
ifconfig | grep -A3 ovpn

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

ნუ მისცემთ გამავალ გვირაბს საკუთარი ბოლო წერტილის შეჭმის საშუალებას

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

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

netstat -rn | grep -F '198.51.100.10'
traceroute -n 198.51.100.10

აირჩიეთ, რომელი მომხმარებლები მიიღებენ გასასვლელს

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

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

openvpn --config user07.ovpn
curl -sS https://ifconfig.me
curl --interface 10.10.10.1 -sS https://intranet.corp.example/health

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

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

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

გამორთეთ კლიენტის ეგზემპლარი, ნახეთ რას აღწევს ჯერ კიდევ დაკავშირებული მომხმარებელი, შემდეგ ისევ გაუშვით. მოთხოვნა, რომელიც ვადაში არ ჯდება, თქვენ მოთხოვნილი სრული ბლოკირების შედეგია; ის, რომელიც WAN მისამართით პასუხობს, ის დაბრუნებაა, რომელიც არ დააფიქსირეთ. გაიმეორეთ შემოწმება IPv6-ისა და DNS-ისთვის, რადგან IPv4-ისთვის დაწერილი პოლიტიკა AAAA ტრაფიკზე არაფერს ამბობს და რომელიმე გვირაბით გატანილი რეზოლვერი იქიდან პასუხობს, საიდანაც მოთხოვნა ნამდვილად გადის.

pfSsh.php playback svc stop openvpn client 2
curl --max-time 6 -sS https://ifconfig.me
pfSsh.php playback svc start openvpn client 2

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