Mac-ის VPN პარამეტრები სერვერს არ უშვებს: სად ცხოვრობს კარიბჭე
Mac-ის VPN ჩანაწერი მხოლოდ გარეთ დარეკვას აკეთებს. სამი კითხვა წყვეტს, გჭირდებათ თუ არა კარიბჭის ჰოსტი, და როგორ დაამტკიცოთ, რომ მსმენელი არსებობს კლიენტებამდე.
macOS-ში VPN-ის სახელს ორი სხვადასხვა საქმე ატარებს, და პარამეტრების პანელი მხოლოდ ერთ მათგანს ეხება. თუ გსურთ, რომ ამ Mac-ის ტრაფიკი პროვაიდერის ან დისტანციური კარიბჭის გავლით გავიდეს, კლიენტის ჩანაწერი საკმარისია. თუ გსურთ სასტუმროს ოთახიდან მიაღწიოთ პრინტერს, NAS-ს ან ადმინის გვერდს თქვენს საშინაო ქსელში, მაშინ რაღაცამ ამ ქსელზე უნდა მიიღოს კავშირები გარედან, და თანამედროვე Mac ნაგულისხმევად ეს რაღაც არ არის. სამი კითხვა წყვეტს, რომელ შემთხვევაში ხართ, და ღირს მათზე პასუხის გაცემა სანამ ველში მისამართს აკრეფთ.
კლიენტის ჩანაწერი ასახელებს დანიშნულებას, არა მსმენელს
macOS Ventura-სა და უფრო ახალ სისტემებში სისტემის პარამეტრები > ქსელი > VPN განყოფილებაში ის ველები, რომლებსაც ძველი ვერსიები ქსელის პარამეტრებში ინახავენ, აღწერენ, როგორ მივაღწიოთ სხვის ბოლო წერტილს: სერვერის მისამართი, დისტანციური ID, ანგარიში ან სერთიფიკატი და სურვილისამებრ მოთხოვნით დაკავშირების წესები. ამ ჩანაწერის შენახვა კავშირს ინახავს თქვენი Mac-ის ქსელურ კონფიგურაციაში. პროცესში არაფერი აკავშირებს პორტს, არ ხსნის მსმენელს და არ არეგისტრირებს დისტანციურ მომხმარებელს.
ამის შემოწმება shell-იდან შეგიძლიათ. იმ Mac-ზე, რომელიც გგონიათ, რომ ემსახურება, გაუშვით sudo lsof -nP -iUDP და მოძებნეთ პორტები, რომლებსაც თქვენი პროტოკოლი იყენებს: 500 და 4500 IKEv2-ისთვის, 1194 OpenVPN-ის ნაგულისხმევისთვის, 51820 WireGuard-ისთვის. მხოლოდ კლიენტი მანქანა აჩვენებს დისტანციურ მისამართსა და პორტზე დაწყობილ სოკეტებს, და არა ველური ბარათის მიბმას, რომელზეც ინტერნეტში ყველაფერი მიაღწევდა. Network Extension-ის შიგნით მოძრავი გვირაბები შეიძლება lsof-ს დაემალოს, ამიტომ ყოველ შემთხვევაში შეამოწმეთ აპლიკაციის სტატუსის პანელი; რასაც ვერ იპოვით, არის ისეთი Apple-ის პარამეტრი, რომელიც ამ Mac-ს კარიბჭედ აქცევს.
სამი კითხვა ჰყოფს ორ როლს
რიგით გაიარეთ ისინი. პირველი ჩვეულებრივ წყვეტს დანარჩენს, ხოლო მესამე არის ადგილი, სადაც Mac-ისთვის სპეციფიკური დაგეგმვის უმეტესობა ცდება.
1. ვინ იწყებს საუბარს? თუ თქვენი Mac გარეთ ირეკავს და მეორე მხარე პასუხობს, კლიენტი გჭირდებათ. თუ ინტერნეტში მყოფმა მოწყობილობებმა შიგნით უნდა დარეკონ თქვენს ქსელამდე მისასვლელად, გჭირდებათ კარიბჭე საჯარო შესასვლელი წერტილით, და Mac შეიძლება დარჩეს იმ კარიბჭის კლიენტად.
2. რა უნდა იყოს ხელმისაწვდომი, სანამ გვირაბი აწეულია? ერთი სერვისი ერთ ჰოსტზე პორტების გადაგზავნის გადაწყვეტილებაა. მთელი ქვექსელი, სახელების გარჩევის ჩათვლით, მარშრუტიზაციისა და DNS-ის გადაწყვეტილებაა, და ის ცვლის იმას, რაც კარიბჭემ უნდა გადასცეს და არა იმას, რასაც კლიენტის ჩანაწერი ამბობს.
3. რომელი OS-ის გამოშვება უშვებს მიმღებ მხარეს? Mac-ებისთვის ამ კითხვას მკაცრი პასუხი აქვს. Apple VPN-ს აღნიშნავს როგორც macOS Server 5.7.1-იდან ამოღებულს, და თავად macOS Server აპლიკაცია 2022 წლის 21 აპრილს შეწყდა; მომსახურების ისტორიის შეტყობინება არის გვერდი, რომელიც უნდა წაიკითხოთ მაშინ, როცა ძველი გაკვეთილი გატარებთ VPN სერვისის იმ მონიშვნის ველში, რომელიც აღარ არსებობს.
როცა პირველი პასუხია „გარედან ვიღაც იწყებს“, შეწყვიტეთ გადამრთველის ძებნა Mac-ის კლიენტის პანელში და გადადით იმ ჰოსტის არჩევაზე, რომელიც გვირაბს დაასრულებს.
სად შეიძლება კარიბჭე სამაგიეროდ იცხოვროს
ოთხი წყობა ფარავს საშინაო და მცირე ოფისის შემთხვევების უმეტესობას. როუტერი ნამდვილი სერვერის რეჟიმით, განსხვავებით სხვა ეტიკეტის მქონე კლიენტის რეჟიმისგან, გვირაბს კიდეზე ამთავრებს და ჰოსტების რაოდენობას დაბლა ინახავს, იმ ფასად, რომ იმ firmware-ის პროტოკოლურ მხარდაჭერას მიბმული ხართ. NAS ან მუდამ ჩართული მინი კომპიუტერი მწარმოებლის სერვერის პაკეტს უშვებს და გიტოვებთ წაკითხვად ჟურნალებს. პატარა ღრუბლოვანი VM გაძლევთ თქვენს მიერ კონტროლირებად საჯარო მისამართს და სახლს მეორე გვირაბით აღწევს. WireGuard-ზე აგებული mesh გადაფარვა, ან თანასწორებს შორის გადამცემი მართული სერვისი, გვერდს უვლის შემომავალი პორტების გადაგზავნას იმით, რომ ორივე ბოლო გარეთ ირეკავს.
ამ არჩევანებს შორის საზღვარი ჩვეულებრივ თქვენი ინტერნეტ კავშირია და არა პროგრამა. თუ ISP გათავსებთ ოპერატორის დონის NAT-ის უკან, როუტერის პორტების გადაგზავნის არც ერთი რაოდენობა არ ქმნის მისაღწევ შესასვლელ წერტილს, და რელეს ან mesh-ის წყობაა პატიოსანი პასუხი. შეადარეთ WAN მისამართი, რომელსაც თქვენი როუტერი იტყობინება, იმ მისამართს, რომელსაც გარე სამყარო ხედავს; თუ ისინი განსხვავდება და როუტერის მნიშვნელობა კერძო ან საერთო დიაპაზონშია, დაგეგმეთ რელეს შემთხვევა.
რომელ ჰოსტსაც აირჩევთ, გადასცეთ ერთი პროტოკოლი ერთ პორტზე და არა დიაპაზონი, და დააშორეთ Mac შემომავალ გზას, გარდა იმ შემთხვევისა, როცა ეს კონკრეტული პროდუქტი ადასტურებს სერვერის როლს თქვენ მიერ გაშვებული macOS-ის გამოშვებისთვის.
დაადასტურეთ როლი სანამ პროფილებს დაურიგებთ
კანდიდატურ კარიბჭეზე დაამტკიცეთ, რომ მსმენელი არსებობს და არ დაეყრდნოთ იმას, რომ ინსტალერმა შექმნა. macOS-ზე ეს ნიშნავს ზემოთ მოცემულ პორტებზე გაფილტრულ sudo lsof -nP -iUDP-ს, და თუ პაკეტების ფილტრის წესები დიზაინის ნაწილია, sudo pfctl -s nat-საც. Linux-ზე ss -lunp იგივე ფაქტებს ბუნდოვნების გარეშე აჩვენებს.
შემდეგ გამოსცადეთ ქსელის გარედან, თავად პროტოკოლის გამოყენებით. Ping ცოტას ამტკიცებს: ICMP ხშირად იფილტრება და UDP 51820-ზე არაფერს ამბობს. კლიენტის ხელის ჩამორთმევა დეტალური ჟურნალით, მობილურ ინტერნეტზე ტელეფონიდან გაშვებული, ყველაზე იაფი ნამდვილი ტესტია, რადგან იმავე გზას გადის, რომელსაც დისტანციური კოლეგა გაივლის.
მხოლოდ ამის შემდეგ შეეხეთ კლიენტის პროფილებს. Mac-ზე scutil --nc list ბეჭდავს იმ VPN სერვისებს, რომლებიც სისტემამ იცის; თუ ახლახან აშენებული კარიბჭე მათ შორის არ არის, თქვენ სხვა მანქანას აწყობთ და არა იმას, რომელიც გამოსცადეთ. თუ ხელის ჩამორთმევა LAN-ზე წარმატდება, მაგრამ გარედან ვერ ხერხდება, ბრალი შემომავალ გზაშია: NAT წესი, პროვაიდერის CGNAT ან კარიბჭის firewall, ამ თანმიმდევრობით.
სანამ რამეს ააშენებთ, ოთხი პუნქტი გადაწყვიტეთ:
- რომელი მხარე იწყებს კავშირს, თქვენი Mac თუ დისტანციური მოწყობილობა.
- უჭერს თუ არა მიმღები ჰოსტის OS-ის გამოშვება და პროდუქტი ნამდვილად სერვერის როლს.
- გაძლევთ თუ არა თქვენი ISP საერთოდ მისაღწევ საჯარო მისამართს.
- რომელ ერთ პორტსა და პროტოკოლს მიიღებს კარიბჭე, და რომელი სერვისი პასუხობს მის უკან.
შემდეგი ნაბიჯი კონკრეტულია: აირჩიეთ კარიბჭის ჰოსტი, გარედან დაადასტურეთ მისი მსმენელი, და მხოლოდ ამის შემდეგ შექმენით Mac-ზე მისკენ მიმართული კლიენტის ჩანაწერი.