গেটওয়ে UDP 4443-এ IKEv2-এর উত্তর দেয় একটি কারণে, প্রোফাইলে Server নামে একটি ফিল্ড আছে, আপনি হোস্টনেম ও পোর্ট লেখেন, আর ফোনটি জানায় যে সে সার্ভারে পৌঁছাতে পারছে না বা ঠিকানাটি রিজলভ করতে পারছে না। কিছুই ব্লক হচ্ছে না। অ্যান্ড্রয়েডের নেটিভ ফর্ম একটি হোস্ট আশা করে, এবং Windows-এও একই কথা প্রযোজ্য। কাস্টম পোর্ট সার্ভার সেটিং হওয়ার আগেই ক্লায়েন্টের সক্ষমতা, এবং কেবল কিছু ক্লায়েন্টই এটি প্রকাশ করতে দেয়। তিনটি অংশ ক্রমানুসারে দেখুন: ক্লায়েন্ট কী বলতে পারে, সার্ভার কী শুনছে, এবং দুই প্রান্ত একইভাবে প্যাকেট ফ্রেম করে কি না।

ফোনটি আসলে কী পাঠিয়েছে

নামের জন্য তৈরি ফিল্ডে host:port স্ট্রিং নাম হিসেবেই রিজলভ হয়। রিজলভার vpn.example.net:4443 -এর জন্য কিছু ফেরত দেয় না, আর আপনি যে ত্রুটি দেখেন সেটি পোর্টে টাইমআউট নয়, বরং নাম রিজলভ বা পৌঁছানো না যাওয়ার ব্যর্থতা। এই পার্থক্যটি গুরুত্বপূর্ণ, কারণ ছোট নাম বা ভিন্ন নেটওয়ার্ক দিয়ে আবার চেষ্টা করলে ফর্মটি যে স্ট্রিং পার্স করতে পারে না তা কখনো ঠিক হবে না।

অ্যান্ড্রয়েডের নেটিভ IKEv2 প্রোফাইল, উইন্ডোজের বিল্ট-ইন VPN ক্লায়েন্টের মতোই, স্ট্যান্ডার্ড IKE পোর্টে আটকে আছে। কোনোটিই পোর্ট ফিল্ড দেখায় না, এবং প্রোফাইল সম্পাদনা করে একটি যোগ করা যায় না। যদি অপারেটরের লিসেনার সত্যিই 4443-এ থাকে, তবে বিল্ট-ইন ক্লায়েন্টটি ভুলভাবে কনফিগার করা নয়, বরং ভুল হাতিয়ার।

পোর্ট প্রকাশ করে এমন ক্লায়েন্ট ব্যবহার করুন

strongSwan-এর অ্যান্ড্রয়েড ক্লায়েন্ট তার উন্নত প্রোফাইল সেটিংসে কনফিগারযোগ্য সার্ভার পোর্টের নথি দেয়, তাই এই নকশার প্রায় প্রতিটি কাজ করা রেসিপিতে এটি দেখা যায়। এই সমর্থনটি ওই ক্লায়েন্টের নিজস্ব: অন্য একটি IKEv2 অ্যাপ, বা একই অ্যাপের কোনো ভেন্ডর ফর্ক, একই ফিল্ড নাও দেখাতে পারে, যদিও অন্তর্নিহিত strongSwan ডেমন এটি সমর্থন করে।

অপারেটরের কাছে পুরো সেটটি একবারেই চান: গেটওয়ে নাম, UDP পোর্ট, প্রমাণীকরণ পদ্ধতি, এবং ক্লায়েন্ট যে সার্ভার পরিচয় আশা করবে তা। কাস্টম পোর্ট সার্টিফিকেট যাচাই বন্ধ করা বা প্রোটোকল বদলানোর কারণ নয়। যেখানে ইনস্টল করা ক্লায়েন্ট পোর্টটি আশা করে সেখানেই তা লিখুন, আর যদি সেই ক্লায়েন্টে এমন ফিল্ড না থাকে, তবে উত্তর হলো অন্য একটি অনুমোদিত ক্লায়েন্ট, অনুমান করা কোনো ফাঁকি নয়।

সার্ভারের দুটি পোর্ট, এবং দুটিই মিলতে হবে

IKE UDP 500-এ শুরু হয়, আর NAT ট্রাভার্সাল সাধারণত IKE ও এনক্যাপসুলেটেড ESP-কে UDP 4500-এ সরিয়ে নেয়। এগুলো strongSwan-এ আলাদা সেটিং, তাই একটি কাস্টম পোর্টে সরানো সার্ভারে দুটিকেই একই মানে বদলাতে হবে:

plugins {
  socket-default {
    port = 4443
    port_nat_t = 4443
  }
}

দুই ভূমিকার জন্য একই পোর্ট থাকলে ডেমনকে একই সকেটে IKE-কে ESP-in-UDP থেকে আলাদা করতে হয়, যা সে করে IKE বার্তার আগে আসা চার-বাইটের নন-ESP মার্কার দিয়ে। তাই ক্লায়েন্ট কাস্টম পোর্টে দর-কষাকষি করে পরে চুপচাপ 4500-এ চালিয়ে যেতে পারে না, আর তাই “শুধু পোর্ট বদলান” বাক্যটি ফ্রেমিংয়ের একটি শর্ত লুকিয়ে রাখে।

ফরওয়ার্ড করা মানে লিসেনার নয়

4443-কে একটি সাধারণ IKE লিসেনারে ফরওয়ার্ড করা হলো সেই ব্যর্থতার ধরন যা প্রায় সফল দেখায়। প্রথম বিনিময় আসে, সার্ভার উত্তর দেয়, তারপর সংযোগটি থেমে যায় বা কিছুই না রেখে কী পুনরুৎপাদন করে, কারণ উত্তরটি অন্য পোর্ট থেকে বের হয় এবং পরের এনক্যাপসুলেটেড ট্রাফিক দুই প্রান্ত যে অবস্থা তৈরি করেছিল তার সঙ্গে কখনো মেলে না। লিসেনার না সরিয়ে গন্তব্য পোর্ট পুনর্লিখন করা নিয়ম ঠিক এই অর্ধ-খোলা ফলাফলই দেয়।

পথটিকে UDP-ও প্রান্ত থেকে প্রান্ত পর্যন্ত অনুমোদন করতে হবে। হোটেল বা ক্যারিয়ার নেটওয়ার্ক দিয়ে TCP 443 পার হওয়া UDP পোর্টে IKEv2 সম্পর্কে কিছুই বলে না, এমনকি নম্বর এক হলেও। যেখানে কেবল TCP 443 অনুমোদিত, সেখানে কাস্টম UDP পোর্ট IKEv2-কে HTTPS বানায় না, আর সঠিক উত্তর আরেকটি পোর্ট পরীক্ষা নয়, ভিন্ন একটি অ্যাক্সেস পথ হতে পারে।

পরীক্ষার সময় তিনটি ধাপ আলাদা করুন

ক্লায়েন্ট একবার চেষ্টা করার সময় সার্ভারে ক্যাপচার করুন। যে অনুরোধ কখনো আসে না তা এন্ডপয়েন্ট বা ফায়ারওয়ালের প্রশ্ন; যে অনুরোধ এসে উত্তর পায় না তা লিসেনার বা নীতির প্রশ্ন; আর যে উত্তরের পরে নীরবতা আসে তা ফ্রেমিং বা পরিচয়ের প্রশ্ন।

tcpdump -ni eth0 -vv udp port 4443

তারপর ক্লায়েন্টের ঘুরন্ত চিহ্ন নয়, তার বার্তা পড়ুন। প্রস্তাব ত্রুটি মানে অ্যালগরিদম মেলে না, প্রমাণীকরণ ব্যর্থতা মানে পরিচয় বা সার্টিফিকেট মেলে না, আর উত্তরহীন বারবার পুনঃপ্রেরণ মানে ওই পোর্টে কেউ উত্তর দিচ্ছে না। একবারে একটি ধাপ পরীক্ষা করুন এবং চেষ্টার মাঝে একটি ফিল্ড বদলান; NAT ট্রাভার্সাল নিয়ে strongSwan-এর নথি সেই মার্কার ও পোর্ট আচরণ বর্ণনা করে যা ক্যাপচার আপনাকে দেখাচ্ছে।

সম্পর্কিত নিবন্ধ