Mac VPN-এর utun ইন্টারফেস চালু, কিন্তু ট্রাফিক যাচ্ছে না? ifconfig দেখুন

আপনি VPN-এ সংযোগ করলেন, ifconfig চালালেন এবং তার উপর একটি ঠিকানা নিয়ে utun4 এন্ট্রি পেলেন। যে সাইটটি দরকার ছিল সেটি এখনও সাড়া দিচ্ছে না। এই ফাঁক স্বাভাবিক: তালিকাটি প্রমাণ করে একটি ভার্চুয়াল ইন্টারফেস আছে, কিন্তু আপনার ক্লায়েন্ট সেটি ধরে আছে, আপনার দরকারের রুটটি সেটিকেই বেছে নেয়, বা প্যাকেটগুলো সেটির ভেতর দিয়ে যাচ্ছে—তা প্রমাণ করে না। কোনো কিছু ইনস্টল করার আগেই যে ল্যাপটপে তিনটি utun এন্ট্রি ছিল, সেখানে ভুল টানেলকে দোষ দেওয়ার এক দুপুর কাটানোর পর আমি ইন্টারফেসের নামে ভরসা করা ছেড়ে দিয়েছি।

utun লাইনে আসলে কী থাকে

পুরো চিত্র দেখতে চাইলে ifconfig -a চালান। কোনো আর্গুমেন্ট ছাড়া ডাকা হলে ifconfig কেবল তখন সক্রিয় থাকা ইন্টারফেসগুলো ছাপে, তাই যে টানেল শুরু হয়নি সেটি লোকে টিকিটে যে আউটপুট পেস্ট করে তা থেকে বাদ পড়তে পারে। ifconfig -l কেবল নামগুলো ফেরত দেয়, আর সংযোগ করার পর নতুন utun দেখা গেল কি না তা বোঝার সবচেয়ে দ্রুত উপায় এটিই।

একটি ইন্টারফেস পড়াই হলো সেই জায়গা যেখানে কাজের বিস্তারিত থাকে। একটি সংযুক্ত টানেল সাধারণত এমন দেখায়:

utun4: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1380
    inet 10.8.0.6 --> 10.8.0.5 netmask 0xffffffff
    inet6 fe80::ce81:b1c:bd2c:69e%utun4 prefixlen 64 scopeid 0x15

তিনটি ফিল্ডই উত্তর বহন করে। UP এবং RUNNING বলে যে কার্নেল ইন্টারফেসটি ব্যবহার করতে রাজি। POINTOPOINT আর সঙ্গী ঠিকানা --> একসাথে ভৌত লিঙ্ক নয়, একটি টানেলের স্বাক্ষর। mtu মানটি «সংযোগ হয়, তারপর থেমে যায়» ধরনের পুরো এক শ্রেণির প্রতিবেদন ব্যাখ্যা করে, কারণ utun ইন্টারফেস সাধারণত কমিয়ে দেওয়া MTU নিয়ে ওঠে, কয়েকটি macOS বিল্ডে 1380, আর ক্লায়েন্ট সেটি অতিক্রম করতে পারে। ফিল্ডের তালিকাটি এত ছোট যে Apple-এর দেওয়া ifconfig ম্যানুয়ালে একবার চোখ বুলিয়ে দেখা যায়।

ইন্টারফেসের পেছনের প্রসেসটি খুঁজুন

ifconfig-এর মালিক অ্যাপ্লিকেশন বলে কিছু নেই। দুটি VPN ক্লায়েন্ট, একটি সিস্টেম সার্ভিস আর গত সপ্তাহের পড়ে থাকা একটি টানেল—সবই এই স্তরে একই রকম দেখতে এন্ট্রি তৈরি করে। আমার নিজের Mac-এ আমি কিছু সেট করার আগেই utun0 থেকে utun3 পর্যন্ত ছিল; Continuity আর iCloud Private Relay-ও টানেল ব্যবহার করে, আর তার কোনোটিই আপনার তদন্ত করা সংযোগ নয়।

যে টানেলগুলো সিস্টেমে একটি কনফিগারেশন নিবন্ধন করে, সেগুলোর জন্য scutil --nc list সবচেয়ে দ্রুত সংযোগসূত্র। এটি প্রতিটি কনফিগারেশন তার স্ট্যাটাস ও সার্ভিস আইডিসহ ছাপে, আর সংযুক্তটি এমনভাবে চিহ্নিত হয়:

scutil --nc list
* (Connected)   5F2A9C10-...   VPN  Work IKEv2

যে ক্লায়েন্টরা কনফিগারেশন নিবন্ধন না করে নিজেদের টানেল প্রসেস চালায়, তারা সেখানে কখনও দেখা যায় না। Tunnelblick আর কমান্ড লাইনের একটি openvpn ইনস্ট্যান্স এই দলে পড়ে, তাই প্রসেস টেবিলও দেখুন: ps -Ao pid,comm | grep -i openvpn। একবার কোনো প্রসেস টানেলের মালিক হলে, utun নম্বরটি সেই প্রসেসেরই, আর কারও নয়।

রুট পরীক্ষা করার আগে ঠিকানা পরীক্ষা করুন

একটি ইন্টারফেস ব্যবহারযোগ্য ঠিকানা ছাড়াই সক্রিয় থাকতে পারে। শুধু IPv6 প্রোফাইল একটি লিঙ্ক-লোকাল fe80:: এন্ট্রি দেখায় এবং inet লাইনে কিছুই না, আর পাঠানো ঠিকানা প্রয়োগ করতে ব্যর্থ ক্লায়েন্ট ঠিক একই আকৃতি রেখে যায়। আপনার গন্তব্য IPv4 হলে এবং টানেলে IPv4 ঠিকানা না থাকলে, রাউটিং প্রশ্নটি আগেই মিটে গেছে।

MTU আলাদা যাচাই দাবি করে, কারণ ব্যর্থতাটি আকারের সমস্যার মতো দেখায় না। এটি এমন সংযোগের মতো দেখায় যা প্রমাণীকরণ করে, তারপর বড় স্থানান্তর শুরু হলেই চুপ হয়ে যায়। এমন একটি প্রোব পাঠান যা খণ্ডিত করা যাবে না, আকার এমন যে প্যাকেটটি ইন্টারফেসের MTU-র সঙ্গে মেলে; 1400 MTU-র জন্য পেলোড 1372 বাইট:

ping -D -s 1372 10.8.0.5

উত্তর মানে সেই আকারের প্যাকেটগুলো টানেল পার হয়। ছোট ping সফল হওয়ার সময় নীরবতা MTU-র দিকে বা পথে ICMP ফেলে দেওয়া কিছুর দিকে ইঙ্গিত করে, প্রমাণীকরণের দিকে নয়, কারণ আপনি ইন্টারফেস পাওয়ার আগেই তা শেষ হয়ে গিয়েছিল।

প্রমাণ করুন গন্তব্যই টানেলটি বেছে নেয়

আসল প্রশ্ন utun4 আছে কি না তা নয়, বরং একটি নির্দিষ্ট ঠিকানায় যাওয়া ট্রাফিক সেটির ভেতর দিয়ে বেরোয় কি না। route -n get একটি গন্তব্যের জন্য তার উত্তর দেয় এবং যে গেটওয়ে ও ইন্টারফেস ব্যবহার হবে তা ছাপে:

route -n get 203.0.113.20
  gateway: 10.8.0.5
  interface: utun4

একই কমান্ড যদি en0 জানায়, তবে আপনার স্প্লিট-টানেল কনফিগারেশন যা করতে বলা হয়েছিল তা-ই করছে, আর ইন্টারফেস পরীক্ষা করে তা বদলাবে না। ডিফল্ট রুট আর পুরো টেবিল এক নজরে দেখতে চাইলে netstat -rn -f inet ব্যবহার করুন।

প্যাকেট সত্যিই চলছে কি না তা কাউন্টারই মিটিয়ে দেয়। netstat -ib প্রতি-ইন্টারফেস প্যাকেট ও বাইটের মোট সংখ্যা জানায়, utun এন্ট্রিসহ; সংখ্যাগুলো সঞ্চিত, তাই একটি ফাঁক দিয়ে দুবার পড়ে তুলনা করুন:

netstat -ib | grep utun4

অ্যাপ্লিকেশন বারবার চেষ্টা করছে অথচ কাউন্টার জমে আছে মানে কার্নেল কখনও ইন্টারফেসকে প্যাকেট দেয়নি। অ্যাপ্লিকেশন এখনও ব্যর্থ হচ্ছে অথচ দুই দিকেই কাউন্টার বাড়ছে মানে তদন্ত টানেলের দূর প্রান্তে যাবে।

যখন কোনো utun-ই দেখা যায় না

সফল মনে হওয়া লগইনের পর খালি ইন্টারফেস তালিকা সাধারণত বোঝায় টানেলই শুরু হয়নি, ifconfig তা লুকাচ্ছে তা নয়। আগে ক্লায়েন্টের নিজের স্ট্যাটাস দেখুন, তারপর সিস্টেমের: যে নেটওয়ার্ক এক্সটেনশন কখনও অনুমোদিত হয়নি, বা যা macOS আপডেটের পর নিষ্ক্রিয় করেছে, সেটি পেছনে কোনো ইন্টারফেস রাখে না। অনুমোদনটি থাকে সিস্টেম সেটিংসের Login Items & Extensions-এ, আর সেখানে পুরোনো এন্ট্রি থাকলে কিছু পুনরায় ইনস্টল করার আগে একবার টগল করে দেখা উচিত।

পুনঃসংযোগের মধ্যে utun নম্বরায়ন স্থির নয়। দশ মিনিট আগে utun4 যেখানে ছিল সেখানে আপনি utun5 পেতে পারেন, কারণ পুরোনো ইন্টারফেস ভেঙে ফেলা হয় এবং কার্নেল পরের খালি সূচকটি দেয়। যে স্ক্রিপ্টগুলো নাম হার্ডকোড করে, সেগুলো ঠিক সেই মুহূর্তে নীরবে ভেঙে পড়ে; বরং ঠিকানা বা রুট মিলিয়ে দেখুন।

পড়ার দিকটি শুধু-পড়ার রাখুন। sudo ifconfig utun4 down টানেলটি বিচ্ছিন্ন করে, আর পূর্ণ-টানেল প্রোফাইলে এটি আপনার দূরবর্তী সেশনও নিয়ে যায়, যা কেবল প্রমাণ সংগ্রহ করার সময় খারাপ বিনিময়। এখানে যা দরকার তার কোনো কিছুই root চায় না: ফ্ল্যাগ, ঠিকানা আর কাউন্টার পড়া সবই সাধারণ ব্যবহারকারী হিসেবে কাজ করে।

পরের বার Mac টানেল খারাপ আচরণ করলে ক্রমে যাচাইগুলো করুন: ifconfig -l দিয়ে utun এসেছে কি না নিশ্চিত করুন, তার ফ্ল্যাগ, ঠিকানা ও MTU পড়ুন, এটিকে একটি প্রসেসের সঙ্গে যুক্ত করুন, route -n get-কে জিজ্ঞাসা করুন গন্তব্য কোন ইন্টারফেস ব্যবহার করে, তারপর netstat -ib কীভাবে নড়ে তা দেখুন। প্রতিটি ধাপ আলাদা স্তর বাদ দেয়, আর যে প্রথমটি ভুল হয়ে ফেরে সেখানেই সমাধান।