ფილიალის ქვექსელის გატარება მთავარი ოფისის SonicWall ინტერნეტ გასასვლელით

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

დაიწყეთ სელექტორით და არა მარშრუტით

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

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

დაამატეთ ფილიალის პოლიტიკა, შემდეგ დაიცავით მისი რიგი

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

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

დაასრულეთ გზა მთავარ ოფისში

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

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

გადაწყვიტეთ, რას აკეთებს ჯგუფი, როცა გვირაბი ვარდება

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

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

გადაამოწმეთ სამი კლიენტიდან, შემდეგ სუფთად დააბრუნეთ

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

ip -4 route get 203.0.113.10
curl -sS -m 5 -o /dev/null -w "%{http_code}\n" https://example.com
traceroute -n -m 6 203.0.113.10

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

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