VPN კლიენტები და LAN: როდის გამოვიყენოთ ცალკე ზონა

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

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

რას აკონტროლებს სინამდვილეში ზონის წევრობა

ზონა აჯგუფებს ინტერფეისებს ან ტრაფიკს firewall-ის მოდელში. მისი input, output და forward პარამეტრები შემდეგ სხვადასხვა როლს მართავს. input არის ტრაფიკი თავად როუტერისკენ; forward არის ტრაფიკი მის გავლით სხვა ჰოსტისკენ. OpenWrt-ის ზონების დოკუმენტაცია სწორედ ამ მიზეზით განიხილავს input-ს, output-სა და forward-ს ცალკე პარამეტრებად.

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

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

გადაწყვეტილება პირველი: input, forward თუ ორივე

თუ დისტანციურ კლიენტებს როუტერიდან DNS სჭირდებათ, დაუშვით input მხოლოდ იმ სერვისისთვის. თუ მათ ფაილურ სერვერამდე მისვლა სჭირდებათ, დაუშვით forward იმ დანიშნულებისკენ. VPN-ის უმეტეს დიზაინს ორივე სჭირდება, მაგრამ სხვადასხვა სერვისისთვის.

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

გადაწყვეტილება მეორე: რა რესურსები სჭირდებათ დისტანციურ კლიენტებს

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

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

თუ ნებადართულ დანიშნულებას შეუძლია შემდგომი გადაცემა, ზონის საზღვარი firewall-ზე ჩერდება და არა იმაზე, რასაც დანიშნულება შემდეგ აკეთებს.

გადაწყვეტილება მესამე: როგორ დაამტკიცებთ საზღვარს

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

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

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