د NAT شاته OpenVPN کلاینټ څنګه د انټرنیټ وتل کیږي

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

لاندې برخه د ترتیب ترتیب نه، د پاکټ لاره تعقیبوي، ځکه چې ترتیب هغه وخت مانا لري چې پوه شئ کوم برخه کومه پرېکړه کوي۔ هر پوړ دقیقاً یوه پرېکړه لري، او تېروتنې هغه ځای کې راټولیږي چې دوه پوړونه یو ګڼل کیږي۔

دوه لیږد غونډې، یوه داخلي لاره

هر کوربه هب ته خپله بهرنۍ اړیکه ساتي، او هېڅ یوه یې د بل په اړه نه پوهیږي۔ د کارونکي انټرنیټ ته ټرافیک یو جلا داخلي بهیر دی چې د کارونکي تونل کې وړل کیږي او بیا د وتلو له تونل څخه بیا بهر کیږي۔ هب باید همدا داخلي بهیر روټ کړي، او وتل باید همدا لیږد کړي۔

outer: consumer --TLS--> hub
outer: exit     --TLS--> hub
inner: consumer --tun--> hub --internal--> exit --tun--> uplink

څرنګه چې دواړه بهرنۍ اړیکې د کلاینټ له اړخ څخه بهر ځي، د وتلو روټر هېڅکله د ننوتلو SYN نه ویني او هېڅکله د منزل NAT اصولو ته اړتیا نه لري۔ یوازې باید جوړه شوې لیږد ژوندی وساتي، کوم چې دا د هر اوږدې اړیکې لپاره لا دمخه کوي۔ په عامه انټرنیټ کې هیڅ شی باید لومړی وتل ته ورسیږي، ځکه چې په هغه پورته لینک کې متحرک پته ستونزه نه ده۔ روټر باید لا هم بهر وتونکې غونډې ته اجازه ورکړي، مګر دا هغه اجازه ده چې براوزر لا دمخه کاروي۔

iroute په سرور کې واقعاً څه نصبوي

هب یوازینی وسیله ده چې پرېکړه کوي کوم ملګری د کوم منزل مالک دی، او دا پرېکړه په کرنل کې نه، بلکې په خپل کارونکي فضا روټینګ جدول کې کوي۔ د وتلو لپاره د exit-node په نوم client-config-dir ننوتنه کولی شي هلته د پیش فرض مخکښ ادعا وکړي:

# /etc/openvpn/server/ccd/exit-node
iroute 0.0.0.0 0.0.0.0

هغه کرښه سرور پروسې ته وایي "د هر منزل سره داخلي پاکټونه دې کلاینټ پورې اړه لري"۔ دا د هب آپریټینګ سیسټم ته پیش فرض لاره نه زیاتوي او هب د انټرنیټ ګېټوې نه جوړوي۔ د OpenVPN 2.6 حواله د کلاینټ ځانګړی داخلي روټینګ او د کرنل روټینګ د جلا میکانیزمونو په توګه ساتي، او همدا جلاوالی لامل دی چې دا طرحه د هب پیش فرض لارې ته د لاس رسولو پرته کار کوي۔

کارونکي ته د هندارې غوندې لارښوونه اړینه ده، د push په توګه رسول شوې، ترڅو د هغې خپل ټرافیک د سیمه ایز ګېټوې له لارې د وتلو پرځای تونل ته ننوځي۔ په فرعي شبکه توپولوژي کې پول د وتلو tun وسیلې باندې تړلې لاره ده، نو د بیرته راستنیدو لوري ته اضافي push ته اړتیا نشته; هغه څه چې وتل باید ترلاسه نه کړي هغه لاندې ریدایرکشن دی، کوم چې د هغې خپل پورته لینک ټرافیک هغه تونل ته بیرته لیږي چې غواړي یې وکاروي۔ دا یوازې کارونکي ته ولیږئ او د CCD فایل غوره شوي په ګڼلو باندې د باور پرځای په کلاینټ کې تطبیق شوې لارې ولولئ۔

# /etc/openvpn/server/ccd/consumer-01
push "redirect-gateway def1"

لیږد د وتلو کرنل کوي

د وتلو په داخل کې د کارونکي پاکټ د tun انټرفیس ته د یوه انټرنیټ کوربه پتې سره رسیږي۔ کرنل خپل روټینګ جدول ګوري، د غوره سمون په توګه ریښتینی پورته لینک مومي او بیا دوه خپلواکې تګلارې پلي کوي: آیا دا پاکټ په بشپړه توګه لیږدیدلی شي، او آیا دا د هغه انټرفیس له لارې د هغې سرچینې پتې سره ووتلی شي۔ لیږد یو sysctl دی، او په ډیرو ویشونو کې په پیش فرض ډول بند وي۔

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

د بیرته راستنیدو لاره د سرچینې ژباړه اخلي

انټرنیټ کوربه 10.90.0.x پتې ته هیڅ لاره نه لري، نو ځوابونه به د وتل تر رسیدو دمخه وشړل شي۔ د پاکټ د پورته لینک د پرېښودو پر مهال سرچینه بیا لیکل دا حل کوي، او د اړیکو تعقیب د بیرته راستنیدو پر مهال هغه بیا لیکل بیرته اړوي۔

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s 10.90.0.0/24 -o enp1s0 -j MASQUERADE
ip -4 route get 10.90.0.9   # run on the exit: must point at the tun

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

هب چېرته پلي کولی شي او چېرته نه

د client-to-client او دودیز کارونکي فضا د معلوماتو لارې سره هب سرور پروسې په داخل کې د ملګرو ترمنځ داخلي پاکټونه سپاري۔ دوی هېڅکله د هب د کرنل FORWARD ځنځیر نه تېریږي، نو هلته کرنل اصول څومره هم په احتیاط لیکل شوي وي د ملګرو ترمنځ تګ راتګ محدودولی نه شي۔ پلي کول باید د سرور په خپله تګلاره کې وي: چاته د نښلولو اجازه ده، کوم CCD فایل ترلاسه کوي، او آیا د وتلو پیش فرض مالکیت په بشپړه توګه ورکول کیږي که نه۔

ځکه چې پیش فرض iroute پراخه باور پرېکړه ده۔ وتل باید د خپل سري انټرنیټ پتو څخه بیرته راستنیدونکی ټرافیک په قانوني توګه ومني، او باید هغه ماشین وي چې تاسو یې کنټرول، تازه او څارنه کوئ۔ هماغه مالکیت داسې ملګري ته ورکول چې تاسو به روټر ورته نه سپارئ هماغه تېروتنه ده چې دا طرحه بلنه ورته کوي۔

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

د وتلو د ورکیدو پر مهال په خوندي ډول ناکامیدل

وتل آفلاین کړئ او داخلي پیش فرض مالکیت د هغې غونډې سره ورکیږي۔ هغه څه چې نه باید پیښ شي دا دي چې هب په خاموشۍ کې بدیل وتل شي: د VPN پول څخه د هب پورته لینک ته هیڅ پیش فرض لاره نه، او په هب باندې هیڅ پراخه ماسکریډ اصول نه چې هماغه ټرافیک په خوښۍ لیږد کړي۔ هغه ناکامي په قصد وګورئ، بیا د لا مخکې خلاص پاڼې پرځای د نوي بهیر سره بیا رغونه وګورئ۔

# on the consumer, with the exit up and then down
ip -4 route get 1.1.1.1
curl -sS -o /dev/null -w '%{http_code}\n' https://example.com

که د وتلو له تلو وروسته هم د کارونکي ټرافیک انټرنیټ ته رسیږي، نو بل څه یې وړي او ستاسو ټاکل شوې پوله نشته۔ DNS او IPv6 هم د جلا پرېکړو په توګه وګورئ: IPv4 لاره او ماسکریډ د AAAA ټرافیک په اړه هیڅ نه وایي، او هب لخوا ټېله شوې حل کوونکې به له هماغه ځایه ځواب ووایي چې پوښتنه واقعاً ورځي۔