د یوې کوربه څخه د TCP او UDP له لارې OpenVPN وړاندې کول
2.7 څخه مخکې یو بهیر یوازې یو لېږد تړي۔ په پل تړل شوې TAP جوړه، دوه TUN فرعي شبکې او ګډ حوض پرتله کړئ، بیا هر پروفایل خپل اورېدونکي ته ورسم کړئ۔
هغه شبکې چې یوازې TCP 443 ته اجازه ورکوي، له هغو شبکو سره یوځای ژوند کوي چې UDP بې ستونزې تېروي، او یو سرور باید دواړو ته خدمت وکړي۔ proto udp لرونکی پروفایل دویمې ډلې ته ځواب وایي او په لومړۍ کې ناکامېږي، او د همدې ترتیب بدلول چې proto tcp ووایي، دویم اورېدونکی نه جوړوي۔ لارښود یوې بهیر لپاره یوازې یو لېږد غوره کوي۔ نور هر څه له همدې محدودیت څخه راځي۔
یا له یوې زیاتې بهیرونه چلوئ، یا هغه نسخه چلوئ چې په یو وخت کې څو ساکټونه تړلی شي۔
2.7 څخه مخکې یو بهیر یوازې یو لېږد تړي
د ټولنې OpenVPN هغه ساکټ تړي چې proto یې بیانوي، او هغه لارښود د نمونې لپاره یوازې یو لېږد غوره کوي۔ TCP او UDP بېل سټکونه دي، نو یو شمېر پورټ کولی شي دواړه په یو وخت کې ونیسي، خو یو بهیر نه شي کولی۔ له همدې امله د 2.6 کرښه تاسو ته د هر ډیمون لپاره یو لېږد درکوي۔ OpenVPN 2.7 دا محدودیت د سرورونو لپاره لرې کړ، چې کولی شي په یو بهیر کې د څو --local بیانونو له لارې څو ساکټونه وتړي۔
مخکې له دې چې د کوم ځواب په شاوخوا ډیزاین وکړئ، نسخه وګورئ، ځکه چې د 2.7 ترتیب بېل عملیاتي ماډل دی چې خپل کنفیګریشن سینټکس لري۔ د 2.6 لپاره لیکل شوی لارښود دوه بهیرونه بیانوي، حتی کله چې داسې نه وایي۔
د دوو نمونو چلولو درې لارې
د TAP انټرفیسونو سره، د هر لېږد لپاره یوه نمونه چلوئ او په کوربه کې دوه tap وسیلې په پل سره ونښلوئ۔ دواړه کلاینټ ډلې په یوه خپرېدونکې ډومېن کې پای ته رسېږي، چې یوې پته حوض ته اجازه ورکوي چې دواړه پوښ کړي او پر خپرېدو ولاړ پروتوکولونه کار ته دوام ورکړي۔ د TUN سره پل نه شته، نو تر ټولو ساده وېش هرې نمونې ته خپله فرعي شبکه ورکوي او لارښوونه دواړه کلاینټ ډلې جلا ساتي۔ دریم انتخاب یو حوض ساتي: هر بهیر learn-address سکریپټ غواړي چې د همدې نمونې وسیلې له لارې کلاینټ ته /32 لار نصبوي۔
همدا دریم ترتیب هغه دی چې خلک یې غواړي او هغه دی چې تر ټولو زیات پام غواړي، ځکه سکریپټ د معلوماتو د لارې برخه کېږي او باید د زیاتولو، تازه کولو او ړنګولو پېښې سمې اداره کړي۔
| Arrangement | Interfaces | Address pool | Cost |
|---|---|---|---|
| Bridged TAP pair | Two tap devices joined by a bridge | One shared pool | Broadcast traffic and bridge maintenance |
| Two TUN subnets | Two tun devices, no bridge | One pool per instance | Routing rules and two plans |
| Shared pool with routes | Two tun devices plus a hook | One pool across both | A script on the data path |
دواړه نمونې جلا وساتئ
هره نمونه بېل پورټ یا پته، بېل حالت فایل او بېل لاګ منزل هم غواړي۔ دوه ډیمونونه چې یو حالت فایل ته زیاتوي، داسې وتنې جوړوي چې د پېښې پر مهال لوستل کېدای نه شي، او هماغه وخت ورته اړتیا وي۔ که دویمه نمونه ځانګړې پته وتړي، هغه پته باید د بهیر د پیل پر مهال په کوربه کې وي؛ که نه، مخکې له دې چې د کیليو په اړه څه ووایي، د تړلو په ناکامۍ وځي۔
د واحدونو او پروفایلونو نومونه داسې وټاکئ چې لېږد د فایل له نوم څخه څرګند وي۔ بل چلوونکی باید د دې پوهېدو لپاره چې کوم یو TCP دی کنفیګریشن پرانیزي۔
پروفایل له اورېدونکي سره ورسم کړئ
proto tcp چلوونکی سرور د proto tcp-client لرونکي کلاینټ پروفایل تمه لري، او هغه پروفایل چې لا هم proto udp لري، د همدې اورېدونکي پر وړاندې پرته له هغې تېروتنې چې کاروونکی پرې اقدام وکړي، وخت تېرېږي۔ که ځای پر ځای کول دواړه لېږدونه وړاندې کوي، دوه پروفایلونه وساتئ او داسې نښانې کړئ چې ملاتړ پوه شي کوم یو ازمویل شوی۔ یوازې د پورټ شمېره لېږد نه بیانوي۔
د اورېدې دېوال قاعدې همدا وېش تعقیبوي: د UDP 1194 قاعده د TCP 1194 په اړه څه نه وایي، او د یوې پتې قاعده بله اورېدونکې نه پوښي۔
لومړی د سرور انځور ولولئ
په سرور کې د ss -lntup سره پیل وکړئ او تایید کړئ چې د TCP او UDP دواړه اورېدونکي ښکاري۔ بیا د هر ډول یو کلاینټ ونښلوئ او د بېلو پتو لرونکو دوو ننوتلو لپاره د حالت وتنه وګورئ۔ که ساکټونه شته او کلاینټ نه راځي، لاره یا اورېدې دېوال مخکې له دې چې ډیمون یې وویني، بستې ردوي۔
هغه ساکټ چې هېڅکله نه ښکاري، د کنفیګریشن یا تړلو ستونزه ده، او هغه ساکټ چې ښکاري خو هېڅکله اړیکه نه ثبتوي، د فلټر ستونزه ده۔ له کلاینټ څخه دواړه یو شان ښکاري، له همدې امله د سرور خپل انځور لومړی راځي۔ په یاد ولرئ چې TCP د کرښې د سر بلاکینګ لري، نو وړاندې کول یې د پاک UDP لار لرونکو کلاینټونو لپاره لوړوالی نه، بلکې د رسېدو اقدام دی۔