hostapd და OpenVPN ერთ Pi-ზე: ვის ეკუთვნის ნაგულისხმევი მარშრუტი?

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

ჩამოთვალეთ ინტერფეისები, სანამ რაიმეს შეცვლით

ჩვეული განლაგება უკაბელო რადიოს და სადენიან პორტს br0-ის შიგნით ათავსებს, hostapd-ს ხიდის წინააღმდეგ უშვებს და dnsmasq-იდან იჯარებს ანაწილებს, სანამ OpenVPN კლიენტი ქმნის tun0-ს. შემდეგ სამი ცალკე მოთხოვნა ერთს ჰგავს: წვდომის წერტილის კლიენტებს სჭირდებათ Pi როგორც მათი კარიბჭე, Pi-ს სჭირდება მარშრუტი ინტერნეტში თავის სერვერამდე მისასვლელად, ხიდს კი სჭირდება კარიბჭის მისამართი, რომელსაც ეს კლიენტები გამოიყენებენ.

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

ip -br addr
ip route show
ip link show master br0
bridge link show

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

მიეცით ხიდს ნაგულისხმევი მარშრუტი, რომელიც მას ეკუთვნის

Raspberry Pi OS ხშირად ტოვებს ხიდს ნაგულისხმევი მარშრუტის გარეშე, როცა ხიდი ინტერფეისის ფაილის დაწერის შემდეგ წარმოიქმნა. ბლოკი /etc/dhcpcd.conf-ში უნდა იყოს და უნდა ასახელოს ზედა როუტერი და არა Pi.

interface br0
static ip_address=192.168.50.2/24
static routers=192.168.50.1
static domain_name_servers=192.168.50.1

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

systemctl restart dhcpcd-ის შემდეგ ip route show default-მა ერთხელ უნდა აჩვენოს br0 და სადენიანი პორტიდან დუბლიკატი არ უნდა იყოს. დაადასტურეთ ძებნა და არა ცხრილი, რადგან მოძველებული ჩანაწერი შეიძლება გამარჯვებულის გვერდით იჯდეს: ip -4 route get 203.0.113.10-მა უნდა დაასახელოს br0. ეს მისამართი TEST-NET-3 დოკუმენტაციის დიაპაზონიდანაა, ამიტომ ამის კითხვისას რეალურ სერვერთან ვერ დაეჯახება.

შეაჩერეთ გვირაბი საკუთარი სერვერისკენ გზის მოპარვაში

OpenVPN კლიენტი, რომელიც იღებს redirect-gateway-ს, ითვისებს ნაგულისხმევ მარშრუტს და გვირაბში მიმართავს. ეს სწორია, როცა წვდომის წერტილის ყველა კლიენტმა უნდა გამოიყენოს VPN, და არასწორია, როცა მხოლოდ ზოგიერთმა დანიშნულებამ უნდა. ნებისმიერ შემთხვევაში, Pi-ის საკუთარი კავშირი სერვერთან არ უნდა მოძრაობდეს გვირაბის შიგნით, რომელსაც ის ჯერ კიდევ აშენებს. OpenVPN ამატებს ჰოსტის მარშრუტს დაშორებულ მხარესთან საწყისი კარიბჭის მეშვეობით, როცა ნაგულისხმევს გადამისამართებს, და ეს ზუსტად ის ქცევაა, რომელიც ტრანსპორტს ცოცხლად ინარჩუნებს; თუ ეს მარშრუტი აკლია, გვირაბი იშლება, როგორც კი დამყარდება.

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

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

გადაწყვიტეთ გადაგზავნისა და NAT-ის საკითხი

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

sysctl net.ipv4.ip_forward
sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s 192.168.50.0/24 -o tun0 -j MASQUERADE

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

ჩაწერეთ არჩევანი firewall-ის წესების გვერდით, რადგან დიზაინში უხილავი NAT წესი ექვსი თვის შემდეგ აუხსნელი ხდება. შეინახეთ IPv6 იმავე გადაწყვეტილებაში; მომუშავე IPv4 გზა გატეხილი IPv6 გზის გვერდით ჯერ კიდევ ნახევრად გატეხილად იკითხება ბრაუზერში.

გადაამოწმეთ კლიენტიდან, შემდეგ სუფთად უკან დააბრუნეთ

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

ip -4 route get 203.0.113.10
ping -c 3 -I br0 203.0.113.10

შემდეგ დაადასტურეთ, რომ Pi-ს ჯერ კიდევ აქვს საკუთარი გასასვლელი: ip route get 203.0.113.10-მა უნდა დაასახელოს ქვედა დონის მოწყობილობა და ping -c 3 -I br0 203.0.113.10-მა უნდა უპასუხოს, თუ სერვერი ICMP-ს უშვებს. თუ კლიენტის პირველი ორი ნაბიჯი გაივლის და მესამე ჩავარდება, ხარვეზი გადაგზავნაში ან NAT-შია. თუ მეორე ნაბიჯი ჩავარდება, ხიდი ან DHCP ჯერ არასრულია.

უკუქცევა ერთი ფაილის რედაქტირება და ორი ბრძანებაა: წაშალეთ ბლოკი, გადატვირთეთ dhcpcd და შეცვალეთ ნაგულისხმევი მარშრუტი ცხადად ip route replace default via 192.168.50.1 dev br0-ით. ეს გააკეთეთ ტექნიკური მომსახურების ფანჯრის დახურვამდე და არა შემდეგ, რადგან ნაგულისხმევი მარშრუტის დაკარგული Pi მიუწვდომელია იმ ქსელიდან, რომელსაც მის შესაკეთებლად გამოიყენებდით.