OpenVPN ক্লায়েন্টরা একে অপরকে দেখতে পায় না: সাবনেট না net30?
ক্লায়েন্টরা সার্ভারে পৌঁছায় কিন্তু একে অপরের কাছে নয়। একটি ping দিয়ে ত্রুটিটি আলাদা করুন, তারপর সাবনেট টপোলজি, client-to-client বা ব্রিজ করা TAP সেগমেন্ট বেছে নিন।
দুটি সম্পর্কহীন ত্রুটি একই অভিযোগ তৈরি করে। প্রথমটিতে একজন ক্লায়েন্ট অন্যজনের কাছে টানেল ঠিকানা দিয়েও পৌঁছায় না, কারণ ঠিকানাগুলো একই সাবনেটে নয় বা সার্ভার পিয়ার ট্রাফিক ফরওয়ার্ড করছে না। দ্বিতীয়টিতে ping কাজ করে কিন্তু অ্যাপের ডিভাইস তালিকা খালি থাকে, কারণ ডিসকভারি নির্ভর করে ব্রডকাস্টের উপর যা 3 স্তরের টানেল বহন করতে পারে না। একটি ping দুটিকে আলাদা করে, আর প্রতিটির সমাধান অন্যটির সমাধানের মতো নয়।
একটি ping সমস্যাটিকে দুই ভাগে ভাগ করে
একটি ক্লায়েন্ট থেকে অন্যটির টানেল ঠিকানায় ping করুন, তার নামে নয় এবং তার LAN ঠিকানায় নয়। যদি ব্যর্থ হয়, ফরওয়ার্ডিং বা অ্যাড্রেসিং সমস্যা এবং ঠিক না হওয়া পর্যন্ত ডিসকভারি অপ্রাসঙ্গিক। যদি সফল হয়, ফরওয়ার্ডিং আগেই কাজ করছে এবং বাকি ফাঁকটি ব্রডকাস্ট বা নাম রেজোলিউশন।
ip addr show tun0সবার আগে ক্লায়েন্ট ইন্টারফেসটি পড়ুন, কারণ নেটমাস্কই টপোলজির নাম বলে। /24 বা অন্য সাবনেট মাস্ক মানে শেয়ার করা পুল; পিয়ার ঠিকানাসহ /30 মানে পুরোনো পয়েন্ট-টু-পয়েন্ট বিন্যাস, যেখানে প্রতিটি ক্লায়েন্টের ঠিক একজন প্রতিবেশী থাকে, সার্ভার।
net30 বনাম সাবনেট, ক্লায়েন্টের দিক থেকে পড়া
| 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-এ সার্ভার প্রতিটি ক্লায়েন্টকে ছোট একটি ব্লক দেয়, তাই অন্য ক্লায়েন্টের টানেল ঠিকানায় রুট থাকে না যদি না সার্ভার সেটি ফরওয়ার্ড করে। সাবনেটে পুরো পুল একটি নেটওয়ার্ক, প্রতিটি ক্লায়েন্ট প্রত্যেকের সাথে কথা বলতে পারে, আর সার্ভার তাদের মধ্যে ফরওয়ার্ড করে। এজন্যই একটি সার্ভার কনফিগারেশন সুস্থ দেখাতে পারে অথচ পিয়ার ping ব্যর্থ হয়: কিছুই নষ্ট নয়, ক্লায়েন্টরা শুধু এক নেটওয়ার্কে নয়। ক্লায়েন্ট একটি কাজ করা লিঙ্ক আর উত্তরহীন পিয়ার ঠিকানা দেখে, যা ফায়ারওয়ালের মতো শোনায় কিন্তু আসলে একটি অ্যাড্রেসিং বিন্যাস।
ডিরেক্টিভ বদলানো মানে সার্ভার পাশে সম্পাদনা ও রিস্টার্ট, এবং এটি ইতিমধ্যে চালু সেশন নয়, পরবর্তী সংযোগে প্রযোজ্য। পরিবর্তনের বিচার করার আগে ক্লায়েন্টদের আবার সংযোগ করুন। কোনো অ্যাপ্লায়েন্স ওয়েব ইন্টারফেস থেকে কনফিগারেশন পুনরুত্পাদন করলে ডিরেক্টিভ, ফাইল ও তারিখ লিখে রাখুন এবং ইন্টারফেস থাকলে সেটির মাধ্যমেই সম্পাদনা করুন, কারণ পুনর্নির্মাণ পরবর্তী সেভে হাতে করা সম্পাদনা মুছে দেবে।
client-to-client আলাদা একটি গেট
একই সাবনেটের ভেতরেও সার্ভার এক ক্লায়েন্ট থেকে আসা ও অন্যজনের ঠিকানায় যাওয়া প্যাকেট ফেলে দেয়, যদি client-to-client সেট না থাকে। ওই কীওয়ার্ড সার্ভারকে পিয়ার ট্রাফিকের ফরওয়ার্ডারে পরিণত করে, কেবল গ্রহণ করা এন্ডপয়েন্টে নয়। টপোলজি ঠিক করার পর মানুষ যে দ্বিতীয় শর্তটি মিস করে, সেটি এটিই।
এটি ব্রডকাস্ট পর্যন্ত বিস্তৃত নয়। সেটিংটি ক্লায়েন্টদের মধ্যে ইউনিকাস্ট ফরওয়ার্ড করে; এটি টানেলকে শেয়ার্ড সেগমেন্টে পরিণত করে না, এবং এর কোনো পরিমাণই মাল্টিকাস্ট ডিসকভারি কোয়েরি প্রতিটি পিয়ারে পৌঁছাবে না।
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-এ ব্রিজ করলে দূরবর্তী ক্লায়েন্টরা অফিসের ব্রডকাস্ট ডোমেইনে ঢুকে পড়ে, যা ডিসকভারি সম্পূর্ণ সমাধান করে। দাম হলো যে প্ল্যাটফর্মগুলো TAP প্রয়োগ করে না, সার্ভারে থাকতে হয় এমন একটি ব্রিজ, এবং একটি ব্যর্থতার ডোমেইন যেখানে অফিসের তারে ব্রডকাস্ট ঝড় প্রতিটি দূরবর্তী ল্যাপটপে পৌঁছায়।
নাম রেজোলিউশন দরকার এমন দুই বা তিনটি ওয়ার্কস্টেশনের জন্য hosts এন্ট্রি বা ইউনিকাস্ট ঠিকানা ব্রিজের চেয়ে অনেক সস্তা। TAP-এর দিকে হাত বাড়ান যখন আপনি যা বদলাতে পারেন না এমন একটি প্রোটোকল 2 স্তরের ডিসকভারির উপর নির্ভর করে, এবং তার আগে নয়।
ব্রিজ ছাড়া একই সাবনেটের ক্লায়েন্ট
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 সমর্থন করলে তবেই TAP ব্যবহার করুন।
- একই সাবনেটে পৌঁছানো গুরুত্বপূর্ণ হলে টানেল ও LAN-এর মধ্যে NAT রাখবেন না।