რატომ უვლის როუტერის საკუთარი DNS VPN გვირაბს გვერდს?
კლიენტის მოთხოვნა და როუტერის ზედა დინების მოთხოვნა ორი განსხვავებული ნაკადია. ჩაწერეთ ორივე, აირჩიეთ გადამწყვეტის გასასვლელი და შემდეგ შეამოწმეთ გვირაბის გაწყვეტის შემთხვევა.
კლიენტების მოთხოვნები გვირაბს მიჰყვება, ხოლო როუტერის საკუთარი მოთხოვნები WAN-ით გადის, და ცეცხლის კედლის ის წესი, რომელიც ერთს მართავს, მეორეზე არანაირ გავლენას არ ახდენს. მიზეზი შეცდომა არ არის: გადაცემული მოთხოვნა და მოთხოვნა, რომელსაც თავად როუტერი ქმნის, ორი ცალკე ნაკადია და თითოეული კონფიგურაციის სხვადასხვა ნაწილს ედარება. მხოლოდ კლიენტის ნახევრის ჩაწერა თავდაჯერებულ პასუხს იძლევა იმ გზაზე, რომელსაც მეორე ნახევარი არასდროს იყენებს. გამოსწორება არის როუტერის გადამწყვეტის განზრახ მიმართვა და შემდეგ ორი გზის ცალ-ცალკე შემოწმება.
რომელ ნაკადს ეკუთვნის სინამდვილეში პაკეტების ჩაწერა
ერთი მოთხოვნა ორ გაცვლას მოიცავს. LAN კლიენტი მოთხოვნას უგზავნის როუტერის გადამწყვეტს და ის LAN ინტერფეისზე გადაცემული ტრაფიკის სახით აღწევს, ამიტომ გადაცემული პაკეტებისთვის დაწერილ პოლიტიკურ მარშრუტს ან NAT წესს შეუძლია მას შეესაბამოს. შემდეგ როუტერი ქეშიდან პასუხობს ან, გამოტოვებისას, თავის მოთხოვნას ხსნის ზედა დინების სერვერისკენ.
ამ მეორე მოთხოვნის წყაროც თავად როუტერია და დანიშნულებაც, და პლატფორმა მის გზას სხვა კონფიგურაციის ბლოკიდან ირჩევს. ორივე გაცვლას ერთი და იგივე სახელი აქვს და არც ერთი არ არის მეორის ასლი. ამიტომ LAN მხარეს აღებული ჩანაწერი ამტკიცებს, სად წავიდა კლიენტის პაკეტი და გამავალ პაკეტზე არაფერს ამბობს.
პრაქტიკული შემოწმება ორივე მხარის ერთდროულად დაკვირვებაა. როუტერზე ჩამოთვალეთ გადამწყვეტის სოკეტი, ლოკალურად ჰკითხეთ მას და ჩაწერეთ WAN ინტერფეისი:
sockstat -4 -l | grep :53
dig +short @127.0.0.1 example.com
tcpdump -ni igb0 udp port 53თუ სოკეტების სია loopback ან LAN მისამართზე მიბმულ მსმენელს აჩვენებს, როუტერი ლოკალურად პასუხობს და არა სხვა ჰოსტზე გადასცემს. მაშინ ჩანაწერი აჩვენებს, გამოდის თუ არა მიღებული ზედა დინების მოთხოვნა გვირაბის ინტერფეისით თუ WAN-ით, და ეს არის ის პასუხი, რომელსაც პოლიტიკური მარშრუტის წესი არასდროს მოგვცემდა.
რატომ ვერ ხედავს პოლიტიკური მარშრუტი მეორე მოთხოვნას
ცეცხლის კედლის წესები ინტერფეისის, წყაროს, დანიშნულებისა და პორტის მიმართ იწერება და მოწყობილობაში გამავალი პაკეტებისთვის ფასდება. მოთხოვნა, რომელსაც როუტერი ქმნის, არაფერში არ გადის, რადგან ლოკალური პროცესი მას პირდაპირ მარშრუტიზაციის ცხრილს გადასცემს. პოლიტიკური მარშრუტიზაცია და NAT ამიტომ მხოლოდ გადაცემულ გზაზე ვრცელდება, და სწორედ ამიტომ შეიძლება წესების ნაკრები სრულად გამოიყურებოდეს და მაინც როუტერის DNS გვირაბის გარეთ დატოვოს.
ეს განსხვავება ყოველი firmware გადაწერის შემდეგაც რჩება, რადგან ის პაკეტის გზიდან გამომდინარეობს და არა ფუნქციიდან. ყველაფერი, რასაც მოწყობილობა თავისთვის ქმნის — იქნება ეს გადამწყვეტის მოთხოვნები, დროის სინქრონიზაცია, განახლების შემოწმება თუ პაკეტების სარკეებზე წვდომა — ლოკალური წარმოშობისაა და იმავე ბრმა წერტილში ვარდება. ამიტომაც ლეპტოპიდან გაკეთებული ტესტი როუტერზე არაფერს ამტკიცებს.
სად წყვეტს pfSense-ის გადამწყვეტი თავის ზედა დინების გზას
pfSense ამ გაყოფას თვალსაჩინოს ხდის. კლიენტის ტრაფიკი შეიძლება პოლიტიკური მარშრუტით VPN კარიბჭეში გაატაროს, ხოლო თავად ცეცხლის კედლის ტრაფიკი გადამწყვეტის გამავალ პარამეტრს მიჰყვება და არა LAN წესებს. ვებ ინტერფეისში ეს პარამეტრი Services > DNS Resolver > Outgoing Network Interfaces-ის ქვეშაა, და მისი მნიშვნელობაა ინტერფეისების სია, რომელთა გამოყენებაც გადამწყვეტს ზედა დინების მოთხოვნებისთვის შეუძლია.
იქ გვირაბის ინტერფეისის დასახელება, და მხოლოდ იმ ინტერფეისის, არის ის, რაც როუტერის საკუთარ მოთხოვნებს გვირაბს აყოლებს. ნაგულისხმევზე დატოვებისას გადამწყვეტი მარშრუტიზაციის ცხრილიდან ირჩევს გასასვლელს, რაც ორმაგი WAN ან VPN მქონე ჰოსტზე ხშირად WAN არის.
სხვა firmware-ები იმავე გადაწყვეტილებას სხვა ეტიკეტით აჩვენებენ: წყაროს მისამართზე მიბმული ზედა დინების სერვერების სია, მხოლოდ გადაცემის რეჟიმი ან დოკუმენტირებული მარშრუტის პოლიტიკა. მოსაძებნი პარამეტრი ყოველთვის ის არის, რომელიც ლოკალურად შექმნილი მოთხოვნებისთვის ირჩევს გასასვლელს ან წყაროს. გადამწყვეტის კონფიგურაციის ცნობარი ამ პარამეტრს pfSense-ისთვის აღწერს და შეცვლამდე ღირს წაკითხვა.
აირჩიეთ მარცხის ქცევა პარამეტრამდე
გვირაბის ვარდნისას ორი ქცევაა დასაცავი: ზედა დინების მოთხოვნების შეჩერება, რომ არაფერი გაჟონოს, ან ცნობილ გზაზე დამტკიცებულ გადამწყვეტზე დაბრუნება. ორივე პოლიტიკაა და არც ერთი არ არის ის, რასაც ნაგულისხმევად იღებთ. გადაწყვიტეთ, რომელი სჭირდება ქსელს, სანამ ინტერფეისების სიას შეეხებით.
მარცხისას დახურვა უფრო ადვილი დასაცავია, მაგრამ ის გვირაბის წყვეტას სახელების გადაწყვეტის წყვეტად აქცევს როუტერის უკან ყოველი მოწყობილობისთვის. დაბრუნება ოფისს გამოსადეგად ტოვებს, მაგრამ გვირაბის გარეთ ზედა დინების გაცვლის ფასად, რომელიც განზრახ უნდა იყოს მისაღები და არა შემთხვევით. ჩაწერეთ არჩევანი, რადგან VPN-ის გარეთ გადამწყვეტის მისამართის დამნახველი შემდეგი ადამიანი ამას გაჟონვად წაიკითხავს, თუ შენიშვნა სხვას არ ამბობს. სწორედ ეს შენიშვნა გამოყოფს დოკუმენტირებულ დაბრუნებას შემდეგი კვარტლის მიმოხილვაში აუხსნელი აღმოჩენისგან.
ორი შემთხვევა ართულებს გადაწყვეტილებას. კერძო სახელებს შეიძლება დასჭირდეს შიდა გადამწყვეტი, რომელსაც გვირაბი აღწევს, და საკუთარი დაშიფრული DNS-ის მქონე ბრაუზერს ან აპლიკაციას შეუძლია როუტერი სრულიად გვერდი აუაროს, ამიტომ თქვენ მიერ კონფიგურირებული გადამწყვეტი ყოველთვის არ არის ის, რომელსაც მოცემული აპლიკაცია იყენებს.
შეამოწმეთ ორივე გზა და შედეგები ცალ-ცალკე შეინახეთ
ბრაუზერში ჩატარებული DNS ტესტი ვიწრო კითხვას პასუხობს: რომელი გადამწყვეტები გამოიყენა იმ ბრაუზერმა იმ ტესტის პირობებში. ის ქსელის მოწყობილობებს არ ითვლის და ვერ ხედავს მოთხოვნას, რომელიც როუტერმა თავისთვის შექმნა. მის გამოსავალს ერთ მონაცემად მოეპყარით და არა აუდიტად.
LAN კლიენტიდან სთხოვეთ როუტერს საჯარო სახელი და შემდეგ კერძო, რომელზეც მხოლოდ თქვენი შიდა ზონა უნდა პასუხობდეს. მხოლოდ მეორე მოთხოვნაზე მარცხი სახელების გადაცემაზე მიუთითებს და არა გვირაბზე:
dig @192.168.1.1 example.com
dig @192.168.1.1 intranet.example.lanშემდეგ ჩამოწიეთ გვირაბი და გაიმეორეთ ორივე მოთხოვნა. უარყოფილი პასუხები ნიშნავს, რომ გადამწყვეტი მარცხისას იხურება; წარმატებული პასუხი სათადარიგო გადამწყვეტზე და მის გამოყენებულ გზაზე მიუთითებს. შეადარეთ ეს თქვენ დაწერილ შენიშვნას და იმავე წუთში WAN ინტერფეისზე აღებულ ჩანაწერს.
ჩანაწერში დაკვირვებები ცალ-ცალკე შეინახეთ: კლიენტისა და როუტერის გაცვლა, როუტერისა და ზედა დინების გაცვლა, და კონფიგურაცია, რომელმაც მეორე გადაწყვიტა. მოგვიანებით მარშრუტიზაციის ცვლილება ამ მეორე გაცვლას გააქტიურებს გაფრთხილების გარეშე. პასუხი, რომელიც VPN-ის ბოლო წერტილის გარდა სხვა ადგილიდან მოდის, თავისთავად გაჟონვა არ არის; ის გაჟონვად მხოლოდ მაშინ იქცევა, როცა კონფიგურაციამ ეს გზა შემთხვევით აირჩია.