რომელ წყაროს მისამართს ჩაწერს NGINX VPN კლიენტისთვის?
გადაწყვიტეთ, რას ხედავს NGINX OpenVPN-ის გვერდით ერთ ჰოსტზე: შიდა გვირაბის მისამართი, საჯარო გასასვლელი მისამართი თუ გადაგზავნილი წყვილი, გავლილი მარშრუტის მიხედვით.
ერთსა და იმავე ჰოსტზე NGINX-ისა და OpenVPN-ის კონფიგურაციაში სამი კლიენტის მისამართი ჩანს, თითო ყოველი მარშრუტისთვის, რომელიც მოთხოვნამ შეიძლება აირჩიოს. ბრაუზერი, რომელიც გვირაბის მისამართს მიაღწევს, ბრაუზერი, რომელიც საჯარო მისამართს მიაღწევს, და პროგრამა, რომელიც კარიბჭის ინტერნეტ გზით გადის, მოსმენის სოკეტზე სხვადასხვანაირად ჩანს. სანამ ჟურნალის სტრიქონს განმარტავთ, გადაწყვიტეთ, რომელ მარშრუტს უყურებთ. გადაწყვეტილება დამოკიდებულია იმ დანიშნულებაზე, რომელიც კლიენტმა გამოიყენა, გარე VPN საბოლოო წერტილისთვის მის მიერ დაცულ გამონაკლისზე და იმაზე, თარგმნის თუ არა რამე პაკეტს გზაში.
გადაწყვიტეთ დანიშნულებით და არა იმით, თუ ვინ არის მომხმარებელი
დაიწყეთ იმ მისამართით, რომელზეც მოთხოვნა გაიგზავნა, რადგან სწორედ ეს მისამართი ირჩევს მარშრუტს. ჰოსტის გვირაბის მისამართზე მოთხოვნა გვირაბის ინტერფეისზე მოდის კლიენტის შიდა მისამართით როგორც წყაროთი. ჰოსტის საჯარო მისამართზე მოთხოვნა ჩვეულებრივ ინტერნეტისკენ მიმართულ ინტერფეისზე მოდის კლიენტის საჯარო მისამართით, მაშინაც კი, როცა იმავე ნოუთბუქს იმ მომენტში გვირაბი აქვს დამყარებული. ამიტომ VPN პულში წევრობა პაკეტის მარშრუტის თვისებაა და არა მომხმარებელს მიმყოლი თვისება.
| Path the request took | Source the site normally records |
|---|---|
| Client reaches the site at its tunnel address, 10.24.0.1 | Client inner address, 10.24.0.20 |
| Client reaches another internet site through the gateway | Gateway public egress address, 192.0.2.44 |
| Client reaches the gateway's public address through the endpoint exception | Client's own public access address |
სწორედ ეს მესამე სტრიქონი ღირს პირველ რიგში შემოწმებას, როცა ჟურნალში VPN მომხმარებელი ჩნდება ისეთი მისამართით, რომელსაც გვირაბთან არაფერი აქვს საერთო. ეს ასევე ხსნის, რატომ შეიძლება ერთი და იმავე პროფილის ორმა მომხმარებელმა სხვადასხვა ჩანაწერი შექმნას: მათი საკუთარი წვდომის ქსელები განსხვავებულია და გვირაბში არაფერი წერს ამას ზემოდან.
რატომ ქმნის გარე საბოლოო წერტილი მეორე საჯარო მარშრუტს
კლიენტმა გვირაბის დასამყარებლად კარიბჭის საჯარო მისამართს უნდა მიაღწიოს, ამიტომ ამ მისამართამდე მარშრუტი გვირაბის გარეთ უნდა არსებობდეს. როცა კლიენტი მთელ ტრაფიკს შიგნით მიმართავს, გონივრული იმპლემენტაცია ინარჩუნებს სერვერის საჯარო მისამართის აშკარა ჰოსტის მარშრუტს, რათა თავიდან აიცილოს გვირაბი, რომელიც საკუთარ თავზეა დამოკიდებული. ეს გამონაკლისი სერვისების მიმართ შერჩევითი არ არის, ამიტომ მას მიჰყვება ყოველი მოთხოვნა იმავე საჯარო მისამართზე, მათ შორის კარიბჭეზე განთავსებულ საიტზე ბრაუზერის მოთხოვნა.
ეს არის მექანიზმი, რომელიც დგას ამ სფეროში დამაბნეველი მოხსენებების უმეტესობის უკან, და ის დამოკიდებულია კლიენტის და არა სერვერის იმპლემენტაციაზე. ამიტომ იდენტური პროფილების მქონე ორი კლიენტი შეიძლება სხვადასხვანაირად მოიქცეს. ჟურნალის »გასწორებისთვის« გამონაკლისის მოხსნა გვირაბსაც ამხედრებს, ამიტომ დაიტოვეთ ის და დააპროექტეთ მის გარშემო.
წაიკითხეთ სოკეტი, ცხრილი და ჟურნალის ფორმატი ერთად
სამი დაკვირვება წყვეტს, რომელ მარშრუტს უყურებთ: სად უსმენს სოკეტი, რომელი ინტერფეისი პასუხობს დანიშნულებას და რას წერს რეალურად ჟურნალის ფორმატი. თუ მსმენელი მხოლოდ გვირაბის მისამართზეა მიბმული, საჯარო მოთხოვნა საერთოდ ვერ მიაღწევს მას, რაც მაშინვე გამორიცხავს ორ სტრიქონს. თუ კლიენტისთვის ძებნა გვირაბის მოწყობილობას აბრუნებს, მოთხოვნა შიდა წყაროთი მოვიდა და ჟურნალმა ეს უნდა აჩვენოს.
ss -lntp 'sport = :443'
ip route get 10.24.0.20
ip route get 192.0.2.44შემდეგ წაიკითხეთ ფორმატი და არა სტრიქონი. გადაგზავნილი თავსართით საზრდოობს ველი წერს მტკიცებას და არა სოკეტის წყვილს, და მტკიცებას მნიშვნელობა აქვს მხოლოდ მაშინ, როცა უშუალო წყვილი სანდო პროქსია. ორივე მნიშვნელობის ჟურნალში ჩაწერა წყვეტს შემდგომ კამათს, რადგან უშუალო წყვილი და ჩანაცვლებული მისამართი სხვადასხვა ფაქტია და მხოლოდ ერთი მათგანი მოვიდა ქსელიდან.
log_format tunneled '$remote_addr $realip_remote_addr $request $status';
grep -n 'log_format' /etc/nginx/nginx.confაირჩიეთ სასურველი შესასვლელი წერტილი და შეათანხმეთ DNS
თუ საიტი მხოლოდ გვირაბით უნდა იყოს, მიეცით სახელი, რომელიც VPN კლიენტებისთვის გვირაბის მისამართზე იხსნება, და გამოიყენეთ პოლიტიკა მოსმენის სოკეტზე. შიდა სახელისთვის 10.24.0.1-ის დამაბრუნებელი გაყოფილი DNS პასუხი მარშრუტიზაციის გადაწყვეტილებაა სახელის ამოხსნის დეტალის სამოსში. თუ საიტი საჯაროც უნდა იყოს, შეინარჩუნეთ ორი სახელი ან ორი პორტი და ნება მიეცით ჟურნალს თქვას, რომელმა მოემსახურა მოთხოვნას.
ნებართვების წესები იგივე ლოგიკას მიჰყვება. გვირაბის პულის დაშვება არ ანიჭებს უფლებას საჯარო მოთხოვნაზე და არ შეავსებს შიდა მისამართს ინტერნეტით მოსულ კავშირზე. ორივე შესასვლელი წერტილის ერთი სახელის ქვეშ შერევა ჩაწერილ წყაროს ხდის კლიენტის მარშრუტიზაციის გვერდით ეფექტს და არა დიზაინის არჩევანს.
შეამოწმეთ მარშრუტი, შემდეგ პოლიტიკა
დაადასტურეთ მარშრუტი კარიბჭეზე გაკეთებული ჩაჭერით და თქვენს მიერ კონტროლირებული მოთხოვნით. გვირაბის მოწყობილობაზე ჩაჭერა და საჯარო ინტერფეისზე ერთი გვიჩვენებს, რომელმა გადაიტანა ბაიტები, და პაკეტების რიგი გეტყვით, მოხდა თუ არა მათ შორის თარგმანი.
tcpdump -ni tun0 port 443 -c 5
tcpdump -ni eth0 port 443 -c 5შემდეგ შეამოწმეთ წვდომა ორივე მიმართულებით: განზრახული დასახელებული შესასვლელი მუშაობს განზრახული კლიენტისთვის და დაუმტკიცებელი საჯარო მარშრუტი უარყოფილია და არა უბრალოდ ნელი. ზოგადი IP-ექოს საიტი რაღაცას ამტკიცებს კარიბჭის ინტერნეტ გასასვლელზე და არაფერს ამ საიტზე იმავე ჰოსტზე. როცა გვერდი და WebSocket არ თანხმდებიან, შეადარეთ მათი URL-ები, მისამართების ოჯახები და DNS პასუხები სანამ სერვერის კონფიგურაციას შეეხებით.