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 ناکام ہوتا ہے: کچھ بگڑا نہیں، کلائنٹ ایک ہی نیٹ ورک میں نہیں ہیں بس۔ کلائنٹ کام کرنے والا ربط اور جواب نہ دینے والا ساتھی پتہ دیکھتا ہے، جو فائر وال جیسا پڑھا جاتا ہے مگر دراصل پتہ بندی کی ترتیب ہے۔
ہدایت بدلنا سرور کی طرف کی ترمیم اور دوبارہ آغاز ہے، اور یہ پہلے سے کھلے سیشنوں پر نہیں بلکہ اگلے کنکشن پر لاگو ہوتا ہے۔ تبدیلی کا فیصلہ کرنے سے پہلے کلائنٹ دوبارہ جوڑیں۔ اگر آلہ ویب انٹرفیس سے کنفیگریشن دوبارہ بناتا ہے، تو ہدایت، فائل اور تاریخ نوٹ کریں، اور انٹرفیس ہونے پر اسی کے ذریعے ترمیم کریں، کیونکہ دوبارہ تعمیر اگلی بار محفوظ کرنے پر ہاتھ سے کی گئی ترمیم مٹا دے گی۔
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 رینج سے پتہ دینا کلائنٹ کو کیبل پر نہیں بٹھاتا۔ سرور ٹنل اور ایتھرنیٹ کے درمیان راستہ بناتا ہے، اس لیے اس پتے کے لیے 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 کے درمیان راستے سے باہر رکھیں۔