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

სიმპტომი: სტუმრები კვლავ WAN-ით გადიან

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

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

ნაბიჯი 1: რეალური სეგმენტი, არა მხოლოდ სახელი

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

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

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

ნაბიჯი 2: აირჩიეთ გვირაბი წყაროს მიხედვით

მარშრუტიზაციის ცხრილები ირჩევა დანიშნულების მიხედვით, ამიტომ წესი „გაგზავნე 0.0.0.0/0 გვირაბში“ ყველას ეხება. პოლიტიკური მარშრუტიზაცია ამატებს მეორე განზომილებას: აირჩიეთ ცხრილი წყაროს მისამართით. Linux-ზე დაფუძნებულ როუტერზე ეს დამატებითი წესი და ცალკე ცხრილია, და რიგითობას მნიშვნელობა აქვს, რადგან პირველი შესაბამისი წესი იმარჯვებს:

ip rule add from 192.168.60.0/24 lookup 100 priority 1000
ip route add default dev wg0 table 100
ip route get 1.1.1.1 from 192.168.60.10

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

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

ნაბიჯი 3: პასუხის გზა და ტრანსლაცია

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

nft add rule ip nat POSTROUTING ip saddr 192.168.60.0/24 oifname "wg0" masquerade

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

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

გამოსცადეთ იზოლაცია, არა მხოლოდ დათვალიერება

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

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

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

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

დაკავშირებული სტატიები