په NGINX stream شرایطو کې د TLS passthrough اړیکې اجازه ورکول
NGINX کولی شي د TLS پای ته رسولو پرته د TCP TLS ریلې انکار وکړي. د اجازې قاعده په stream کې کېږدئ، نه په HTTP location کې، او وګورئ کوم peer پته راځي.
د تصدیق نامې هېڅکله نه ساتلو سره کوډ شوي بایټونه لیږل هغه څه دي چې TLS passthrough ریلې کوي، او دا ترتیب هم اسانه دی او هم لږ ګډوډونکی. ځکه چې هېڅ شی نه کوډ کېږي، د فلټر کولو لپاره د HTTP په بڼه هېڅ شی نشته، نو عادي location بلاک او د هغې د لاسرسي قواعد دلته هېڅ کار نه کوي. هغه پرېکړه چې NGINX یې لري د اړیکې په اړه ده: کوم شبکه یي peer ودرول شو، او ایا هغه peer باید په بشپړه توګه ولیږل شي.
پرېکړه په HTTP کې نه، په stream کې ده
په stream شرایطو کې NGINX د TCP غونډو سره کار کوي. دا د اړیکې peer پته ګوري او کولی شي د هغې په سر منظم allow او deny قواعد پلي کړي، مخکې لدې چې هر بایټ backend ته ورسیږي. دا بشپړه د منلو پرېکړه ده او شخصي کیلي، تصدیق نامې یا HTTP تحلیل ته اړتیا نه لري.
| Mechanism | What it decides | Where it lives |
|---|---|---|
| stream allow/deny | Whether this TCP peer is relayed | stream server block |
| ssl_preread map | Which backend a named connection goes to | stream, with the preread module |
| HTTP location rule | Whether an HTTP request is served | http server block |
هغه درې کرښې هېڅکله یو بل نه بدلوي. د HTTP لاسرسي لارښود په کوم فایل کې چې د 443 پورټ یادونه کوي کاپي کول هېڅ نه بدلوي، ځکه چې stream سرور هېڅکله http شرایط نه لولي.
اړیکه ومنئ مخکې لدې چې یې ولیږئ
فرض کړئ چې د stream او stream-access ماډولونو سره یو موجود نصب دی، VPN پیریدونکي سرچینې پتې په 10.90.0.0/24 کې ساتي، او 192.168.50.20:443 کې backend لا دمخه غوښتل شوې HTTPS هویت وړاندې کوي.
stream {
server {
listen 443;
allow 10.90.0.0/24;
deny all;
proxy_pass 192.168.50.20:443;
}
}دا د نوي listener ټوټې په توګه ولولئ، نه د روان ترتیب مستقیم بدلون په توګه. لومړی موجود listener او include وګورئ، ځکه چې په لا نیول شوي پورټ کې دوهم listener د غوښتنې په وخت نه، بلکې په reload کې ناکام شي.
په دې پام وکړئ چې څه نشته: listen ... ssl نشته، د تصدیق نامې لارښود نشته. NGINX کوډ شوی جریان لیږي، او backend TLS پای ته رسوي او هغه تصدیق نامه وړاندې کوي چې پیریدونکی یې تصدیقوي. هغه پیریدونکی چې په allowlist کې ناکام شي د هغې TCP غونډه رد کیږي، نه د HTTP 403 پاڼه، او هر وسیله چې د حالت کوډ تمه لري بې ګټې څه راپور کوي.
allowlist څه پوښي او څه نه پوښي
که ریلې لا دمخه backendونه د سرور نوم له مخې غوره کوي، نو د ماډول شتون سره ssl_preread او map کولی شي هغه کار ته دوام ورکړي. نوم لا هم پیریدونکی وړاندې کوي، او د نوم وړاندې کول دا نه ثابتوي چې پیریدونکی VPN ته ورننوت.
د مثال قاعده ټول stream listener پوښي. دا هغه د یوې واحدې ننوتنې نقطې لپاره ناسمه کوي چې د عامه او یوازې-VPN سایټونو مخلوط وړاندې کوي، چېرې چې د هر نوم لپاره استثنا ته اړتیا وي؛ جلا listenerونه معمولا د نوم پورې تړلي هغه پالیسۍ څخه روښانه وي چې هیڅوک یې نشي لوستلی.
دوه نور تشې د یادولو وړ دي. prefix سمون نه وایي چې پیکټ کوم انټرفېس له مخې راغی، او په بل ځای کې HTTP قاعده دا listener نه شي محدودولی. دواړه دلیلونه دي چې د host کچې ingress پالیسي په انځور کې وساتئ، پرځای دې چې یوه allow کرښه ټوله پوله وګڼئ. پوله د دوو کنټرولونو په توګه ولیکئ چې باید سره سمون ولري، ترڅو په هر یو کې بدلون وڅیړل شي.
NGINX په رښتیا د چا پته ګوري؟
د بار انډول کوونکی، بل proxy یا source NAT کولی شي NGINX ته مخکې منځګړی کېږدي، نو هغه peer چې ګوري د VPN پیریدونکي داخلي پته نه ده. د prefix غوره کولو دمخه ریښتینې لار وګورئ، ځکه چې د غلطې پتې لپاره لیکل شوې allowlist یا د ژباړونکي شاته هر څوک مني یا هیڅوک.
PROXY پروتوکول او د ریښتیني IP اداره قانوني ځوابونه دي، او یوازې د مطابقت لرونکو، په څرګنده توګه باوري لیږونکو لپاره تنظیم شي. دواړه میکانیزمونه هغه څه مني چې لیږونکی یې وایي، او همدا لامل دی چې د لیږونکو لیست باید لنډ وي. د هر انټرنیټ پیریدونکي څخه د پیژندنې سرلیک باور کول د سرچینې معلومات بیا باوري نه کوي؛ دا سم انکار په جعلي منلو بدلوي.
د reload دمخه دواړه پایلې وازموئ
ترتیب تایید کړئ، reload وکړئ، بیا دوه ځله وازموئ: یوه نوې اجازه شوې غونډه چې باید کار وکړي، او یوه رد شوې چې باید ونه کړي. په اجازه شوې ازموینه کې نورمال backend تصدیق نامې تایید وساتئ، ځکه چې هغه ریلې چې نښلي خو backend نه شي تصدیق کولی یوه ستونزه حل او بله جوړه کړې.
nginx -t
ss -tnp | grep ':443'backend لار او ځواب هم جلا وګورئ. allowlist تېرول یوازې دا ثابتوي چې NGINX غونډه منلې؛ دا نه شي کولی نه رسېدونکی backend ځواب ته اړ کړي، او نه هغه بیرته راستنېدونکې لار سمولی شي چې ستاسو د پیل دمخه نه وه.