NGINX საიტი მხოლოდ VPN-ისთვის: მსმენელი, ფაირვოლი და HTTP ნებართვების სია

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

მაგალითი იყენებს Linux OpenVPN კარიბჭეს 10.90.0.1-ზე tun0-ზე, კლიენტებს 10.90.0.0/24-ში, შენახულ წყაროებს და ამ შესასვლელისთვის დაცულ TCP 8443-ს. შეცვალეთ მნიშვნელობები, შეინარჩუნეთ ფენები.

დაიწყეთ სოკეტით, არა ჰოსტის სახელით

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

server {
    listen 10.90.0.1:8443 ssl;
    server_name admin.corp.example;

    ssl_certificate     /etc/nginx/tls/admin-fullchain.pem;
    ssl_certificate_key /etc/nginx/tls/admin-key.pem;

    root /srv/private-site;

    allow 10.90.0.0/24;
    deny all;

    location / {
        try_files $uri $uri/ =404;
    }
}

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

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

დახურეთ ყველა სხვა მსმენელი ამ კონტენტისთვის

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

sudo nginx -T | grep -n "listen\|server_name\|root\|proxy_pass"

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

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

შეზღუდეთ შემავალი ბილიკი ჰოსტზე

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

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

sudo ufw allow in on tun0 proto tcp from 10.90.0.0/24 to 10.90.0.1 port 8443

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

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

შეინარჩუნეთ HTTP სია ხელუხლებელი, როცა მდებარეობები იცვლება

NGINX allow და deny ჩანაწერებს რიგით აფასებს, და ზემოთ მოცემული სერვერის დონის სია ნაწილობრივ უშვებს გამოცხადებულ ჯგუფს საბოლოო deny-მდე. წვდომის მოდული ასევე აღნიშნავს, რომ ნებისმიერი წვდომის ჩანაწერის განმსაზღვრელი მდებარეობა იყენებს საკუთარ სიას მშობელი სიის ნაცვლად. რიგი ისეთივე მნიშვნელოვანია, როგორც თავად ჩანაწერები.

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

გადახედეთ ყოველ მდებარეობას, ფსევდონიმს და ალტერნატიულ ბლოკს იმავე პოლიტიკის ნაწილად. თუ IP შემოწმებები კომბინირებულია NGINX ავთენტიფიკაციასთან, გაიაზრეთ satisfy: any პარამეტრს შეუძლია კლიენტი ერთი მექანიზმით შეუშვას, სანამ მეორე არ გაიარა. შეიტანეთ წვდომის სია მდებარეობების გადახედვის სიაში.

HTTP უარი ხდება მას შემდეგ, რაც TCP კავშირი NGINX-ს აღწევს. ის ავსებს ქსელურ შეზღუდვას, და აპლიკაციის საკუთარი ავტორიზაცია კვლავ ვრცელდება ყოველ მომხმარებელზე.

შეამოწმეთ ცოცხალი ბილიკი და ხარვეზის შემთხვევა

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

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

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

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