რატომ წყვეტს როუტერის ადმინის პანელი პასუხს VPN-ის ცვლილების შემდეგ

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

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

გვირაბი არასოდეს ყოფილა მართვის გზა

გადაგზავნა და შესვლა სხვადასხვა სამუშაოა. „შეუძლია კლიენტს გვირაბით NAS-მდე მიღწევა?“ ეს გადაგზავნის კითხვაა როუტერში გამავალ პაკეტებზე. „შემიძლია როუტერის SSH პორტის გახსნა?“ ეს შესვლის კითხვაა თავად როუტერზე მიმართულ პაკეტებზე. გადაგზავნილი ტრაფიკისთვის დაწერილი გამტარი წესი მეორე კითხვისთვის არაფერს აკეთებს, და ეს არის ყველაზე გავრცელებული მიზეზი, რატომაც გვირაბი, რომელიც ტრაფიკს იდეალურად გადააქვს, მაინც უარყოფს თქვენს ადმინის სეანსს.

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

პირველი ფენა: არსებობს მარშრუტი როუტერის საკუთარ მისამართამდე?

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

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

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

მეორე ფენა: შესვლის პოლიტიკა, არა გადაგზავნის პოლიტიკა

Firewall-ები წესებს აფასებენ იმ ინტერფეისზე, რომელზეც პაკეტი ჩამოდის. pfSense-სა და OPNsense-ში ინტერფეისის ჩანართი და წესების რიგი წყვეტს, დაშვებულია თუ არა ტრაფიკი თავად firewall-ის სერვისებთან; წესი, რომელიც LAN კლიენტებს ინტერნეტში უშვებს, არ არის წესი, რომელიც გვირაბის პარტნიორს ვები ინტერფეისის გახსნის უფლებას აძლევს. firewall4-იან OpenWrt-ში თითოეულ ზონას შესვლის პოლიტიკა აქვს, option input 'ACCEPT' ან 'REJECT', და REJECT შესვლის მქონე ზონაში მდებარე გვირაბის ინტერფეისი უარყოფს მართვის კავშირებს, თანაც აგრძელებს ტრაფიკის გადაგზავნას, თუ გადაგზავნა დაშვებულია.

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

# on the router: bind addresses and the loaded ruleset
ss -ltnp | grep -E ':(22|80|443)\b'         # Linux / OpenWrt
sockstat -4 -l | grep -E ':(22|80|443)\b'   # FreeBSD / pfSense
nft list ruleset | grep -A6 'chain input'    # firewall4
pfctl -sr | head -40                         # pf / pfSense

მესამე ფენა: რამე უსმენს ამ მისამართზე?

სერვისი შეიძლება მუშაობდეს და მაინც მიუწვდომელი იყოს, რადგან ერთ მისამართზე დაბა და თავი. OpenWrt-ის uhttpd-ს /etc/config/uhttpd-ში აშკარა მსმენი ჩანაწერები აქვს, მაგალითად list listen_http '0.0.0.0:80'; აწყობა, რომელიც მხოლოდ LAN მისამართზე იბმება, გვირაბის მისამართზე არაფერს იღებს, და მსმენი ინტერფეისის პარამეტრის მქონე პროდუქტებიც იგივენაირად იქცევიან. ზემოთ მოცემული მსმენი ბრძანებები ამაზე პირდაპირ პასუხობს.

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

VPN ინტერფეისი საზღვარია, არა აღდგენის გზა

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

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

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

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

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

პირველ ცვლილებამდე ოთხი რამ ჩაწერეთ: როგორ მიხვდებით მოწყობილობას, თუ გვირაბი მოკვდება, მაგალითად სერიული კონსოლი, პროვაიდერის კონსოლი ან LAN-ში მდგარი მანქანა; სად გადის ექსპორტში მიმდინარე კონფიგურაცია; რომელ ერთ წესს ან მარშრუტს აპირებთ შეცვლას; და როგორ დააბრუნებთ ზუსტად იმ ელემენტს. OpenWrt-ზე sysupgrade -b /tmp/backup.tar.gz იჭერს კონფიგურაციას, და ცვლილებები uci commit-მდე მოლოდინში რჩება, რაც იაფ გაუქმებას გაძლევთ, თუ დროულად შეამჩნევთ. pfSense კონფიგურაციის ისტორიას ინახავს, და AutoConfigBackup მხოლოდ მაშინ ეხმარება, თუ ის უკვე ჩართული იყო. თუ როუტერი fail-closed წესების კრებულს უშვებს, დაადასტურეთ, რომ თქვენი დაგეგმილი ტექმომსახურების გზა არ არის იმ ტრაფიკის შიგნით, რომელსაც ეს წესი ბლოკავს, და გახსოვდეთ, რომ გადატვირთვა მუდმივ წესებს ხელახლა აყენებს და არა შლის.

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

სწრაფი შემოწმება წასვლამდე:

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