მეორე WAN VPN ჩანაწერი ვერ მუშაობს, ხოლო პირველადი კვლავ მუშაობს

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

ყოველ WAN-ს სჭირდება საკუთარი ჩანაწერის ხელშეკრულება

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

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

შეამოწმეთ, რომ მეორე WAN ნამდვილად პასუხობს

შეამოწმეთ ორივე ხაზის გარედან, და არა შესასვლელის უკან მდგარი მანქანიდან, და შეამოწმეთ ზუსტად ის სახელი, რომელსაც კლიენტის პროფილი იყენებს. TLS მსმენელისთვის სწრაფი შემოწმებაა openssl s_client -connect ADDRESS:443 -servername vpn.example.com -showcerts, რომელიც თქვენი ქსელის გარეთ მდგარი ჰოსტიდან გაშვებულია. გსურთ დასრულებული ხელის ჩამორთმევა, რომლის ჯაჭვიც პროფილში არსებულ სახელს ემთხვევა და არა უბრალოდ TCP პორტი, რომელიც კავშირს იღებს.

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

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

მიჰყევით პასუხს და არა მხოლოდ მოთხოვნას

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

შეამოწმეთ მარშრუტიზაციის გადაწყვეტილება მეორე ჩანაწერიდან წარმოშობილი ტრაფიკისთვის. პასუხი უნდა გავიდეს იმ ინტერფეისიდან, რომელზეც მოთხოვნა მოვიდა, ან სულ მცირე ატაროს მისამართი, რომელსაც შორეული მხარე ამ გზის კუთვნილად მიიღებს. პოლიტიკური მარშრუტიზაციის პლატფორმებზე ეს ნიშნავს შემომავალ ინტერფეისზე ან თარგმნილ წყაროზე მიბმულ წესს, პლუს ყოველ გარე ინტერფეისზე მიბმულ თარგმანის განაცხადს. ჩაწერეთ ერთდროულად ორივე ინტერფეისზე, სანამ კლიენტი უკავშირდება; ISP B-ზე მოსული SYN და ISP A-დან გამავალი SYN-ACK ერთ გაშვებაში წყვეტს საკითხს.

მიეცით კლიენტს მეორე ჩანაწერის გაგების გზა

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

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

ერთი მისამართი ორ პროვაიდერთან სხვა პროდუქტია

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

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

რა შეამოწმოთ შემდეგ

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

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