როუტერის VPN-ით ერთი მოწყობილობის გატარებას სამი წესი სჭირდება და არა გადამრთველი

როუტერის VPN-ზე თითო მოწყობილობის გადამრთველი არ არსებობს; გადამრთველი, რომელსაც ეძებთ, მალსახმობია, რომელიც თქვენს ნაცვლად პოლიტიკის მარშრუტიზაციის წესებს წერს. როგორც კი ერთი ლეპტოპი, ერთი პორტების დიაპაზონი, ერთი მისამართების სია ან ერთი LAN სეგმენტი უნდა გამოიყენოს გვირაბი, სანამ დანარჩენი ყველაფერი WAN-ზე რჩება, თქვენ ქმნით პოლიტიკურ მარშრუტს და არა რთავთ ფუნქციას. საქმეს სამი მოძრავი ნაწილი აქვს და თითოეული განსხვავებულად ფუჭდება: მონიშნული ცხრილი მარშრუტის გარეშე დუმილს ჰგავს, არასწორ ჯაჭვში დადებული ნიშანი იმას ჰგავს, თითქოს არაფერი მომხდარა, ხოლო დაკარგული NAT წესი გვირაბს ჰგავს, რომელიც უკავშირდება და არაფერს ატარებს. კიდევ ორი ნაწილი იკარგება, რადგან ისინი არასოდეს ჩნდება mangle წესში, და ესენია DNS და IPv6.

მითი: გვირაბი კლიენტის პარამეტრია

როუტერის მხარეს მდებარე VPN კლიენტი ერთ უხეშ საქმეს კარგად აკეთებს: ის 0.0.0.0/0-ს მთავარ მარშრუტიზაციის ცხრილში დებს და გვირაბისკენ მიმართავს. WireGuard ამას AllowedIPs-იდან იღებს, OpenVPN კი სერვერიდან გამოგზავნილი redirect-gateway-იდან, და ორივე ცვლის გზას როუტერის უკან მდგარი ყველა ჰოსტისთვის. AllowedIPs-ის შევიწროება ან route-nopull-ის დამატება ცვლის იმას, რასაც კლიენტი აყენებს. ეს არ ცვლის იმას, ვისზე ვრცელდება ეს დაყენება, რადგან კლიენტი მოწყობილობებს საერთოდ არ ხედავს. ის მხოლოდ პაკეტებს ხედავს.

წყაროთი ან დანიშნულებით შერჩევა მარშრუტიზაციის გადაწყვეტილებაა, ამიტომ ის როუტერის პოლიტიკის ფენას ეკუთვნის — mangle წესი და მეორე ცხრილი RouterOS-ზე, MARK და ip rule OpenWrt-ზე ან DD-WRT-ზე, ან firewall წესი, რომლის კარიბჭეც გვირაბია pfSense-ზე. Netgate-ის WireGuard კლიენტის რეცეპტი არის ის, რაც გამოცნობამდე უნდა წაიკითხოთ, რადგან ამ პლატფორმაზე წესის კარიბჭე, ინტერფეისის მიბმა და გამავალი NAT ჩანაწერი ერთმანეთს უნდა შეეგუოს, სანამ ერთი კლიენტიც კი გამოიყენებს გვირაბს.

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

ნაწილი პირველი: გვირაბი, რომელიც ნაგულისხმევი მარშრუტი არ არის

RouterOS-ზე დაამატეთ კლიენტი ნაგულისხმევი მარშრუტის გარეშე და გვირაბს საკუთარი ცხრილი მიეცით. პირველი მარშრუტი მონიშნული ნაგულისხმევია; მეორე — წარუმატებლობის ნახევარი.

/ip route add dst-address=0.0.0.0/0 gateway=VPN_GATEWAY_IP routing-mark=vpn distance=1
/ip route add dst-address=0.0.0.0/0 type=unreachable routing-mark=vpn distance=2

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

RouterOS 7 ჰყოფს იმას, რაც 6.x-მა ერთად შეინარჩუნა: ცხრილს აცხადებთ /routing table add name=vpn fib-ით, შემდეგ კი მას სახელით მიმართავთ მარშრუტზე და mangle წესში. 6.x-ის ფრაგმენტი, რომელიც routing-mark-ს ჩაწერს ცხრილის განსაზღვრის გარეშე, სუფთად იტვირთება და არაფერს ემთხვევა. მეორე კლასიკაა 0.0.0.0/1-ის ორი ნახევარი, ან ერთ ცხრილში ერთსა და იმავე მანძილზე ორი ნაგულისხმევი: ბირთვი ერთს ირჩევს და ქცევა გადატვირთვის შემდეგ შეიძლება შეიცვალოს.

ნაწილი მეორე: მონიშვნა მარშრუტის ძიებამდე

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

/ip firewall mangle add chain=prerouting src-address=192.168.88.50 action=mark-routing new-routing-mark=vpn
/ip firewall mangle add chain=prerouting dst-address-list=via-vpn action=mark-routing new-routing-mark=vpn
/ip firewall address-list add list=via-vpn address=203.0.113.10

Linux-ის firmware იგივეს აკეთებს netfilter-ის ნიშნით და წესით, რომელიც მონიშნულ პაკეტებს თქვენ მიერ შევსებულ ცხრილში მიმართავს:

iptables -t mangle -A PREROUTING -p tcp --dport 27000:27050 -j MARK --set-mark 0x200
ip route add default dev tun0 table 100
ip rule add fwmark 0x200 table 100

ჯაჭვი სტილის არჩევანი არ არის. როცა პაკეტი FORWARD-ს აღწევს, მარშრუტის ძიება უკვე მოხდა, ამიტომ MARK ან DROP იქ მხოლოდ გადაწერა ან გადაგდება შეუძლია. ნიშანი PREROUTING-ში უნდა მოხვდეს გადამისამართებული ტრაფიკისთვის და OUTPUT-ში როუტერის მიერ წარმოქმნილი ტრაფიკისთვის, სადაც როუტერის DNS, NTP და განახლებების შემოწმება ცხოვრობს. სწორედ ეს გამავალი გზაა ჩვეულებრივი მიზეზი, რატომაც სრულად გვირაბიზებული კონფიგურაცია გაჟონვის ტესტში მაინც ISP-ის resolver-იდან პასუხობს.

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

ნაწილი მესამე: NAT, DNS და LAN-ის გამონაკლისი

გვირაბიდან გამავალ ტრაფიკს სჭირდება წყაროს მისამართი, რომელსაც მოპირდაპირე მხარე უპასუხებს. შეზღუდეთ გარდაქმნა გვირაბის ინტერფეისამდე: out-interface=VPN_NAME RouterOS-ზე, -o tun0 Linux-ზე, შესაბამისი გამავალი NAT ჩანაწერი pfSense-ზე. masquerade წესი ამ შეზღუდვის გარეშე გადაწერს ტრაფიკს, რომლის ხელუხლებლად დატოვებაც გინდოდათ, და სიმპტომია ის, რომ გვირაბის გარეშე დარჩენილი მოწყობილობა კარგავს თავის საჯარო მისამართს.

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

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

როცა წესი ემთხვევა, მაგრამ აპლიკაცია მაინც WAN-ს იყენებს

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

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

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

გადაამოწმეთ ორი მოწყობილობით და გადატვირთვით

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

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

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