د WSS تونل کوډ کول د TLS په پای نېټه ودرېږي، نه په اپلیکیشن کې

په خوندي WebSocket کې د وړل کېدونکي تونل کوډ کول په ټولیزه توګه هغومره دي څومره چې کلینټ په هغې کې اېښي دي، تر دې زیات نه۔ wss:// سکیم وایي چې TLS په یوه ټوپ کې یوه اړیکه ساتي۔ د WebSocket پیغامونو دننه بایټونه که جلا خوندي دي یا نه، د دې په اړه هېڅ نه وایي، او کله چې په منځ کې څه TLS پای ته رسوي، ستاسو ترافیک څوک لوستلی شي، دا همدا توپیر ټاکي۔

دوه پوړونه چې لکه یو ښکاري

خوندي WebSocket هغه TLS دی چې پر سر یې WebSocket لاس ورکول کېږي، لکه څنګه چې RFC 6455 د اړیکې او امنیت په برخو کې بیانوي۔ د TLS پوړ سرور تصدیقوي او جریان کوډ کوي، بیا د WebSocket پوړ هغه څه چوکاټ کوي چې اپلیکیشن یې د لېږلو پریکړه کوي۔

دا دوه خپلواکې پریکړې دي، او هغه ډیاګرام چې په ټول لار یو قلف ګانده د بل پټوي۔ وپوښتئ چې د TLS اړیکه څوک پای ته رسوي۔ بیا وپوښتئ چې کلینټ په هر پیغام کې څه اېښي۔ د ځای پرځای کولو په اړه نور هر څه له همدغو دوو ځوابونو راځي۔

ډیزاین A: لیږد یوازینی کوډ کول دی

په ساده ډیزاین کې، کلینټ خام IP پیکټونه اخلي او په WebSocket پیغامونو کې یې نغاړي۔ دننه هېڅ کوډ شوی نه دی، نو هغه برخه چې د TLS غونډه لري، ساده متن بارونه لولي۔ کله چې هغه برخه ستاسو خپل تونل سرور وي، دا هماغه هدف پای ټکی دی او ډیزاین همغږی دی، ځکه چې سرور به هر حال ترافیک لیدلی و۔

دا بل ترتیب شي کله چې د کتنې پروکسي په لار کې کېني او د هغه سند سره TLS پای ته رسوي چې کلینټ باور پرې لري۔ هغه پروکسي اوس هغه هم ساده متن لري چې سرور به یې درلود، او د WebSocket چوکاټ جوړولو هېڅ اندازه دا نه بدلوي۔ د کلینټ باور زېرمه دا پایله له تونل خلاصېدو ډېر مخکې ټاکلې وه، ځکه چې هغې د هماغه نوم لپاره د هغه سند منلو ته غوره کړه۔ پروکسي هم غوښتل شوی کوربه او د هر پیغام اندازه ویني، چې دا پرته له نور هېڅ ډيکوډ کولو د ډېرو فعالیتونو د ګوتې نښې اخیستلو لپاره بسنه کوي۔

ډیزاین B: بار خپلې کلي لېږدوي

په دوهم ډیزاین کې، کلینټ خپل پیکټونه د VPN پروتوکول سره کوډ او تصدیقوي چې خپله همکاره پیژندنه او کلي بدلون لري، بیا پایله د WebSocket پیغامونو دننه وړي۔ دلته د باندې TLS پای ته رسول ترافیک نه، بلکې کوډ شوی متن ښکاره کوي۔ پروکسي د پیغامونو اندازې او وخت لیدلی شي، او په بار کې بل هېڅ نه۔ دا ډېر کوچنی ښکارېدل دی، او دا لا هم هغه میټاډاټا دي چې په کتنه کې یې نوم اخیستل ارزښت لري، نه دا چې لاس وڅنډل شي۔

د دنني پروتوکول خپل پای ټکي لا هم ساده متن ویني، دا د دې ترتیب مانا او هم د هغې حد دی۔ که په پای ټکي کې یوه برخه د کوډ کولو مخکې یا د ډيکوډ وروسته د معلوماتو لوستلو واک ولري، اضافي پوړ هغه نه محدودوي۔ کلي او هغه سافټویر چې د هغو سره کار کوي، هغه مهم حد پاتې کېږي۔

د VPN لیبل، پیژندل شوې کلینټ آیکون یا بازارموندنې پاڼه د دې ډیزاین شتون ثبوت نه دی۔ د بار بڼه لوستل ثبوت دی۔

تعقیب کړئ چې ساده متن په حقیقت کې چېرته ښکاره کېږي

د URL سکیم تاسو ته یو حقیقت درکوي، نو پاتې یې له انټرفېسونو واخلئ۔ لاندې کتنې په ترتیب سره چل کړئ، ځکه هر یو بل ته تنګي ورکوي:

ss -tnp | grep -E ':(443|8443)\b'
ip -br link show type tun
openssl s_client -connect vpn.example.net:443 -servername vpn.example.net -brief
tcpdump -ni tun0 -c 5 -X

له باندې اړیکې پیل کړئ۔ د TLS پورټ ته یوه اوږده TCP غونډه د WebSocket وړونکي بڼه ده، او نااړونده کوربه ته دوهمه غونډه ژور ګوتلو مخکې د څرګندونې وړ ده۔ بیا په کلینټ کې د تونل انټرفېس ومومئ، ځکه چې tun یا tap وسیله تاسو ته وایي چې کلینټ د یو اپلیکیشن جریان پروکسي کولو پر ځای IP پیکټونه سمبالوي۔

د تونل انټرفېس کتنه معمولاً د بار پوښتنه حل کوي۔ هلته لوستل کېدونکي سرلیکونه معنا لري چې دنني پیکټونه هېڅکله جلا کوډ شوي نه وو، په داسې حال کې چې لوړ انټروپي بارونه معنا لري چې وو۔ په باندې انټرفېس کتنه تکرار کړئ او دواړه پرتله کړئ: که دواړه تصادفي ښکاره شي، دننی پوړ هغه کار کوي چې باندنی یې نه شي باطلولی۔

هغه باور وګورئ چې تاسو واقعاً ورکړی دی

نصب شوی کارپوریټ ریښه سند د کلینټ د باور زېرمې په اړه حقیقت دی، نه دا چې کوم پروکسي څه ثبت یا کتنه کوي۔ د CA شتون څخه د چلند اټکل کولو پر ځای، پلي شوې تګلاره او ریښتینې اړیکه لار وټاکئ۔

په مدیریت شوو وسایلو کې، له مدیر وپوښتئ چې کومه برخه TLS پای ته رسوي، کلینټ د ټینګ شوي سند تصدیق کوي که عام سند، او د بار بڼه څه ده۔ هغه درې ځوابونه هغه موندنه درکوي چې وروسته یې دفاع کولی شئ۔

پایله د حکم پر ځای د حد په توګه ولیکئ۔ "TLS د کتنې پروکسي کې پای ته رسېږي، او دننی بار یوازې د پای ټکو سره کلي په جلا توګه کوډ شوی دی" هغه د کتنې وړ خبره ده چې د عرضه کوونکي بدلون هم تېروي۔ "WebSockets خوندي دي" نه تېروي۔