ერთი საჯარო ჰოსტი VPN-ისა და ვებისთვის: როგორ გავყოთ როლები

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

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

აირჩიეთ მისამართის მფლობელი პორტებამდე

გვირაბის ბოლო წერტილი და ვებ სერვერი შეიძლება ერთ ბირთვს იზიარებდნენ; ერთი მისამართის, პორტისა და პროტოკოლის ერთდროული გაზიარებაა ის, რაც ფერხდება. WireGuard ჩვეულებრივ იღებს UDP 51820-ს, OpenVPN იღებს UDP 1194-ს ან TCP 443-ს, ხოლო ვებ სერვერი იღებს TCP 443-ს. მტკივნეული წყვილია OpenVPN TCP 443-ზე HTTPS-ის გვერდით, რადგან ორივეს ერთი და იგივე სოკეტი სურს და ბირთვი მას პირველად დაკავშირებულს აძლევს. მხოლოდ წინ დგას დემულტიპლექსორი, როგორიცაა sslh ან TLS-ის მცოდნე პროქსი, რომელიც აძლევს მათ ამ პორტის გაზიარების საშუალებას, და ის ამატებს კომპონენტს, რომლის გაუმართაობა ზუსტად firewall-ის პრობლემას ჰგავს.

შეხედეთ მფლობელებს, სანამ რამეს შეცვლიდეთ: ss -lntup ბეჭდავს თითოეული მოსმენილი სოკეტის ლოკალურ მისამართს, პორტსა და პროცესს. ორი სტრიქონი, რომლებიც აჩვენებს 0.0.0.0:443-ს, ნიშნავს, რომ მეორე სერვისი არასდროს დაკავშირდა, რამდენადაც ხალისიანი იქნებოდა მისი init სკრიპტი. ხიდი მფლობელსაც გადაადგილებს. როცა eth0 უერთდება br0-ს, IP გადადის br0-ზე და ყოველი firewall წესი, რომელიც ახსენებს eth0-ს, წყვეტს დამთხვევას, ამიტომ დაუკავშირეთ სერვისები ხიდს და დაადასტურეთ ip -br addr-ით.

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

მარშრუტიზაცია ორ LAN-ს შორის ან NAT ერთ მხარეს

ორი LAN, რომლებიც ერთმანეთს ვერ ხედავენ, შეიძლება თითოეულმა დარეკოს საჯარო ჰოსტს, რომელიც შემდეგ გვირაბებს შორის გადასცემს. ამ მარშრუტიზებულ დიზაინს სამი რამ სჭირდება: ჩართული გადაცემა, მარშრუტი ყოველი შორეული პრეფიქსისკენ და გადაცემის პოლიტიკა, რომელიც ტრანზიტს გაატარებს. sysctl -w net.ipv4.ip_forward=1 ფარავს პირველს, ip route add 10.20.0.0/24 dev wg1 მეორეს, და nftables-ის ხაზი, როგორიცაა nft add rule inet filter forward iifname "wg0" oifname "wg1" accept მესამეს.

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

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

შეამოწმეთ გაყოფა, როცა ორი როლი გაჩერებულია

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

სამი ბრძანება ხდის ამ ტესტს ხელშესახებს. curl -sk --resolve example.test:443:203.0.113.10 https://example.test/ ამტკიცებს, რომ ლოკალური მსმენელი პასუხობს გარე DNS-ის გარეშე, wg show კლიენტზე ამტკიცებს, რომ ჩამოჭიდება დასრულდა, და tcpdump -ni any port 51820 ჰაბზე გამოყოფს მარშრუტიზაციის პრობლემას გასაღების პრობლემისგან. ჩამოჭიდება, რომელიც არასდროს ჩნდება ჩანაწერში, ჰოსტამდე მოკვდა: პროვაიდერის firewall, არასწორი საჯარო მისამართი ან გზაზე NAT წესი.

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

შეინახეთ წესების ნაკრები წაკითხვადი, როცა როლებს აკლებთ. nft list ruleset უნდა აჩვენოს ერთი დაშვების წესი თითოეული მიმართულებისთვის, რომელიც ნამდვილად გჭირდებათ, და გადაცემის ჯაჭვი, რომელიც ყველაფერს უშვებს, გაყოფა არ არის, ეს მომუშავე დემოა.

მხოლოდ IPv6 წვდომის ხაზები და IPv4 სერვისები

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

შეამოწმეთ თითოეული ოჯახი ცალ-ცალკე curl -4 და curl -6-ით, რადგან ერთი წარმატებული მოთხოვნა არაფერს ამბობს იმ გზაზე, რომელიც არ გამოგიცდიათ. პორტის საკუთრება ოჯახებს შორის არ იცვლება, მაგრამ მსმენელი იცვლება: ss -lntup IPv4 და IPv6 სოკეტებს ცალკე სტრიქონებად ჩამოთვლის, და 0.0.0.0:443 არ ფარავს [::]:443-ს, თუ პროცესმა dual-stack სოკეტი არ მოითხოვა.

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