Windows VPN-এর ঠিকানা ফিল্ডে পোর্ট কেবল SSTP-এর সাথে কাজ করে

সার্ভার নাম ফিল্ড host:port নয়। PPTP, L2TP ও IKEv2-এর পোর্ট স্থির; SSTP পোর্ট কেবল সম্পূর্ণ https:// URL হিসেবে গ্রহণ করে, আর 443 এগিয়ে পাঠানো বেশি পরিষ্কার।

একটি VPN সার্ভার TCP 10443-এ উত্তর দেয়, Windows-এর অন্তর্নির্মিত ক্লায়েন্টের সঠিক শংসাপত্র আছে, তবুও সংযোগটি DNS টাইমআউটের মতো বিরতির পরে ছিঁড়ে যায়। কারণ সাধারণত ঠিকানা ফিল্ড: সার্ভার নাম বা ঠিকানায় vpn.example.com:10443 লিখলে Windows পুরো স্ট্রিংটি হোস্টনাম হিসেবে পড়ে, কারণ সেই বাক্সটি সাধারণ host:port ইনপুট নয়। পোর্ট সেখানে প্রকাশ করা যাবে কি না তা প্রোফাইলের ব্যবহৃত টানেল ধরনের উপর নির্ভর করে, এবং চারটি ধরনের মধ্যে কেবল একটি মানটিকে এমন কিছু হিসেবে ধরে যা সে পার্স করতে পারে।

কেন ঠিকানা ফিল্ড host:port বাক্স নয়

সেই ফিল্ডের পেছনের প্রোফাইল বৈশিষ্ট্য ServerAddress, এবং প্রতিটি টানেল ধরন নিজেই ঠিক করে স্ট্রিংটির সাথে কী করবে। তাদের তিনটির পূরণ করার পোর্ট প্যারামিটার নেই, তাই কোলন আর একটি সংখ্যা কেবল এমন নামের অক্ষর যা কখনো সমাধান হবে না। চতুর্থটি HTTPS-এ চলে, যেখানে পোর্ট URL-এর অংশ, তাই মানটি এমন রূপে লিখতে হবে যা URL হিসেবে পার্স হয়।

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

স্থির পোর্টযুক্ত তিনটি ধরন

PPTP TCP 1723-এ সংযুক্ত হয় এবং তারপর টানেলটি GRE, IP প্রোটোকল 47-এ বহন করে। L2TP/IPsec টানেলের জন্য UDP 1701 এবং IPsec-এর জন্য UDP 500 ও 4500 ব্যবহার করে, যেখানে 4500 হলো NAT অতিক্রমের পোর্ট। IKEv2-ও UDP 500 ও 4500 ব্যবহার করে। এই প্রোফাইলগুলির কোনোটিই ইন্টারফেসে কোথাও পোর্ট ফিল্ড দেখায় না, এবং কোনোটিই অ-মানক পোর্টে দরকষাকষি করবে না।

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

SSTP-এর URL দরকার, নাম নয়

SSTP ব্যতিক্রম কারণ এটি TLS সেশনের ভেতরে চলে। ফিল্ডটি URL হিসেবে পার্স হতে হবে: প্রথমে https:// স্কিম, তারপর হোস্ট, তারপর কোলন ও পোর্ট। স্কিম ছাড়া Windows মানটিকে সাধারণ নাম হিসেবেই ধরে থাকে এবং কোনো TLS বিনিময়ের আগেই সংযোগ ব্যর্থ হয়।

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

Get-VpnConnection -Name "Corporate SSTP" | Select-Object Name, ServerAddress, TunnelType

ServerAddress ঠিক যা সংরক্ষিত হয়েছিল তা দেখায়। যদি এটি কোলনযুক্ত খালি হোস্টনাম হিসেবে পড়া হয়, তবে প্রোফাইল কখনো URL পায়নি এবং যতবারই আবার চেষ্টা করা হোক এটি ঠিক হবে না।

একই বাক্সে আটকানো ভেন্ডর সিনট্যাক্স

কিছু গেটওয়ে সেই ফিল্ডের জন্য অতিরিক্ত রীতির নথিভুক্ত করে, যেমন পোর্টের পরে যোগ করা realm বা এমন কুয়েরি প্যারামিটার যা শংসাপত্রের আচরণ বদলায়। সেগুলি সেই ভেন্ডরের সার্ভার বোঝে এবং কিছু বিল্ডে তার নিজের ক্লায়েন্টও বোঝে। সেগুলি Windows প্রোফাইল ফরম্যাটের অংশ নয়, এবং অন্তর্নির্মিত প্রোফাইলে আটকালে সাধারণত সেই একই নীরব নাম-ব্যর্থতা হয়।

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

পোর্ট প্রমাণ করুন, তারপর ব্যর্থ ধাপটি পড়ুন

প্রোফাইলকে দোষ দেওয়ার আগে নিশ্চিত করুন যে ক্লায়েন্টের নেটওয়ার্ক থেকে কিছু সেই পোর্টে TCP গ্রহণ করে:

Test-NetConnection vpn.example.com -Port 10443

সাফল্য শ্রোতাকে প্রমাণ করে, SSTP-কে নয়। ওয়েব সার্ভার, রিভার্স প্রক্সি বা লোড ব্যালেন্সার TCP হ্যান্ডশেক সম্পন্ন করে তবুও SSTP বলতে পারে না, তাই সবুজ পরীক্ষা আর লাল VPN বাস্তব সমন্বয়। শংসাপত্রের বিষয়বস্তু প্রোফাইলের নামের সাথে তুলনা করুন, এবং যে বিল্ডগুলিতে এটি থাকে সেগুলিতে RasClient লগ দেখুন, কারণ এটি সাধারণ টাইমআউটের বদলে ব্যর্থ ধাপটি লিপিবদ্ধ করে।

তারপর সেই বিকল্পটি ভাবুন যা সমস্যা নথিভুক্ত করার বদলে সরিয়ে দেয়: বাইরে থেকে TCP 443-কে VPN সার্ভারের 10443-এ পাঠান। তখন ক্লায়েন্ট কোনো পোর্ট ছাড়াই ডিফল্ট প্রোফাইল ব্যবহার করে, যা সাধারণত পরিচালিত বহরের জন্য সবচেয়ে পরিচ্ছন্ন ব্যবস্থা এবং কাস্টম পোর্টকে অভ্যন্তরীণ বিবরণ করে রাখে।

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