د OpenVPN route-nopull هغه څه چې واقعاً سرور له تېلولو منع کوي
route-nopull تېل شوي لارې او DHCP اختیارونه غورځوي، نه لاس ورکول۔ د دې، pull-filter یا هیڅ نه ترمنځ غوره کړئ، بیا لارې پخپله اضافه کړئ۔
تاسو په کلینټ پروفایل کې route-nopull کېښود ترڅو تونل ستاسو اصلي لاره ونه خوري، او اوس د دفتر فرعي شبکه نه رسېدونکې ده پداسې حال کې چې کلینټ لا هم وایي چې نښلول شوی دی۔ دواړه مشاهدې سمې دي، او هیڅ شی ناکام شو نه دی۔ دا بیرغ کلینټ ته وایي چې هغه لارې او DHCP ننوتنې پرېږدي چې سرور یې تېلوي، کوم چې د زیاتولو پر مهال د ډېرو خلکو د تمې په پرتله تنګ لارښوونه ده۔ پاتې کېدونکی یو کاري تونل دی، پرته له دې نظر چې کوم مقصدونه باید ترې کار واخلي۔
هماغه تشه د دې مقالې د بحث ټول پرېکړه ده۔ یا سرور شبکه بیانوي، یا کلینټ، او بیرغ هغه کار کلینټ ته سپاري پرته له دې چې ستاسو لپاره یې څه وکړي۔
د نښلېدو پر مهال بیرغ څه بندوي
اوښتونکی OpenVPN کلینټ معمولاً د تصدیق وروسته له سرور څخه یوه کڅوړه اخلي: لارې، د اصلي ګېټوې بیا لارښوونه، DNS سرورونه او څو تنظیمي لارښوونې۔ د route-nopull په پلي کېدو سره کلینټ لا هم غونډه مني، لا هم تصدیقنامې ګوري، لا هم د سایفرونو او keepalive په اړه خبرې کوي، او لا هم انټرفیس پورته کوي۔ هغه څه چې غورځوي یې د تېل شوو route کرښو او تېل شوو dhcp-option کرښو پلي کول دي، DNS هم پکې۔
ګډوډي د مړې اپلیکیشن ترڅنګ شنه ښودونکي څخه راځي۔ تونل شته؛ د مقصدونو هغه تونل ته نقشه نشته۔ د کلینټ په حالت پینل کې هیڅ شی «نښلول شوی او لارښوونه کوي» له «نښلول شوی او بېکاره» څخه نه جلا کوي، ځکه چې د تونل له نظره دواړه یو شان حالت دي۔
ولې ژوندی تونل بیا هم هیڅ نشي لارښوونه کولی
انټرفیس د خپل پتې سره څرګندېږي او په نقطه-تر-نقطې لینک کې ډېری وخت له سیال ته د کوربه لارې څخه ډېر ځانګړی څه نه وي۔ شخصي فرعي شبکه یوازې هغه وخت رسېدونکې کېږي کله چې یوه لاره د سم پریفکس سره هماغه انټرفیس ته اشاره وکړي، او د تېلولو له بندېدو سره هغه لاره هیګله نه راځي۔ ډاونلوډ شوی پروفایل هم معمولاً مرسته نه شي کولی، ځکه چې دا د دې انګېرنې پر بنسټ لیکل شوی و چې سرور به همدا معلومات برابروي۔ نو ځکه انټرفیس روغ ښکاره کېدای شي پداسې حال کې چې فرعي شبکه تیاره پاتې کېږي۔
نو د پروفایل لوستل ډېر لږ څه ثابتوي۔ پرځای یې په نښلول شوې ماشین کې روان حالت ولولئ:
ip addr show tun0
ip route show dev tun0
ip route get 10.20.5.10په دوهم امر کې د فرعي شبکې لارې پرته پته د دې ستونزې لاسلیک دی۔ دریم امر بیا د هغې پوښتنې ځواب ورکوي چې کاروونکو ته واقعاً مهمه ده، ځکه چې هغه انټرفیس راپور کوي چې کرنل به د یو ځانګړي مقصد لپاره غوره کړي، نه هغه لیست چې تاسو یې د کارېدو هیله درلوده۔ که دا ستاسو د فزیکي لینک له لارې ځواب ورکړي، تونل په لاره کې نه دی۔
د نومونو حل کېدل د یوې اړوندې دلیل له امله ناکامېږي، نه د جلا دلیل له امله۔ تېل شوې dhcp-option DNS ننوتنې په هماغه بیرغ پرېښودل کېږي، نو د داخلي کوربه ګانو پوښتنې هغه حل کوونکي ته ځي چې ځایي شبکه برابره کړې وي۔ هغه حل کوونکی د دفتر لپاره زون نه لري، نو پوښتنه ناکامېږي یا عامه ځواب ورکوي، او نیمګړتیا د سرور د ستونزې په څېر ښکاري پداسې حال کې چې دا د کلینټ د ترتیب ستونزه ده۔ له نوم څخه دمخه د پتې ازموینه هماغه څه ده چې دواړه جلا کوي۔
د بیرغ او د پریفکس فلټر ترمنځ غوره توب
دواړه اختیارونه د یوې شکایت بېلابېل شکلونه حل کوي، او بد غوره توب هماغه «نښلول شوی خو بېګټه» حالت جوړوي۔ یو تېل شوې تګلاره په بشپړه توګه بدلوي، بل یې د پریفکس له مخې سمون کوي۔ جدول لنډه بڼه ورکوي، او ترې وروسته پراګراف هغه برخه پوښي چې خلک نیسي۔
| Setting | What the client keeps | Reasonable when |
|---|---|---|
| no option | every pushed route and DHCP entry | the server's view of the network is correct |
route-nopull | the session, none of the pushed routing or DNS | you will write the full local policy yourself |
pull-filter | everything except lines matching your prefixes | the push is nearly right and one or two lines are wrong |
pull-filter د دریو فعلونو سره د پریفکس سمون ورکوونکی دی، نو کولای شي د کرښو یوه کورنۍ ومني، په غلې توګه یې له پامه وغورځوي، یا د پریفکس د ښکارېدو پر مهال اړیکه په بشپړه توګه رد کړي۔ هماغه وروستی چلند د پېژندنې وړ دی: د ردولو قاعده د تګلارې اختلاف په ناکامه لاس ورکولو بدلوي، نه په غلې پرېښودنې۔ د OpenVPN 2.6 لارښود منل شوي پریفکسونه او د هر فعل دقیق مانا لیست کوي۔
یو عام منځنی لار دا ده چې یوازې redirect-gateway رد کړئ او د دفتر لارې او DNS د موخې مطابق راځي۔ دا تېلول د هغو برخو لپاره کاري ساتي چې سرور یې له تاسو ښه پوهېږي، او په هماغه وخت هغه یوه کرښه منع کوي چې ستاسو اصلي لاره به ونیسي۔
په لاس لارې او حل کوونکی اضافه کول
که بیرغ وساتئ، پروفایل باید هغه څه ووایي چې سرور به یې ویل۔ په کلینټ اړخ کې route لارښوونې د اړیکې له ټینګېدو وروسته پلي کېږي، نو د بیرغ ترڅنګ کار کوي، د هغې له خوا بندېږي نه۔ هغه په پروفایل کې کېږدئ، په متقابل امر کرښه کې نه، که نه نو بله بیا نښلېدنه کاري حالت بیا نه جوړوي۔
route-nopull
route 10.20.0.0 255.255.0.0
dhcp-option DNS 10.20.0.53DNS کرښه په نااسانه ځای کې ده: دا د کلینټ اړخ لارښوونه ده، خو ځینې کلینټونه یې یوازې د پلیټفارم د DNS یوځای کېدو له لارې پلي کوي، کوم چې د لینک د بدلېدو پر مهال پرې لیکلی شي۔ په systemd کوربه کې حل کوونکی په مستقیمه توګه د تونل انټرفیس ته ټاکل له دې هیله ډېر وړاندوینې وړ دي چې کلینټ به د لومړیتوب سیالي وګټي:
resolvectl dns tun0 10.20.0.53
resolvectl domain tun0 ~corp.example.comد لارښوونې ډومېن د پتې په اندازه مهم دی۔ پرته له دې، د عامه نومونو پوښتنې هم کېدای شي داخلي حل کوونکي ته ولېږل شي، او هر داخلي حل کوونکی چې تکرار ردوي به د شخصي زون د کارېدو پر مهال براوزینګ مات کړي۔ ورسره یوازې د هغه پسوند لاندې نومونه تونل حل کوونکي ته لارښوونه کېږي او نور ټول فزیکي لینک تعقیبوي۔
د پایلې کتنه: پته، نوم او بهرنۍ لاره
درې ازموینې ممکنه ناکامۍ جلا کوي۔ لومړی د IP له مخې شخصي پته واخلئ، بیا په نوم هماغه کوربه، بیا یو عادي عامه وېبپاڼه۔ کاري IP او ناکام نوم حل کوونکي ته اشاره کوي؛ ناکام IP او کاري نوم لارښوونې ته اشاره کوي؛ دواړه ناکامېدل معمولاً مانا دا ده چې تونل په لاره کې نه دی۔
بیا بهر ته وګورئ نه دننه۔ د تونل د پای نقطې خپله لاره باید بدلون ته زغم وکړي، او هر بندوونکی ناکامي باید د پای نقطې له نیولو پرته تونل ته محدوده وي۔ هغه کلینټ چې د تونل له لوېدو وروسته هم براوزینګ ته دوام ورکوي د لارښوونې نه، د تګلارې ستونزه ده، او به پورتنې درې ازموینو کې هیڅ کې نه ښکاري۔
وروستی لیست د پروفایل په اسنادو کې ولیکئ: لارې، حل کوونکی، ډومېنونه او د هر یو د شتون دلیل۔ هماغه جدول بیا جوړوونکې بیا نښلېدنه یوازینی ثبوت دی چې ځایي تګلاره بشپړه ده۔ که تونل پورته وي او درې واړه ازموینې تېرې شي خو اپلیکیشنونه لا هم ناکامېږي، بله کتنه ځای مخکې تصدیق شوې تصدیقنامې نه، بلکې «نښلول شوی خو آفلاین» ستونزو ټولګه ده۔