SSH და VPN შემავალი წესები: რას აკონტროლებს სინამდვილეში ნებადართულთა სია

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

თვალი ადევნეთ ერთ SSH ცდას შემავალ კაუჭამდე

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

შემდეგ დაადასტურეთ მსმენელი, რადგან ვერც ერთი წესი ვერ იხსნის სერვისს, რომელიც არ არსებობს. გაუშვით ss -ltnp და შეამოწმეთ, რომ რაღაც მიბმულია მოსალოდნელ პორტსა და მისამართების ოჯახზე, შემდეგ წაიკითხეთ ssh -v კლიენტზე, რომ ნახოთ სად ჩერდება.

გადაგზავნა ცალკე გადაწყვეტილებაა

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

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

ჩაგდება და უარი მოქმედებებია, არა პოლიტიკა

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

table inet admin {
    chain input {
        type filter hook input priority filter; policy drop;
        ct state established,related accept
        ip saddr 203.0.113.0/28 tcp dport 22 accept
        udp dport 51820 accept
        icmp type { destination-unreachable, time-exceeded } accept
    }
}

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

შეინახეთ ის საკონტროლო ტრაფიკი, რომელიც ნამდვილად გჭირდებათ

მთელი ICMP-ის დაბლოკვა პოპულარული ნაგულისხმევია, რომელიც არღვევს ბილიკის MTU აღმოჩენას და სიმპტომია კავშირი, რომელიც დგინდება და შემდეგ იჭედება უფრო დიდ პაკეტებზე. IPv6-ზე მეზობლების აღმოჩენა მის საკუთარ ICMPv6 ტიპებზეა დამოკიდებული და მათი ჩაგდება წყვეტს კავშირს მანამ, სანამ რომელიმე TCP წესს ჰკითხავენ. ორივე ნებადართულთა სიაში უნდა იყოს როგორც დასახელებული დამოკიდებულება და არა როგორც საერთო ნებართვა. პოლიტიკა, რომელიც ჩუმად არღვევს აღმოჩენას, უარესია, ვიდრე ის, რომელიც ცოტა დიაგნოსტიკურ ტრაფიკს უშვებს.

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

დაამტკიცეთ აღდგენა, სანამ ძველ ბილიკს მიატოვებთ

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

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