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

د لومړي هغه چې نه سمونځ کوي په هغه ځای ودرېږئ، او نورو ته قاعده مه ورزیاتوئ۔

لاس ورکول یوازې تونل ثابتوي

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

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

اورېدونکی او لار ولولئ

په کلاینټ کې ډاډ ترلاسه کړئ چې د سرور د تونل پته تونل ته رغړېږي۔ په سرور کې ډاډ ترلاسه کړئ چې په هغه پته چې کلاینټ کاروي ساکټ شته، او د هغې شاته پروسه هغه ده چې تاسو یې په نظر کې لرله۔

wg show
ip route get 10.66.0.1
ss -lntup | grep -E ':80|:443'
nft list ruleset | grep -A6 'chain input'
curl -vk --max-time 5 https://10.66.0.1/

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

هغه پته چې کلاینټ کاروي د هغې پتې سره پرتله کړئ چې سرور یې په رښتیا د تونل انټرفیس کې لري۔ په هر اړخ کې زوړ ترتیب داسې غوښتنه جوړوي چې په سمه توګه هغه همکار ته رغړېږي چې داسې پته نه لري۔

قاعدې د محلي ننوتون لپاره پلي کړئ، د لېږدولو لپاره نه

که پاکټ ورسېد او ساکټ شته، پاتې پوله د ننوتلو تګلاره ده۔ هغه قاعده چې لېږدولو اجازه ورکوي محلي رسولو اجازه نه ورکوي، او یوه انټرفیس ته محدوده قاعده کېدای شي ستاسو د تمې وړ تونل انټرفیس نوم سره سمون ونه خوري۔

د کوربه پرانیستلو پرځای د نظر وړ خدمت ته په یوه اجازه لرونکي پورټ ازموینه وکړئ۔ بیا د اپلیکیشن خپله اجازه وګورئ: د اجازه لیست، د حساب شرط یا یو ځانګړي کوربه نوم ته تړل کېدل کېدای شي هغه غوښتنه رد کړي چې شبکه په بریالیتوب سره رسولې ده۔

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

د نوم، اندازې او هویت ناکامۍ جلا کړئ

هغه خدمت چې په پته کار کوي خو په نوم ناکامه کیږي د DNS ستونزه ده، او سمون یې په اور لګوونکي کې نه، بلکې په هغه حل کوونکي ترتیب کې دی چې کلاینټ ته لېږل کیږي۔ هغه خدمت چې کوچنیو غوښتنو ځواب وایي خو په لویو ځوابونو کې بند پاتې کیږي د پاکټ اندازې او MTU ته اشاره کوي، چې بشپړه بېله څېړنه ده۔

د غلط کوربه نوم یادونکې HTTPS تېروتنه معمولاً معنا دا ده چې غوښتنه بل خدمت ته رسېدلې، ډېری وخت ځکه چې یو پراکسي یا بل اورېدونکی هغه پورټ لري۔ د سند موضوع ولولئ او د هغه کوربه سره یې پرتله کړئ چې تاسو ورته رسېدل غوښتل۔ دا پرتله کول هېڅ لګښت نه لري او ډېری وخت څېړنه پای ته رسوي۔

ولیږئ چې کومه کنټرول نقطه ناکامه شوه: ساکټ، د ننوتلو قاعده یا د اپلیکیشن تګلاره۔ هغه یوه کرښه د شبکې خرابي د اجازې له پرېکړې جلا کوي۔ دا بل کس هم له هغو پورټونو پرانیستلو منع کوي چې هېڅکله ستونزه نه وه۔

اړوندې مقالې