ვირტუალური pfSense TAP ხიდი: სამი ადგილი, სადაც კადრი შეიძლება მოკვდეს
ხიდი, მისი წევრები და ვირტუალური კომუტატორი თითოეული ცალკე წყვეტს. გაარკვიეთ რომელი მფლობელი ფილტრავდა, სანამ გამორთავთ მართვას, რომელიც გზაზე არასდროს ყოფილა.
თქვენ გამორთავთ წესს LAN ინტერფეისზე, კადრი მაინც ქრება და დასკვნა ის არის, რომ pfSense საკუთარ firewall-ს უგულებელყოფს. ჩვეულებრივ მოხდა ის, რომ გადაწყვეტილება სხვა მფლობელმა მიიღო: თავად ხიდმა, წევრ ინტერფეისმა ან სტუმრის გარეთ არსებულმა ვირტუალურმა კომუტატორმა. თითოეულს აქვს საკუთარი მართვა და საკუთარი ჟურნალი.
ქვემოთ მოცემული სამი საზღვარი ღირს გამიჯვნად, სანამ რომელიმე პარამეტრს შეცვლით, რადგან ერთის გამორთვა მეორეს ვერ ანაზღაურებს.
ერთი კადრი, სამი პოლიტიკის მფლობელი
TAP კლიენტის კადრი შედის გვირაბის მოწყობილობით, კვეთს pfSense ხიდს, გამოდის LAN წევრით და შემდეგ გადის ვირტუალურ კომუტატორს, სანამ რაიმეს მიაღწევს. სტუმრის შიგნით ფილტრაცია შეიძლება მოხდეს ხიდზე ან წევრ ინტერფეისებზე, და რომელია აქტიური, კონფიგურაციის არჩევანია და არა მუდმივი თვისება. სტუმრის გარეთ ჰიპერვიზორი წყვეტს, შეუძლია თუ არა ამ ვირტუალურ ადაპტერს ისეთი წყარო MAC-ის მქონე კადრების გაგზავნა, რომელიც მას არ ეკუთვნის. ნებისმიერ ამ წერტილში ვარდნა კლიენტის მხრიდან ერთნაირად გამოიყურება.
გამოძიებამდე ჩამოწერეთ განზრახული გზა: გვირაბის წევრი, ხიდი, LAN წევრი, ვირტუალური კომუტატორი, დანიშნულება. შემდეგ იკითხეთ, რომელი მფლობელი დაინახავდა კადრს ამ გზაზე.
რომელი pfSense მართვა ფილტრავს
pfSense ამისთვის ორ sysctl-ს აფიქსირებს, ერთს ხიდის წევრებზე ფილტრაციისთვის და ერთს თავად ხიდზე ფილტრაციისთვის, და ერთი მათგანი მაინც უნდა დარჩეს ჩართული. ხიდის დონეზე ფილტრაცია ეხება ტრაფიკს, რომელიც ხიდის წევრებით შემოდის, ამიტომ იგი მიმართულებით შემომავალია და არა სიმეტრიული. წაიკითხეთ წესები იმ ინტერფეისზე, რომელიც ნამდვილად ფილტრავს, რადგან ფილტრაციის როლის გარეშე წევრზე დაწესებული წესი საერთოდ არაფერს აკეთებს. ხიდის ფილტრაციის დოკუმენტაცია ხსნის მფლობელობას.
IP მისამართის გარეშე წევრ ინტერფეისს არ აქვს საკუთარი მისამართის ან ქვექსელის მაკრო, ამიტომ ამ მაკროს წინააღმდეგ დაწერილი წესი შეიძლება აღწეროს სხვა რამ, ვიდრე თქვენი განზრახული LAN. გამოიყენეთ განზრახ მინიჭებული ქსელის ობიექტები კომფორტის მაკროების ნაცვლად.
ფრაგმენტი კადრი არ არის
Ethernet კადრები ატარებენ IP პაკეტებს, და IP პაკეტი შეიძლება იყოს უფრო დიდი დატაგრამის ფრაგმენტი, ამიტომ ეს ორი სიტყვა ურთიერთშემცვლელი არ არის. გვირაბის შიგნით არის შიდა პაკეტი, ხოლო მის გარეთ გარე სატრანსპორტო პაკეტი, და უკმარისობა შეიძლება ეკუთვნოდეს ორივეს. პატარა ping ამოწმებს ერთ გზას ამ დასტის გავლით და ვერაფერს ამტკიცებს დიდ გადაცემაზე. შეადარეთ წარუმატებელი გაცვლა ორ მეზობელ საზღვარზე და წაიკითხეთ ვარდნის მიზეზი, სანამ წესს დაადანაშაულებთ.
თუ ფრაგმენტები ქრება, პასუხი შეზღუდული შესწორება ან პაკეტის ზომის გამოძიებაა და არა ფილტრაციის სრულად გამორთვის გადაწყვეტილება.
ჰიპერვიზორს აქვს საკუთარი დაშვების გადაწყვეტილება
სტუმარი, რომელიც სხვა მანქანებისთვის ტრაფიკს ხიდავს, აგზავნის კადრებს, რომელთა წყარო MAC მისამართები მისი ადაპტერის არ არის, და ბევრი ვირტუალური კომუტატორი ამას გაყალბებად მიიჩნევს, თუ პორტების ჯგუფი ამას არ უშვებს. ამ გადაცემის დაშვება და ადაპტერისთვის ყოველი კადრის მიღების დაშვება ცალკეული მართვებია, და ორივეს ყველგან ჩართვა გაცილებით დიდი ცვლილებაა, ვიდრე პრობლემა მოითხოვს. დაადგინეთ, რომელი კადრები უნდა მიიღოს და რომელი უნდა გაგზავნოს ხიდმა, შემდეგ მიანიჭეთ მხოლოდ ეს ქცევა იმ საზღვარზე, რომელიც მას ფლობს. შეინარჩუნეთ კონსოლის წვდომა, სანამ დისტანციურად მართულ ხიდს შეცვლით.
კავშირის აღდგენა ტესტის ნახევარია; მეორე ნახევარი იმის დადასტურებაა, რომ ნაკადი, რომელიც ბლოკირებული უნდა დარჩეს, კვლავ ბლოკირებულია.
ჩაწერეთ, რომელი მფლობელი ფილტრავდა, რომელი მართვა შეიცვალა და რომელი ორი ნაკადი შეამოწმეთ. ეს ჩანაწერი ხელს უშლის შემდეგ ინციდენტს დაიწყოს იმავე ვარაუდით, რომ pfSense თავის თავს უგულებელყოფს.