د OpenVPN UDP لپاره د Nginx stream ریلې: څه بدلوي

ستاسو کلاینټ په UDP تنظیم دی، د Nginx سرور کې د VPN پورټ ته اشاره کوونکی location بلاک دی، او هېڅ نه رارسي. دا تمه کېدونکې ده: HTTP location نشي کولی د UDP ډیټاګرام وړي، هر نوم چې مخکې برخې ته ورکړل شي۔ Nginx دې ته stream اورېدونکي ته اړتیا لري، او کله چې ترتیب هلته یوسئ، د جزیاتو دوهمه ټولګه پرېکړه کوي چې غونډه ژوندۍ پاتې کېږي که نه۔

د پروکسي پرت له ادرس مخکې راځي

د Nginx stream ماډول پرته له دې چې HTTP تحلیل کړي، TCP او UDP پروکسي کوي. د هغې 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 ځواب ورکوي؛ د دې په اړه یې هېڅ ونه ویل چې مخکې برخه څه ملاتړ کوي۔ دواړه کېدای شي سم وي، او یوازې یو له دوی څخه د دې ځای پرځای کولو ترتیب دی۔