এসএসএইচ রিমোট পোর্ট ফরওয়ার্ডিং ব্যর্থ হয়েছে

Question

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

আমার ফায়ারওয়ালের পিছনে একটি সার্ভার রয়েছে (এ) যা বেশ কয়েকটি বন্দরে একটি বিপরীত সুড়ঙ্গকে একটি ছোট ডিজিটাল ওশান ভিপিএস (বি) এ সূচনা করে যাতে আমি বি এর আইপি ঠিকানার মাধ্যমে এ-তে সংযোগ করতে পারি। টানেলটি প্রায় 3 মাস ধরে ধারাবাহিকভাবে কাজ করে, তবে গত 24 ঘন্টা হঠাৎ চারবার ব্যর্থ হয়েছে। একই জিনিসটি ঘটল কিছুক্ষণ আগে অন্য ভিপিএস সরবরাহকারী - কয়েক মাস নিখুঁত অপারেশন করার পরে, হঠাৎ একাধিক দ্রুত ব্যর্থতা।

আমার কাছে মেশিন এ-তে একটি স্ক্রিপ্ট রয়েছে যা স্বয়ংক্রিয়ভাবে টানেল কমান্ড কার্যকর করে ( ssh -R *:X:localhost:X address_of_Bপ্রতিটি পোর্ট এক্সের জন্য) তবে এটি কার্যকর হলে এটি বলে Warning: remote port forwarding failed for listen port X।

/var/log/secureসার্ভারে sshd এ গিয়ে এই ত্রুটিগুলি দেখায়:

bind: Address already in use
error: bind: Address already in use
error: channel_setup_fwd_listener: cannot listen to port: X

সমাধানের জন্য ভিপিএস পুনরায় চালু করা দরকার। ততক্ষণে পুনরায় সংযোগ করার সমস্ত প্রচেষ্টা "রিমোট পোর্ট ফরওয়ার্ডিং ব্যর্থ" বার্তা দেয় এবং কার্যকর হবে না। এটি এখন সেই স্থানে যেখানে টানেলটি থামার প্রায় 4 ঘন্টা আগে স্থায়ী হয়।

ভিপিএসে কিছুই পরিবর্তিত হয়নি, এবং এটি একক-ব্যবহারযোগ্য, একক ব্যবহারকারী মেশিন যা কেবল বিপরীত টানেলের শেষ পয়েন্ট হিসাবে কাজ করে। এটি CentOS 6.5 এ ওপেনএসএসএইচ_5.3 পি 1 চালাচ্ছে। দেখে মনে হচ্ছে সংযোগটি হারিয়ে যাওয়ার পরে sshd পোর্টগুলি বন্ধ করে দিচ্ছে না। আমি কেন পুরোপুরি নিখুঁত ক্রিয়াকলাপের মাস পরে বা কেন হঠাৎ এটি ঘটবে তা বোঝাতে আমি ক্ষতিগ্রস্থ হয়ে পড়েছি।

স্পষ্ট করার জন্য, আমার প্রথমে এটি নির্ধারণ করতে হবে যে টানেল ব্যর্থ হওয়ার পরে এসএসডি কেন বন্দরগুলি শুনতে অস্বীকৃতি জানায়, যা মনে হয় এসএসডি দ্বারা বন্দরগুলি খোলা রেখে কখনও বন্ধ করা হয়নি। এটিই মূল সমস্যা বলে মনে হচ্ছে। আমি প্রত্যাশা করি না যে আমি কীভাবে প্রত্যাশা করে মাসের পরে আচরণ করার পরে এই জাতীয় আচরণ করবে (যেমন এখনি পোর্টগুলি বন্ধ করে দেওয়া এবং স্ক্রিপ্টটি পুনরায় সংযোগ করার অনুমতি দেওয়া)।

Comments

আপনার প্রশ্ন কি? কীভাবে পোর্ট বাইন্ডিং ত্রুটি মোকাবেলা করতে হবে, বা কীভাবে ssh মারা যাচ্ছে, বা কীভাবে আবার কিছু জানবেন?

— ম্যাডহ্যাটার 15:40 '

আমাকে বুঝতে হবে কেন sshd ভিপিএসে পোর্টগুলি খুলতে অস্বীকার করছে (বাইন্ড ত্রুটি)। পোর্ট বাইন্ডিং ত্রুটিটি সমস্যার মূল বলে মনে হচ্ছে এবং আমি যদি এটি সমাধান করতে সক্ষম হই তবে সবকিছুই কাজ করা উচিত।

— জাস্টিন মির্কভা

যে কোনও দেরী লুকারদের জন্য, সংযোগটি উন্মুক্ত রাখতে ম্যানুয়ালি একটি স্ক্রিপ্ট তৈরি করার পরিবর্তে কেবল পরিবর্তে অটোশ ব্যবহার করুন, এটি আপনার জন্য এটি করে does serverfault.com/questions/598210/...

— oligofren থেকে

Answer 1

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

এই জাতীয় সংযোগগুলি ঘটতে পারে এমন তিনটি উপায় রয়েছে:

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

উপরোক্ত তিনটির মধ্যে কোনটি ঘটছে তা নির্ধারণ করা অত্যন্ত গুরুত্বপূর্ণ নয়, কারণ একটি পদ্ধতি রয়েছে, যা তিনটিকেই সম্বোধন করবে। এটি হ'ল কিপালাইভ বার্তাগুলির ব্যবহার।

আপনি মধ্যে হওয়া উচিত ClientAliveIntervalজন্য শব্দ sshd_configএবং ServerAliveIntervalজন্য বিরতি ssh_configবা ~/.ssh/config।

sshএকটি লুপে কমান্ড চালানো ভাল কাজ করতে পারে। লুপের মধ্যে একটি ঘুম সন্নিবেশ করা ভাল ধারণা যে কোনও কারণে সংযোগ ব্যর্থ হলে সার্ভারের প্লাবন শেষ না করে।

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

Comments

আমি ভাবছি এই সমস্যা হতে পারে। বিশেষত, এ-তে আমার লিপিটি বি এর সাথে পুনরায় সংযোগ স্থাপনের চেষ্টা করবে যদি ssh প্রক্রিয়াটি মারা যায় (অবশ্যই যেহেতু সতর্কতা বার্তাটি এসএসএস প্রক্রিয়াটি হ'ল না যখন এটি ঘটে তখন এটি কেবল স্তব্ধ হয়ে যায়, তবে এটি অন্য দিনের জন্য সমস্যা)। তবে যদি এ খুব দ্রুত বি সাথে পুনরায় সংযোগ স্থাপনের চেষ্টা করে, বি এ সংযোগের জন্য এ অপেক্ষা করতে পারে। আমার সম্ভবত এটি পুনরায় সংযোগের আগে বি এর সর্বদা সময় বের হয়ে যায় তা নিশ্চিত করা দরকার। পুনরায় সংযোগের আগে sshd প্রক্রিয়াগুলি মেরে ফেলার জন্য ম্যাডহ্যাটারের পরামর্শের সাথে মিলিত হওয়ার ফলে সম্ভবত সম্ভাব্য 95% কেস কভার করা সম্ভব।

— জাস্টিন শ্রীকভা

এবং এসএসএইচকে হত্যা না করার সতর্কতা বার্তার কথা বলার ফলে তা আমার মনে হয়েছে ... এবং ম্যানপেজগুলি দেখে looking -o ExitOnForwardFailure yesআমার প্রয়োজন ঠিক ঠিক দেখা যাচ্ছে । সুতরাং এটি আমি খুঁজে বের করা প্রয়োজন আরও একটি জিনিস। ভাবতে ভাবতে, আমি এই সতর্কতা বার্তাগুলির বিশ্লেষণ করতে পাইথন স্ক্রিপ্ট লিখছিলাম। এটি অনেক সহজ। : ডি

— জাস্টিন মির্কভা

ExitOnForwardFailureআমার উত্তর লেখার সময় ভুলে যাওয়ার জন্য দুঃখিত । আমি এখন এটি উত্তরে যুক্ত করেছি have

— ক্যাস্পারড

কোনও সমস্যা নেই, এবং এটি আসলে ছিল -o ExitOnForwardFailure=yes(সমান চিহ্নটি নোট করুন)। সুতরাং কেউ যদি এই জুড়ে আসে, আমার পূর্ববর্তী মন্তব্যটি অনুলিপি করুন এবং পেস্ট করবেন না, এটি কার্যকর হবে না। : পি

— জাস্টিন মির্কভা

সুতরাং আমি প্রায় 10 ঘন্টা সার্ভারটি পর্যবেক্ষণ করছি এবং দেখে মনে হচ্ছে এটি ঠিকঠাক চলছে; আমি এই মুহুর্তে ধরে নিচ্ছি যে এই উত্তরটি সঠিক (আমি যা দেখেছি তার উপর ভিত্তি করে আমি প্রায় 99% নিশ্চিত) এবং দ্রুত বিচ্ছিন্নতার সিরিজটি নেটওয়ার্ক ইস্যুগুলির সাথে সম্পর্কিত কাকতালীয় ঘটনা যা কয়েক মাস পরেই প্রকাশিত হয়েছিল। প্রতিটি পরিষেবা শুরু। আপনার সাহায্যের জন্য সবাইকে ধন্যবাদ। ;)

— জাস্টিন মির্কভা

Answer 2

আপনি সেই প্রক্রিয়াটি খুঁজে পেতে পারেন যা সেই সার্ভারের সাথে বন্দরকে আবদ্ধ করে

sudo netstat -apn|grep -w X

এটি অর্ধ-অবক্ষয়হীন বলে মনে হচ্ছে sshd, তবে যখন আপনি ডেটা রাখতে পারেন তখন অনুমান কেন করবেন? আবার টানেলটি আবার উপরে আনার চেষ্টা করার আগে স্ক্রিপ্টের জন্য পিআইডি 9 কে সিগন্যাল প্রেরণের সন্ধানের জন্য এটি একটি ভাল উপায়।

Comments

আমার মনে আছে এটি পূর্ববর্তী ভিপিএস সরবরাহকারীর উপর যাচাই করেছিলাম এবং আমি নিশ্চিত করেছিলাম যে এসএসডিডি হ'ল সেই পোর্টগুলি শোনার প্রক্রিয়া। পরের বার এটি ঘটে আমি এটি এখানে যাচাই করব, কিন্তু আচরণ এবং সেটআপ ঠিক একই হিসাবে আমি এটি অন্যরকম হওয়ার আশা করি না।

— জাস্টিন মির্কভা

দুর্দান্ত, তাই আপনার স্ক্রিপ্টটি যাতে টানেলটি পুনরায় খোলে তা করার চেষ্টা করার আগে পুরানো টানেলরটিকে মেরে ফেলে।

— ম্যাডহ্যাটার

আপনি যা বলছেন তা যদি একবারে একাধিক টানেল স্ক্রিপ্ট (এ তে) চলমান থাকে না। অন্যদিকে, আপনি যদি স্ক্রিপ্টটিকে বিভ্রান্তিকর প্রক্রিয়াগুলি হ্রাস করার জন্য বিতে একটি কমান্ড কার্যকরভাবে প্রয়োগ করতে চান ... এটি আসলে একটি অর্ধ খারাপ ধারণা নয়। তবে একটি উদ্বেগ বারবার সমস্ত এসএসএইচ সংযোগ বন্ধ করে দিচ্ছে যদি আমি ডিবাগ করার চেষ্টা করি। যদি এ-তে থাকা স্ক্রিপ্টটি সর্বদা বিভ্রান্তির কারণে বি কে হত্যা করে, তবে আমি ক্রমাগত দুর্বৃত্ত A স্ক্রিপ্ট দ্বারা বি থেকে কাত হয়ে যেতে পারি না। : পি এটি পরীক্ষা না করে তা নিশ্চিত না করে তা পরীক্ষা করতে হবে। তবে আমি যেমন বলেছি, অর্ধেক খারাপ ধারণা নয়। ;)

— জাস্টিন মির্কভা

আমি ভাবিনি সেখানে ছিল। আপনি বলছেন রিমোট সার্ভারে একটি স্ক্রিপ্ট চলছে যা বাঁধের ত্রুটির কারণে একটি টানেল আনার চেষ্টা করে এবং ব্যর্থ হয়, এবং আমি ধরে নিচ্ছি এটি যখন আপনার প্রয়োজন হবে তখনই এটি চালিত হবে (যেমন, বিদ্যমান টানেলটি ভাল না হলে) কারণ আপনি অন্যথায় বলেন নি। আমি কেবল যে পরামর্শ দিচ্ছি তা হ'ল এটি নতুন টানেলটি আনার চেষ্টা করার আগে পোর্টটি উন্মুক্ত করে রাখা নির্দিষ্ট প্রক্রিয়াটিকে হত্যা করে।

— ম্যাডহ্যাটার

স্ক্রিপ্ট চলমান স্ক্রিপ্টটি কেবল সার্ভার এ-তে রয়েছে, সার্ভার বি একটি সরল ভ্যানিলা সার্ভার যা কোনও অতিরিক্ত স্ক্রিপ্ট নেই। আমি সম্ভবত যা করব তা হ'ল সার্ভার বিতে কিল স্ক্রিপ্ট লিখুন, তবে এটি একটি থেকে পরপর নির্দিষ্ট সংখ্যক বার সংযোগ করতে ব্যর্থ হলে দূরবর্তীভাবে এ থেকে এটি কল করুন। এইভাবে অন্যান্য এসএসএইচ সংযোগে হস্তক্ষেপের সম্ভাবনা কম। এবং আমি সম্ভবত ক্রি স্ক্রিপ্ট লগ করব প্রতিবার এটি চালানো হবে এবং খুব তাড়াতাড়ি অনেকবার বলা হয়ে থাকলে কিছুই না করে প্রস্থান করুন। ব্যক্তিগতভাবে, মনে হচ্ছে যে কোনও স্ক্রিপ্ট যা sshd মারে সম্ভবত রেট-সীমাবদ্ধ করা বুদ্ধিমানের। : পি

— জাস্টিন মির্কভা

Answer 3

আমার জন্য যখন কোনও sshটানেল সংযোগটি পুনরায় সংযোগ স্থাপনের জন্য কিছুটা সময় নেয় তাই sshপ্রক্রিয়াটি আমাকে কোনও সক্রিয় টানেল না রেখে অবরুদ্ধ করে চলেছে এবং কেন জানি না। একটি কার্যকর সমাধান হ'ল পুরানো সংযোগগুলি পুনরায় সেট করার জন্য অপেক্ষা না করে নতুন সংযোগগুলির সাথে sshব্যাকগ্রাউন্ডে রাখা এবং -fস্পোন করা। -o ExitOnForwardFailure=yesনতুন প্রসেস সংখ্যা limt ব্যবহার করা যেতে পারে। -o ServerAliveInterval=60আপনার বর্তমান সংযোগ নির্ভরযোগ্যতা উন্নত করে।

আপনি sshকমান্ডটি ঘন ঘন পুনরাবৃত্তি করতে পারেন , cronআপনার স্ক্রিপ্টের একটি বা একটি লুপে বলতে পারেন, উদাহরণস্বরূপ, নিম্নলিখিতটিতে আমরা sshপ্রতি 3 মিনিটে কমান্ডটি চালাচ্ছি :

while (1)
do
    ssh -f user@hostname -Rport:host:hostport -N -o ExitOnForwardFailure=yes -o ServerAliveInterval=60
    sleep 180
done

Comments

আরও শক্তিশালী সমাধান অটোশ

— মার্কো লাভাগিনো

-o ExitOnForwardFailure=yesআমি যা খুঁজছিলাম তা ছিল, অনেক অনেক ধন্যবাদ!

— ভাদ্পিপ

Answer 4

আমার অভিজ্ঞতার মধ্যে ssh এর পরিষ্কারভাবে না বেরোনোর ​​কিছুটা কৌতুকপূর্ণ অভ্যাস আছে যদি দূরবর্তী সিস্টেমে 'কিছু' এখনও চলমান থাকে। উদাহরণস্বরূপ ব্যাকগ্রাউন্ডে শুরু হয়েছিল। আপনি এটি দ্বারা পুনরুত্পাদন করতে পারেন:

ssh <server>
while true; do  sleep 60; done&
exit

আপনার ssh লগ আউট করবে, তবে বাস্তবে সেশনটি বন্ধ করবে না - যতক্ষণ না দূরবর্তী প্রক্রিয়াটি শেষ হয় (যা এটি হবে না, কারণ এটি 'সত্যিকারের' লুপ)। এটি একই রকম কিছু ঘটতে পারে - আপনার অধিবেশনটিতে একটি 'আটকে' প্রক্রিয়া রয়েছে যা এসএসএস দ্বারা তৈরি হয়েছিল। বন্দরটি ব্যবহারে রয়ে গেছে এবং তাই এটি আপনার স্থানীয় প্রক্রিয়া দ্বারা পুনরায় ব্যবহার করা যাবে না।

Comments

সম্পূর্ণ মেশিনে ssh -o ConnectTimeout=10 -o BatchMode=yes -gnN -R *:X:localhost:X root@$TUNSRV 1>>tunnel.log 2>&1 &চালিত এসএসএইচ কমান্ডটি এসএসএইচ দ্বারা টানেল ব্যতীত আর কিছুই করা হয়নি, বিশেষত -N বিকল্পের কারণে। যা খোলা রাখা হচ্ছে তা sshd নিজেই রিমোট সার্ভার বিতে করা হচ্ছে।

— জাস্টিন মির্কভা