د OpenVPN کليانټونه يو بل نه وينې: subnet که net30؟
کليانټونه سرور ته رسېږي خو يو بل ته نه. تېروتنه په يو ping بېله کړئ، بيا د subnet ټوپولوژي، client-to-client يا په پل وتړل شوی TAP برخه وټاکئ.
دوه بې تړاوه تېروتنې يو ډول شکايت پیدا کوي. په لومړۍ کې يو کليانټ بل ته د تونل پتې په واسطه هم نه رسېږي، ځکه چې پتې په يو subnet کې نه دي يا سرور د همکارانو تر منځ ترافيک نه لېږدوي. په دوهمه کې ping کار کوي خو د اپليکېشن د وسايلو لړليک تش پاتې کېږي، ځکه چې پيداکول پر broadcast ولاړ دي چې د 3 طبقې تونل يې نشي وړلای. يو ping دواړه بېلوي، او د هر يوه سمول د بل د سمولو سره هيڅ نه ورته دي.
يو ping ستونزه په دوه ووېشل
له يو کليانټ څخه د بل کليانټ د تونل پتې ته ping وکړئ، نه د هغه نوم ته او نه د هغه LAN پتې ته. که هغه ونشوه، لېږدول يا پته ورکول ستونزه ده او پيداکول تر سمېدو پورې بې اړيکه دي. که بريالی شو، لېږدول لا دمخه کار کوي او پاتې تشه broadcast يا د نومونو حل دی.
ip addr show tun0له هر څه مخکې د کليانټ انټرفېس ولولئ، ځکه چې شبکه يي ماسک ټوپولوژي نوموي. /24 يا بل subnet ماسک يعنې شریکه زېرمه؛ د همکار پتې سره /30 يعنې پخوانی له نقطې تر نقطې ترتيب، چېرې چې هر کليانټ يوازې يو ګاونډی لري، سرور.
net30 د subnet پر وړاندې، د کليانټ له خوا لوستل شوی
| What you observe | net30 | subnet |
|---|---|---|
| Client netmask | /30 with a peer address | The pool's own mask |
| Peers a client can address directly | One, the server | Every client in the pool |
| Addressing | One /30 block per client, with the server as the only peer | One pool mask shared by all clients |
| Effect of client-to-client | Required for any peer traffic | Required for peer traffic, still no broadcast |
په net30 کې سرور هر کليانټ ته کوچنی بلاک ورکوي, نو بل کليانټ ته د تونل پتې لار نشته پرته له دې چې سرور يې ولېږدوي. په subnet کې ټوله زېرمه يو شبکه ده، هر کليانټ هر بل ته اشاره کولی شي، او سرور د دوی تر منځ لېږدوي. له همدې کبله يو سرور ترتيب روغ ښکاري خو د همکارانو تر منځ ping ناکامېږي: هيڅ شی نه دی مات، کليانټونه يوازې په يوه شبکه کې نه دي. کليانټ کار کوونکې اړيکه او بې ځوابه همکار پته ويني، چې د firewall په څېر لوستل کېږي خو په رښتيا د پتې ورکولو ترتيب دی.
د لارښود بدلول د سرور خوا ته سمون او بيا پيل دی، او د راتلونکي اړکېدو لپاره دی نه د لا خلاصو شوو ناستو لپاره. د بدلون د ارزولو مخکې کليانټونه بيا وتړئ. که اله د ويب انټرفېس څخه ترتيب بيا پیدا کړي، لارښود، دوتنه او نېټه ثبت کړئ، او کله چې انټرفېس وي سمون د هغه له لارې وکړئ، ځکه چې بيا جوړول به په راتلونکي خوندي کولو کې لاسي سمون پوښي.
client-to-client جلا دروازه ده
حتی په يوه subnet کې هم سرور هغه پاکټونه غورځوي چې له يو کليانټ څخه راځي او بل ته استول شوي، پرته له دې چې client-to-client ټاکل شوی وي. هغه کليدي کلمه سرور د همکارانو د ترافيک لېږدوونکی جوړوي نه يوازې منونکی پای ټکی. دا دوهم شرط دی چې خلک يې د ټوپولوژي له سمولو وروسته هېروي.
دا broadcast ته نه غځېږي. ترتيب د کليانټونو تر منځ unicast لېږدوي؛ دا تونل شریکه برخه نه جوړوي، او د هغې هيڅ اندازه به د multicast پيداکولو پوښتنه هر همکار ته ونه رسوي.
TUN د TAP پر وړاندې، او هر يو څه وړلای شي
| Property | TUN | TAP |
|---|---|---|
| Layer | Layer 3, IP packets | Layer 2, Ethernet frames |
| Broadcast and multicast | Not carried | Carried |
| Bridging to the LAN | Not applicable | Required for a shared segment |
| Client platform support | Everywhere | Missing on Android and iOS, limited on macOS |
د tap اله په LAN کې پل کول لېرې کليانټونه د دفتر broadcast سيمې ته راولي، چې پيداکول په بشپړه توګه حل کوي. بيه يې هغه پليټ فارمونه دي چې TAP نه پلي کوي، هغه پل چې بايد پر سرور وي، او د ناکامۍ سيمه چېرې چې د دفتر په کېبل broadcast توپان هر لېرې لاپ ټاپ ته رسېږي.
د دوو يا درې کاري سټېشنونو لپاره چې د نومونو حل ته اړتيا لري، hosts ننوتنه يا unicast پته له پله ډېره ارزانه ده. TAP ته هغه وخت ورشئ چې هغه پروتوکول چې بدلولی يې نه شئ د 2 طبقې پيداکولو پورې تړلی وي، او نه له هغه مخکې.
د يوې subnet کليانټونه پرته له پله
له LAN سيمې څخه پته ورکول کليانټ پر کېبل نه کېنوي. سرور د تونل او Ethernet تر منځ لارښونه کوي، نو د هغې پتې ARP د سرور پر انټرفېس ودرېږي او د LAN پاتې برخه هېڅکله نه پوهېږي چې هغه چېرې اوسېږي.
ip neigh add proxy 10.50.1.250 dev eth0Proxy ARP هغه تشه بندوي، سرور د کليانټ له خوا ځواب ورکوي. د سيمې لپاره parpd ننوتنې سمبالوي کله چې کليانټونه راځي او ځي، خو sysctl net.ipv4.conf.eth0.proxy_arp=1 د هر هغه څه ځواب ورکوي چې بلې خوا ته لارښودل کېږي، کوم چې دومره پراخ دی چې په بوخت برخه کې خپل حيرانتیا پیدا کړي.
کومه لار چې وټاکئ، NAT د تونل او کېبل تر منځه لرې کړئ. د MASQUERADE قاعده هماغه د پتې ورکولو پوښتنه پټوي چې ځواب ورکول يې غواړئ. دا بل کس ته هم داسې ټوپولوژي پرېږدي چې د کليانټ له خوا پرې فکر نه شي کولی.
مخکې له دې چې څه بدل کړئ، پر سرور د tcpdump -ni tun0 سره يوه هڅه ونیسئ او تثبيت کړئ چې د همکار پاکټ اصلاً راځي که نه. راتلل او غورځول کېدل client-to-client ته اشاره کوي؛ هېڅکله نه راتلل ټوپولوژي يا لارښونې ته. د OpenVPN 2.6 لارښود دواړه کليدي کلمې او پخواني ټوپولوژي مستند کوي، او د فورم پوسټ څخه کرښه کاپي کولو مخکې له خپلې بڼې سره يې پرتله کول ښه دي.
- tun انټرفېس د /30 همکار جوړه پر ځای د زېرمې ماسک ښيي.
- پيداکول ازمويلو مخکې بلې تونل پتې ته سيمه ييز ping بريالی کېږي.
- کله چې همکاران پاکټونه تبادله کړي، د سرور ترتيب
client-to-clientلري. - د اپليکېشن ناکامېدو ويلو پر ځای هغه پيداکولو پروتوکول ونوموئ چې ازموئ.
- TAP يوازې هغه وخت وکاروئ چې په ډله کې هر کليانټ پليټ فارم يې ملاتړ کوي.
- کله چې په يوه subnet کې رسېدنه مهمه وي، NAT د تونل او LAN تر منځ له لارې بهر وساتئ.