ხიდიანი VPN ჰოტსპოტი: რომელ ნაგულისხმევ მარშრუტს იყენებს ტელეფონი?
Pi-ის ნაგულისხმევი მარშრუტი ტელეფონის კარიბჭე არ არის. გაყავით ორი გადაწყვეტილება, დააშორეთ uplink ხიდს და გამოსცადეთ lease გვირაბამდე.
თქვენი ხიდიანი ჰოტსპოტის ტელეფონი მისამართსა და კარიბჭეს სადღაც იღებს და ეს Pi-ის ნაგულისხმევი მარშრუტი არ არის. Pi-ის ნაგულისხმევის შეცვლა ცვლის, სად აგზავნის Pi საკუთარ ტრაფიკს. ტელეფონი აგრძელებს იმ კარიბჭის გამოყენებას, რომელიც უთხრეს, და როცა ეს კარიბჭე დისტანციურ LAN-ზეა, მისი ჩარჩოები უბრალოდ გადის ხიდს. ორი მომხმარებელი, ორი გადაწყვეტილება. მათი გაყოფა ხსნის უმეტეს შეტყობინებას ინტერნეტის გარეშე ჰოტსპოტზე, როცა თავად Pi რიგზეა.
ორი მოწყობილობა, ორი განსხვავებული კარიბჭის გადაწყვეტილება
Pi-ს აქვს საკუთარი IP დასტა და საკუთარი ნაგულისხმევი მარშრუტი. ტელეფონს აქვს საკუთარი IP დასტა და საკუთარი ნაგულისხმევი მარშრუტი.
| Consumer | Who chooses its gateway | What carries the traffic |
|---|---|---|
| Phone on the bridged AP | The remote LAN router, delivered in its client configuration | An Ethernet frame toward that router crosses the AP and TAP bridge |
| Pi's encrypted connection | The travel uplink's route toward the VPN peer | The Pi sends its own outer transport packets over the underlay |
ეს ცხრილი მთელი მოდელია. ტელეფონის კარიბჭე დისტანციურ LAN-ზე მდებარე მისამართია და მისი ჩარჩოები მე-2 დონეზე გადაეცემა ამ მარშრუტიზატორს. Pi-ის ნაგულისხმევი მარშრუტი ეხება Pi-ის საკუთარ გარე ტრანსპორტს, რომელმაც VPN პარტნიორამდე მოგზაურობის uplink-ით უნდა მიაღწიოს.
ხიდი ჩარჩოებს გადასცემს, ის პაკეტებს არ მარშრუტიზებს
Linux ხიდი Ethernet ჩარჩოებს დანიშნულების MAC-ით გადასცემს და ეს არის ყველაფერი, რასაც თავის პორტებს შორის აკეთებს. ტელეფონის ჩარჩო, რომელიც დისტანციური მარშრუტიზატორის MAC-ზეა მიმართული, TAP პორტზე გადადის და გვირაბს გადის Pi-ის მარშრუტიზაციის ცხრილის შეხების გარეშე. ამიტომ გატეხილ Pi-ის ნაგულისხმევ მარშრუტს ტელეფონი მუშაობადი შეუნარჩუნებლად დატოვება შეუძლია, და ამიტომ სწორი ვერ შეასწორებს არასწორი კარიბჭის მიღებულ ტელეფონს.
TAP Ethernet ჩარჩოებს ატარებს და შეიძლება იყოს ხიდის პორტი. TUN IP პაკეტებს ატარებს და არ შეიძლება. თუ თქვენმა დიზაინმა ერთი მეორეთი შეცვალა, ხიდი ხიდი არ არის და დანარჩენი აქ არ ვრცელდება.
გადაწყვიტეთ, ვინ ანაწილებს ტელეფონის lease-ს
DHCP-ის მე-3 პარამეტრი მარშრუტიზატორის პარამეტრია და კლიენტს ეუბნება, რომელი კარიბჭე გამოიყენოს თავის ქვექსელში. როცა დისტანციური LAN-ის DHCP სერვერი ერთადერთი გამანაწილებელია, ტელეფონი დისტანციურ კარიბჭეს იღებს და დიზაინი თანმიმდევრულია. როცა მოგზაურობის მხარეს სხვა რამ პირველი პასუხობს, ტელეფონი ლოკალურ კარიბჭეს იღებს, მისი ინტერნეტ ტრაფიკი მოგზაურობის uplink-ით გადის და მის დისტანციურ LAN-ის ტრაფიკს საერთოდ არ აქვს გზა.
გაუშვით ერთი გამანაწილებელი ამ ბროდკასტული დომენისთვის და ჩაწერეთ, რას ანაწილებს.
Pi განსხვავებული შემთხვევაა, მაშინაც კი როცა მისამართს იმავე lease-დან იღებს. გააზრებულად გადაწყვიტეთ, უნდა დააყენოს თუ არა ის მარშრუტები, რომლებსაც lease გვთავაზობს, რადგან იმპორტირებულმა დისტანციურმა ნაგულისხმევმა შეიძლება Pi-ის საკუთარი VPN ტრანსპორტი იმ გვირაბში ჩათრიოს, რომლის ცოცხლად შენარჩუნებასაც ცდილობს. systemd-networkd-ის შემთხვევაში ეს გადაწყვეტილება DHCP განყოფილებაში UseRoutes= არის; dhclient-ის შემთხვევაში ეს მოთხოვნების სიაში routers პარამეტრია.
დააშორეთ uplink ხიდიან LAN-ს
ინტერფეისი, რომელიც Pi-ის გარე VPN კავშირს ატარებს, არ უნდა გახდეს ხიდის პორტი. თუ გახდა, დაშიფრული ტრანსპორტი გაფართოებულ LAN-ში გადადის და გვირაბი საბოლოოდ საკუთარ გარე პაკეტებს ატარებს, რაც ისე ფუჭდება, რომ პაკეტის დაკარგვას ჰგავს და არა მარყუჟს. ასევე ცხადად დააფიქსირეთ AP შესაძლებლობა და ხიდის მხარდაჭერა. station რეჟიმში უსადენო ინტერფეისი ჩვეულებრივ ვერ იქნება ხიდის პორტი, რადგან 802.11 სათაურში ადგილი არ არის ხიდისთვის საჭირო მეორე MAC მისამართისთვის.
განსაზღვრეთ გაფართოებული ბროდკასტული დომენი, ერთი მისამართების გეგმა და ის ჩარჩოების ფილტრაცია, რომელიც ნამდვილად გსურთ. Pi-ზე VPN მსმენელის დაშვება ყველა ხიდიან კლიენტს Pi-ის მართვის სერვისებზე წვდომას არ აძლევს. ეს ცალკე წესებია და მათი ერთად მიჩნევა ის გზაა, რომლითაც ჰოტსპოტი ჩუმად ღია კარად იქცევა.
როცა გატყდება, ოთხი რამ ცალ-ცალკე გამოსცადეთ
როცა ტელეფონი დისტანციურ LAN-ს ვერ აღწევს, ოთხი დაკვირვება ჰყოფს მიზეზებს. შეასრულეთ ისინი ამ რიგით და გაჩერდით პირველ წარუმატებელზე.
ip route show default
bridge link show
ip -4 neigh show dev br0
tcpdump -ni br0 arp or icmpდაიწყეთ lease-ით: აქვს ტელეფონს მისამართი და კარიბჭე დისტანციურ ქვექსელში? შემდეგ შეხედეთ ხიდს და დაადასტურეთ, რომ AP პორტი და TAP პორტი ორივე გადასცემს. შემდეგ წაიკითხეთ მეზობლების ცხრილი, რადგან დისტანციური მარშრუტიზატორის გადაუწყვეტელი ჩანაწერი ნიშნავს, რომ ჩარჩოები გადის და არაფერი პასუხობს. ბოლოს დააკვირდით ჩარჩოებს ხიდზე, სანამ ტელეფონი ping-ს აკეთებს, რაც გეუბნებათ, IP-ის ქვემოთაა საერთოდ ხარვეზი.
დასრულებისას ჩაწერეთ, რომელ მოწყობილობას ეკუთვნის თითოეული ნაგულისხმევი მარშრუტი. დოკუმენტაციის ერთი სტრიქონი ლოკალურ და დისტანციურ გამოსვლას გააზრებულ კლიენტურ გადაწყვეტილებად აქცევს და ხიდის ბმული ღირს მის გვერდით შენახვად.