Pi-ის hotspot კლიენტები TUN VPN-ით სახლის LAN-ს ვერ აღწევენ

ლოკალური Wi-Fi და Ethernet კლიენტები უკავშირდებიან Pi-ის hotspot-ს, იღებენ მისამართს მისი DHCP დიაპაზონიდან და უჩივლოდ ტვირთავენ ინტერნეტ გვერდებს. შემდეგ იგივე კლიენტებს დრო ეწურებათ, როცა სახლის LAN-ზე ხსნიან ფაილების გაზიარებას ან ვებ ინტერფეისს, მაშინ როცა თავად Pi ამ LAN-ს გვირაბით აღწევს. უსადენო ფენაში არაფერია გატეხილი. აკლია მარშრუტიზებული კონტრაქტი: hotspot-ის პრეფიქსი უნდა გადატანილ იქნას TUN ინტერფეისში და სახლის მხარეს რაღაცამ უნდა იცოდეს, როგორ გააგზავნოს პასუხები იქ დაბრუნებით. ორივე ნახევარი უნდა არსებობდეს, სანამ ერთი პაკეტი შეძლებს ორმხრივი გზის დასრულებას.

სამი შეერთება სამი განსხვავებული საქმით

Linux Ethernet ხიდი კადრებს გადასცემს დანიშნულების MAC მისამართის მიხედვით. OpenVPN TUN რეჟიმში ატარებს IP პაკეტებს და საერთოდ არ აქვს MAC ფენა, ამიტომ ლოკალური ხიდის დამატება გვირაბს პორტად არასოდეს არეგისტრირებს. ბირთვის TUN/TAP დოკუმენტაცია ხსნის ამ განცალკევებას: TAP მოწყობილობა Ethernet ინტერფეისს ჰგავს, TUN მოწყობილობა — არა. დიზაინი, რომელიც ორ ლოკალურ პორტს ხიდავს და შემდეგ მარშრუტიზაციას აკეთებს, როუტერია, რაც არ უნდა თქვან ინტერფეისების სახელებმა.

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

მოდემი კლიენტების ხიდის გარეთაც შეინახეთ. PPP შეერთება სხვა ეტიკეტის Ethernet მოწყობილობა არ არის და pppd-ის დოკუმენტირებული ნაგულისხმევი მარშრუტის ლოგიკა IPCP მოლაპარაკების შემდეგ მუშაობს და თავის მარშრუტს იწევს უკან, როცა ეს კავშირი ვარდება. DHCP შაბლონის კოპირება და ყოველი usb0-ის ppp0-ად გადარქმევა არაფერს ამტკიცებს კარიბჭის, მეტრიკის ან სასიცოცხლო ციკლის შესახებ.

აირჩიეთ პრეფიქსები, სანამ რომელიმე კონფიგურაციას შეცვლით

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

ip -4 addr show scope global
ip -4 route show table main
ip -4 route get 192.168.77.10

პირველი აუზი არის underlay მისამართი, რომელიც ოპერატორმა მოდემს მისცა; ის უნდა დარჩეს ყოველი კლიენტისკენ მიმართული გეგმის გარეთ. მეორე არის გვირაბის ქვექსელი, რომელიც სერვერმა აირჩია, ხშირად მისივე კერძო /24-ქსელი. მესამე არის hotspot-ის ხიდი, ხოლო მეოთხე არის სახლის პრეფიქსი, რომლის მიღწევაც გსურთ. ამ გავლაში hotspot იღებს 172.28.90.0/24-ს ხიდით 172.28.90.1-ზე, და სახლის სერვისის LAN ინარჩუნებს 192.168.77.0/24-ს, რაც გვერდს უვლის მომხმარებლის როუტერების 192.168.1.0/24 და 10.0.0.0/24 ნაგულისხმევებს და ოპერატორის 100.64.0.0/10 დიაპაზონს.

hotspot-ის DHCP დიაპაზონში გამოაცხადეთ მხოლოდ ხიდის მისამართი კარიბჭედ და მეტი არაფერი. არასოდეს მისცეთ hotspot კლიენტებს სახლის მისამართი კარიბჭედ; მათ არ აქვთ ბმულის დონის გზა ამ სეგმენტამდე.

მარშრუტიზაცია გაუკეთეთ თითოეულ მიმართულებას იმ მხარეს, რომელიც მას ფლობს

Pi-ს სჭირდება მარშრუტი სახლის პრეფიქსისთვის გვირაბის გავლით. სერვერები სერვერის რეჟიმში ჩვეულებრივ უბიძგებენ ამ მარშრუტს, ამიტომ ჯერ დაადასტურეთ, რომ გადაცემა ჩართულია და რომ ბირთვი სახლის მისამართს tun0-იდან ხსნის.

sysctl net.ipv4.ip_forward
ip route add 192.168.77.0/24 dev tun0
ip -4 route get 192.168.77.10

თუ ip route get კვლავ underlay ინტერფეისს აცნობს, იქ გაჩერდით; გზის შემდგომი არაფერი ვერ შეაკეთებს არასწორ ძიებას.

სახლის მოწყობილობებს არ აქვთ მარშრუტი 172.28.90.0/24-მდე, ამიტომ მათი პასუხები ნაგულისხმევ კარიბჭეს მიჰყვება და როუტერთან იღუპება. არსებობს ორი მხარდაჭერილი შეკეთება. ან დაამატეთ სტატიკური მარშრუტი სახლის როუტერზე, რომელიც hotspot პრეფიქსს VPN სერვერის LAN მისამართისკენ მიმართავს, ან, როცა სერვერი თავად არის კარიბჭე, დაარეგისტრირეთ კლიენტის პრეფიქსი სერვერის საკუთარ მარშრუტიზაციის ცხრილში. OpenVPN-ის მრავალკლიენტიან რეჟიმში კლიენტის სპეციფიკური დირექტორია ატარებს ამ ასოციაციას: ფაილი, დასახელებული კლიენტის სერტიფიკატის საერთო სახელის მიხედვით, რომელიც შეიცავს iroute 172.28.90.0 255.255.255.0-ს და შესაბამის route ხაზს, რომელიც მას სერვერის ბირთვში აყენებს. სერვერზე გამოცნობილი ბირთვის მარშრუტი არ არის იგივე განაცხადი, რაც სერვერს უთხრა, რომელი კლიენტი ფლობს პრეფიქსს.

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

გახსენით გადაცემა firewall-ის გამოცნობის გარეშე

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

iptables -S FORWARD
iptables -t nat -S POSTROUTING
nft list ruleset

მოძებნეთ მიღების წესი br0-იდან tun0-მდე და შესაბამისი პასუხის მიმართულება, ასევე postrouting წესი, რომელმაც შეიძლება წყარო გადაწეროს. თუ ჯაჭვის პოლიტიკა drop-ია და არც ერთი წესი არ ემთხვევა, დაამატეთ ვიწრო მიღებები და ხელახლა შეამოწმეთ, ნაცვლად იმისა, რომ პოლიტიკა accept-ად აქციოთ.

თარგმნა პოლიტიკის არჩევანია და არა მოთხოვნა. წყაროს NAT სახლის LAN-ისკენ ყოველ hotspot კლიენტს Pi-ის გვირაბის მისამართივით აჩვენებს, რაც კარგავს თითო კლიენტის მიკუთვნებას სახლის ჟურნალებში და ამტვრევს სერვისებს, რომლებიც ორიგინალ წყაროს ელიან. მარშრუტიზაცია NAT-ის გარეშე კლიენტების მისამართებს ხილულად ინახავს, მაგრამ დამოკიდებულია ზემოთ მოცემულ დაბრუნების მარშრუტზე. აირჩიეთ ერთი და DNS-სა და IPv6-ს იგივენაირად მოეპყარით, რადგან გატეხილი IPv6 გზის გვერდით მომუშავე IPv4 გზა ბრაუზერში მაინც ნახევრად გატეხილად იკითხება.

შეამოწმეთ ორმხრივი გზა, შემდეგ განზრახ გატეხეთ იგი

ტესტეთ hotspot კლიენტიდან, არასოდეს Pi-იდან, რადგან თავად Pi-ის ტრაფიკი გვერდს უვლის როგორც წინა, ისე დაბრუნების გზას. დააკვირდით ორივე ინტერფეისს, სანამ ერთი კლიენტი სახლის სერვისამდე მისვლას ცდილობს.

tcpdump -ni br0 host 192.168.77.10
tcpdump -ni tun0 host 192.168.77.10
ping -c 3 192.168.77.10

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

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

მიიღეთ დიზაინი მხოლოდ მაშინ, როცა hotspot კლიენტს შეუძლია სახლის სახელის ამოხსნა, TCP სერვისის გახსნა და სესიის ცოცხლად შენარჩუნება ერთი მოდემის ხელახალი დაკავშირების განმავლობაში. თუ აპლიკაციას ნამდვილად სჭირდება Ethernet დონის აღმოჩენა სახლის სეგმენტზე, აირჩიეთ მხარდაჭერილი Layer 2 დიზაინი იმის ნაცვლად, რომ ლოკალური ხიდი ხიდად აღწეროთ და დაელოდოთ მაუწყებლობის გამოჩენას.