pfSense-ის გამავალი NAT: ჯერ წაიკითხეთ გენერირებული წესები

გახსენით Firewall, შემდეგ NAT, შემდეგ Outbound და წაიკითხეთ რეჟიმი, სანამ რაიმეს დაამატებთ. Automatic რეჟიმში pfSense ქმნის წესებს WAN ინტერფეისებისთვის და მათ შორის დისტანციური წვდომის VPN ქსელებისთვის, ამიტომ პული, რომლის დამატებასაც აპირებთ, ხშირად უკვე დაფარულია. ხელით დაწერილი სტრიქონის არარსებობა არ არის იმის მტკიცებულება, რომ თარგმანი აკლია. ქვემოთ მოცემული თანმიმდევრობა ხელს გიშლით, მთელი firewall Manual-ზე გადაიყვანოთ ერთი პულის გადასაჭრელად.

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

Automatic რეჟიმი უკვე ფარავს VPN პულს

თითოეულ რეჟიმს თავისი მფლობელი აქვს. Automatic ქმნის წესებს WAN ინტერფეისებისთვის და თავის წყაროებში აერთიანებს დისტანციური წვდომის VPN ქსელებს. Hybrid ინარჩუნებს ამ გენერირებულ წესებს და საშუალებას გაძლევთ მათ გვერდით ხელით შექმნილი წესები დაამატოთ. Manual წყვეტს რაიმეს გენერირებას, ამიტომ firewall-ზე ყოველი თარგმანი თქვენს პასუხისმგებლობად იქცევა, მათ შორის ისინი, რომლებიც თქვენ არ დაგიწერიათ. მეოთხე პარამეტრი მთლიანად თიშავს გამავალ NAT-ს. ხელით დაწერილად მოჩვენებული სტრიქონი არაფერს ამტკიცებს, სანამ არ გაიგებთ, რომელი რეჟიმია აქტიური.

Automatic და Hybrid რეჟიმებში გვერდი ასევე აჩვენებს გენერირებულ წესებს. წაიკითხეთ ისინი, სანამ დაასკვნით, რომ VPN პულს თარგმანი არ აქვს: მოძებნეთ პულის ქსელი წყაროს სვეტში და WAN ინტერფეისი ინტერფეისის სვეტში.

აირჩიეთ Hybrid მხოლოდ განხილული გამონაკლისისთვის

დოკუმენტირებული გამონაკლისი კვლავ შესაძლებელია, როცა გამავალი პოლიტიკა ნამდვილად განსხვავდება. წარმოიდგინეთ სერვერი, რომელიც ანაწილებს 10.90.0.0/24-ს, სადაც firewall-მა უნდა უზრუნველყოს IPv4 ინტერნეტ გამოსავალი და მარშრუტიზაცია უკვე ირჩევს WAN-ს. მოსალოდნელი გარდაქმნაა, რომ წყარო 10.90.0.23 გადაიწეროს WAN მისამართზე. შეამოწმეთ, აკეთებს თუ არა ეს გენერირებული წესი უკვე ამ გამოსავალზე; თუ არა, Hybrid ინარჩუნებს ავტომატურ დაფარვას და ამატებს თქვენს განხილულ წესს.

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

ნუ გადაიყვანთ მთელ firewall-ს Manual-ზე ერთი პულის გამო. ეს გადაწყვეტილება გადაანაწილებს მოვლას ყოველი შიდა ქსელისა და ყოველი მომავალი WAN ცვლილებისთვის.

NAT არ ირჩევს გამოსავალს

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

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

დაამტკიცეთ გარდაქმნა ახალ კავშირზე

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

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