Nginx-ის stream რელე OpenVPN UDP-ისთვის: რას ცვლის

თქვენი კლიენტი UDP-ზეა გაწყობილი, Nginx სერვერს აქვს location ბლოკი, რომელიც VPN-ის პორტზე მიუთითებს, და არაფერი არ აღწევს. ეს მოსალოდნელია: HTTP location-ს არ შეუძლია UDP დატაგრამის გადაზიდვა, როგორც არ უნდა ერქვას წინა ნაწილს. ამისთვის Nginx-ს სჭირდება stream მსმენელი და მას შემდეგ, რაც კონფიგურაციას იქ გადაიტანთ, დეტალების მეორე ნაკრები წყვეტს, გადარჩება თუ არა სესია.

პროქსი ფენა მისამართზე ადრე მოდის

Nginx-ის stream მოდული პროქსირებს TCP-სა და UDP-ს HTTP-ის გარჩევის გარეშე. მისი HTTP მოდული ელოდება მოთხოვნის სტრიქონს, თავსართებსა და პასუხს, და არც ერთი მათგანი არ არის მშობლიურ OpenVPN დატაგრამში. ამიტომ ფენის არჩევა პირველი გადაწყვეტილებაა და ის არ არის დამოკიდებული იმაზე, მსმენელი IPv4-ია თუ IPv6.

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

მსმენელი და backend

nginx -V 2>&1 | tr ' ' '\n' | grep stream

stream {
    server {
        listen [::]:1194 udp reuseport;
        proxy_pass [2001:db8::20]:1194;
    }
}

სანამ რამეს შეცვლით, დარწმუნდით, რომ build მოიცავს stream მოდულს; დისტრიბუციულ პაკეტს შეუძლია ის ცალკე მოდულად გაყოს, და მოდულის არარსებობა ტუნელის ნაცვლად კონფიგურაციის შეცდომას იძლევა. მოათავსეთ ბლოკი მთავარ კონფიგურაციის კონტექსტში და არა http-ის შიგნით, და შეცვალეთ დოკუმენტაციის მისამართი ნამდვილი backend-ით.

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

სესიის ტაიმაუტები მოთხოვნის ტაიმაუტები არ არიან

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

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

რას ცვლის რელე და რას არა

stream პროქსი არ ასრულებს OpenVPN-ის TLS მართვის არხს და არც HTTPS-ად გარდაქმნის. backend რჩება VPN სერვისად, და სერტიფიკატის ურთიერთობა რჩება კლიენტსა და ამ სერვისს შორის. განზრახული backend იდენტობის შენარჩუნება კვლავ კლიენტისა და სერვერის საქმეა.

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

გადაამოწმეთ კლიენტიდან და არა პორტიდან

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

როცა ვინმე ამბობს, რომ Nginx-ს UDP არ შეუძლია, რადგან მის ნაცვლად მარტივმა რელე ხელსაწყომ იმუშავა, ეს ორი ფაქტი დაკავშირებული არ არის. ხელსაწყომ დაამტკიცა, რომ backend პასუხობს; მან არაფერი თქვა იმაზე, რასაც წინა ნაწილი უჭერს მხარს. ორივე შეიძლება მართალი იყოს და მხოლოდ ერთი მათგანია კონფიგურაცია ამ განლაგებისთვის.