یو WireGuard پیر نه رسیږي او بل کار کوي: د ګامونو لیست

یو WireGuard پیر تګ راتګ تېروي او دویم یې لاس ورکول بشپړوي خو هېڅکله د تونل شاته هيڅ شي ته نه رسېږي۔ کار کوونکی پیر تاسو ته وایي چې انټرفیس، UDP پورټ او د سرور کیلي به سم وي۔ دا د دویم پیر د AllowedIPs، د هغه د داخلي سرچینې پتې یا د دوی ترمنځ د لېږد قواعدو په اړه هیڅ نه وایي۔ لیست په ترتیب سره بشپړ کړئ او په لومړي ګام کې چې شرط یې ناکام شي ودرېږئ۔

ګام 1: هغه لار ولیکئ چې پاکټ باید پرې لاړ شي

په یوه هب کې دوه کلاینټان په خپله یو بل ته نه رسېږي۔ په هب او وړانګو ډیزاین کې سرور پاکټ په wg0 ترلاسه کوي او باید بیا له wg0 څخه بل پیر ته ولېږي، چې د IP لېږد او د لېږد قاعدې ته اړتیا لري۔ په مستقیم پیر-تر-پیر ډیزاین کې هر اړخ ته د بل پای ټکی او د بل د تونل پتې AllowedIPs دننه ته اړتیا وي۔ د هر کونفیګرېشن لوستلو دمخه پریکړه وکړئ چې کوم ډیزاین تصحیح کوئ۔

تمه شوې لار تاسو ته هم وایي چې چېرته وګورئ۔ که پاکټ باید هب تېر کړي، ناکام ګام یا د لېږونکي AllowedIPs دی، یا د هب لېږد، یا د ترلاسه کوونکي AllowedIPs۔ که باید مستقیم ولاړ شي، هب بې اړیکه دی او د دواړو پیرونو د پای ټکي ساحې مهمې دي۔

ګام 2: AllowedIPs په دواړو خواوو کې پرتله کړئ، نه یوازې په یوه

WireGuard AllowedIPs هم د مسیرونو د جدول او هم د لاسرسي لیست په توګه کاروي۔ د لېږلو پر مهال د منزل پته د پیر په AllowedIPs کې لټول کېږي ترڅو تونل وټاکل شي؛ د ترلاسه کولو پر مهال باید داخلي سرچینه پته د لېږونکي پیر AllowedIPs دننه پرېوځي، که نه نو پاکټ غورځول کېږي۔ په هره خوا کې د یوې ساحې نشتوالی هماغه نښه ورکوي: لېږد کار کوي، بار ورکېږي۔

د فایل پرځای ژوندی حالت ولولئ، ځکه چې بیا لوستل ممکن په چوپتیا ناکام شوي وي: sudo wg show wg0 allowed-ips۔ په سرور کې د ناکام پیر ننوتنه باید د هغه د تونل پته ولري، لکه 10.90.0.3/32۔ په کلاینټ کې د سرور پیر ننوتنه باید هغه منزل ولري چې تاسو یې ازموئ، که د هب د تونل پته وي یا لرې فرعي شبکه۔ یو پر بل اوړېدونکې ساحې لټون مبهم کوي او کېدای شي هغه پیر غوره کړي چې تاسو یې نه غوښت، نو هغوی جلا وساتئ۔

ګام 3: داخلي سرچینه پته وګورئ

هغه کلاینټ چې 10.90.0.3 د wg0 له لارې مسیروي خو پاکټونه د خپلې Wi-Fi پتې څخه لېږي، د ترلاسه کوونکي له خوا ردېږي، ځکه چې سرچینه د پیر AllowedIPs سره سمون نه لري۔ تصدیق کړئ چې کرنل په رښتیا څه غوره کوي د ip route get 10.90.0.3 from 10.90.0.2 سره، او د تونل انټرفیس ته ټاکل شوې پته د ip -brief addr show wg0 سره تصدیق کړئ۔

په ترلاسه کوونکي Linux هوسټ کې د بېرته لارې فلټر کول دویمه دروازه ده۔ په هغه انټرفیس کې کلک rp_filter چې بېرته لار ورته اړه لري کېدای شي هغه تونل تګ راتګ وغورځوي چې بېرته لار یې له هغه انټرفیس سره سمون نه لري چې له هغې راغلی۔ د بندولو دمخه اغېزمن ارزښت وګورئ؛ په ډېرو ټوپولوژیو کې سم اصلاح یوه لار ده، نه یو سست فلټر۔

ګام 4: د هب لېږد او بېرته لار بیاکتنه کړئ

که هب باید د پیرونو ترمنځ ولېږي، کرنل ته net.ipv4.ip_forward=1 ته اړتیا ده، او فایر وال باید لېږل شوی بهیر ومني: په wg0 کې دننه، له wg0 څخه بهر، د لېږونکي د تونل پتې څخه تر ترلاسه کوونکي پتې۔ یوه عامه نیمګړتیا دا ده چې د ننوتلو قاعده UDP 51820 مني خو د لېږد قاعده نه لري]، نو لاس ورکول بریالي کېږي او بار مري۔ اغېزمن قواعد د sudo nft list ruleset یا ستاسو د فایر وال مدیر د برابرې قاعدې سره ولیکئ۔

بیا ځواب وګورئ۔ د منزل هوسټ باید لېږونکي ته د بېرته لارې لاره ولري، یا د هب له لارې یا د خپل ګېټوې له لارې۔ که هب د تونل فرعي شبکه هم NAT کوي، تصدیق کړئ چې ژباړه پر لېږل شوي بهیر پلي کېږي او ځواب د حالت له پای ته رسېدو دمخه هب ته رسېږي۔ یو طرفه نیمګړتیا چې د کیلي د ستونزې په څېر ښکاري ډېری وخت همدا بېرته لار ده۔

په پای کې، لاس ورکول له معلوماتو جلا کړئ۔ هغه پیر چې لاس ورکول بشپړوي خو په لویو لېږدونو کې بند پاتې کېږي معمولاً په هماغه لار کې MTU یا MSS ستونزه لري، نه AllowedIPs ستونزه۔ لومړی د کوچني ping سره، بیا د بشپړ اندازې ping سره ازموئ او دواړه پیرونه پرتله کړئ۔

ګام 5: یو شی بدل کړئ او کار کوونکی پیر سوکاله وساتئ

په ناکامه لار کې یوازې یو بدلون وکړئ او دواړه پیرونه بیا ازموئ۔ د هر پیر AllowedIPs له 0.0.0.0/0 سره بدلول هغه پیر د ماتولو ترټولو ګړندې لار ده چې دمخه یې کار کاوه، ځکه چې په هغه انټرفیس کې د ټول تګ راتګ مسیرونو پریکړه بدلوي۔ هماغه یوه ننوتنه سمه کړئ، بیا ولولئ او ژوندی حالت بیا ولولئ۔

ولیکئ کومه لار بریالۍ شوه، کومه ناکامه شوه، او د هر یوه لپاره د کمانډ دقیق تولید۔ هغه پرتله د VPN خرابېدو په اړه له عمومي راپور څخه ډېره ارزښت لري، او بل کس به لومړی هماغه وغواړي۔