OpenVPN او HTTPS په 443 پورټ کې: اورېدونکی د چا دی؟
TCP او UDP 443 جلا ساکټونه دي. یو TCP اورېدونکی شریکول مالک ته اړتیا لري، او د OpenVPN پورټ شریکول یوه تنګه موافقه ده، نه د پراکسي چل.
دوه خدمتونه کولی شي دواړه په 443 پورټ کې ځواب ووایي پرته له دې چې کله هم سیالي وکړي، ځکه چې اورېدونکی یوازې د شمېرې له مخې نه، بلکې د لېږد، پتې او پورټ له مخې یوځای ټاکل کېږي۔ یو ماشین ته ویب سرور او OpenVPN کېږدئ، او یوازینی پوښتنه چې لومړی ځواب ورته ویل ارزښت لري دا ده چې هر بهیر له کرنل څخه کوم ساکټ غواړي۔ هغه لیست د ترتیب له ترمیم مخکې ولیکئ، او ډېری «پته له مخکې کارول کېږي» تېروتنې پخپله ځان تشریح کوي۔ له لیست وروسته هر څه د UDP اورېدونکي، شریک TCP ساکټ یا د پروتوکول له مخې لارښوونکي مخکیني برخې ترمنځ انتخاب دی۔
له هغه ساکټ پیل کړئ چې هر بهیر یې غواړي
bind په همدې درېګونې بریالی یا ناکام کېږي، نو دوه ډیمونونه یوازې هغه وخت ټکر کېږي چې درې واړه برخې سره یوځای شي۔ له همدې امله په TCP 443 کې یو ویبپاڼه په UDP 443 کې د OpenVPN اورېدونکي سره بېحد سره ژوند کوي، او له همدې امله د دوی یو بلې دویمې سیمهییزې پتې ته لېږدول هم بحث پای ته رسوي۔ ژوندي اورېدونکي ولولئ، نه هغه فایلونه چې باید یې جوړ کړي وای، ځکه چې زوړ include یا هېر شوی unit فایل ستاسو یاد ترمیم څخه زیات ژوند کوي۔
| Line in the listener list | What it establishes | What to do next |
|---|---|---|
| One udp row and one tcp row, each on 443 | Separate transport sockets, nothing contested | Point the VPN profile at udp and stop editing |
| A single tcp address and port listed by two processes | A real bind collision between two daemons | Move one service, or put a dispatcher in front of both |
| A proxy process owns the socket, no vpn process | The proxy accepts and has to hand off correctly | Check that its backend speaks the protocol it forwards |
د root په توګه ss -lntup وچلوئ او هر هغه کرښه ولولئ چې 443 یادوي، په IPv6 ننوتلو سره۔ معمولاً د v6 وحشي اورېدونکی v4 ټرافیک هم مني، او همداسې هېر شوی اورېدونکی هغه فایل د بدلولو وروسته هم پورټ نیول شوی ساتي چې تاسو یې مسؤل ګڼلئ۔ که د بهیر نوم تاسو حیران کړي، له هر څه لاس وهلو مخکې ss -lntup 'sport = :443' سره وتنه تنګه کړئ۔
کله چې شبکه اجازه ورکړي تونل UDP ته واړوئ
UDP اورېدونکی ټکر په بشپړ ډول څنډې ته کوي او معمولاً تر ټولو لنډ ترمیم دی، ځکه چې هېڅ ساکټ شریک نه کېږي او په لاره کې هېڅ اضافي محصول نه راځي۔ خو دا وړیا نه ده۔ ځینې کسټمر شبکې پرته له reset لېږلو UDP 443 غورځوي، نو تونل د bind کې ناکامېدو پرځای د جوړېدو پاتې کېږي، او کارونکی د لوستلو وړ هېڅ تېروتنې پرته VPN بندېدو راپور ورکوي۔ UDP اورېدونکی د ویب طبقې بیا پیل هم زغملای شي، کوم چې په هغه ماشین کې مهم دی چې ویبپاڼه یې ډېره بیا ځای پرځای کېږي۔ له هغې شبکې ازموینه وکړئ چې کارونکي پکې ناست دي، ځکه چې په سرور کې shell یوازې دا ثابتوي چې سرور ځان ته رسېدلی شي۔
لېږد په سرور ترتیب او په کسټمر پروفایل کې یوځای بدل کړئ۔ هغه پروفایل چې لا هم TCP غواړي په یوازې UDP اورېدونکي پروړاندې د بیا نښلولو په دوره کې ګرځي، او دا تر هغې چې دواړه فایلونه پرتله کړئ د شبکې خرابۍ په څېر ښکاري۔
پرېږدئ چې VPN بهیر TCP 443 ولري او پاتې نورې برخې ولېږدئ
Community OpenVPN په TCP سرور حالت کې د راغلي نښلېدنې لومړني بایټونه لولي او هر هغه څه چې خپل پروتوکول نه وي HTTPS بیکاینډ ته لېږي، port-share لارښوونه همدې لپاره ده۔ بیکاینډ د TLS سره فعال یو عادي ویب سرور دی، چې په همدې لارښوونه کې د URL له مخې نه، بلکې د کوربه او پورټ له مخې نومول کېږي۔
port-share 10.0.0.5 8080
په هغه ماشین کې چې ویبپاڼه دویمه خصوصي پته لري، هغه کرښه غیر-VPN ټرافیک 10.0.0.5:8080 ته لېږي، نو HTTPS مجازي کوربه باید هلته وتړل شي او اورلګېدونکی باید سیمهییز ټوپ ته اجازه ورکړي۔ ویب سرور باید TLS پخپله پای ته ورسوي، ځکه چې راغلي بایټونه د براوزر اصلي لاس نیول دي او په منځ کې هیچا نه دي کوډ پرانیستی۔ لارښوونه یو ساده HTTP اورېدونکي ته وګرځوئ او براوزر به د ناسمې طریقې تېروتنه ترلاسه کړي، کومه چې د خرابې ویبپاڼې په څېر لوستل کېږي، نه د ناسم ځای بیکاینډ په څېر۔ لارښوونه یوازې په TCP سرور حالت کې شته، او UDP اورېدونکی د کتنې لپاره هېڅ جریان نه لري۔
ځکه چې VPN بهیر هر نښلېدنه مني، ویب اپلیکیشن لېږل شوې غوښتنه د لیدونکي له خوا نه، بلکې د کوربه خپلو پتو څخه راتلونکې ویني۔ هر هغه څه چې ریښتینې کسټمر پتې ته اړتیا لري په بیکاینډ کې د PROXY پروتوکول ملاتړ یا د هغه زیاتوونکې مخکینۍ برخې پورې تړلي دي۔ بیکاینډ بلې سیمهییزې پتې ته لېږدول د لیدونکي پته نه راګرځوي؛ یوازې دا بدلوي چې ویبپاڼه د کوربه کومې پتې ثبتوي۔ دا محدودیت په ځای پرځای کولو یادښتونو کې ولیکئ مخکې له دې چې تحلیلي راپور پوښتنه پورته کړي۔
بېرته پراکسي غلط وسیله ده؛ د څلورمې طبقې لارښوونکی نه
HTTP بېرته پراکسي TLS پای ته رسوي څو غوښتنې ولولي، مانا دا چې دا نشي کولی OpenVPN جریان بې لاس وهنې تېر کړي۔ د څلورمې طبقې لارښوونکی چې د SNI یا لومړي پاکټ کتنې له مخې لېږدوي کولی شي د دواړو مخې ته ودرېږي، په دې شرط چې هغه غونډه پای ته نه رسوي چې VPN پرې تکیه لري۔ دواړه وسیلې په ډیاګرام کې ورته ښکاري او په ساکټ کې په بشپړ ډول بېل رفتار کوي۔
سوداګریز Access Server خپل د پورټ شریکولو تنظیمات راوړي، او هغه د ټولنې لارښوونې سره یو په یو نه ځي۔ محصول او نسخه وټاکئ مخکې له دې چې د بل لپاره لیکل شوی لارښود سم کړئ۔ کاپي شوی تنظیم چې په خاموشۍ کې نادیده ګڼل کېږي له هېڅ تنظیم څخه بدتر دی، ځکه چې وروسته هم د اورېدونکو لیست باوري ښکاري۔
ویبپاڼه او تونل د دوو جلا لارو په توګه وآزموئ
ویبپاڼه پورته کړئ او تونل ونښلوئ، بیا د اورېدونکو لیست ولولئ چې اوس 443 د کوم بهیر ملکیت دی۔ پورته شوې پاڼه د VPN په اړه هېڅ نه ثابتوي، او نښلېدونکی تونل د ویبپاڼې په اړه هېڅ نه ثابتوي، که څه هم دواړه یوه شمېره کاروي۔ لاندې درې حکمونه په ترتیب سره شریک ساکټ، ویب لاره او VPN خدمت ګوري۔
ss -lntup 'sport = :443' curl -sI https://vpn.example.com/ | head -n 1 journalctl -u openvpn-server@server -n 20
د همدې شیبې لپاره د بیکاینډ د لاسرسي لاګ کسټمر پته د VPN لاګ پتې سره پرتله کړئ۔ که ویبپاڼه هر لیدونکی د کوربه خپله ثبتوي، لېږد کار کوي او پتې سمبالول نه کار کوي۔ که دواړه لاګونه خاموش وي، مخکینۍ برخې هېڅکله نښلېدنه نه ده سپارلې۔ په هر حال، اورېدونکو لیست ټاکي چې ساکټ څوک مني، او دا هغه حقیقت دی چې باید تایید شي مخکې له دې چې بل فایل بدل کړئ۔
هغه اورېدونکو نقشه د ترتیب ترڅنګ پرېږدئ څو چې 443 ته راتلونکی لاس وهونکی پوه شي چې کوم بهیر مني او بل پروتوکول چېرته لاړ۔ د ترمیم موخه څه وه پر هغې تکیه کولو پرځای له بدلون وروسته ملکیت تایید کړئ۔