অনুরোধে ফাইল পাঠানো হচ্ছে না ফেডোরা 17 tftp


2

আমার ইস্যুটি হ'ল আমি কোনও সার্ভারে tftp স্থাপনের চেষ্টা করছি, tftp থেকে কোনও ফাইল ডাউনলোড করার চেষ্টা করার সময় সবকিছু ঠিকঠাকভাবে চালিত হবে এটি কখনই সাড়া দেয় না, আমি দেখছি এমন কোনও ত্রুটি নেই, কেবল নীরবতা, যখন আমি স্মিফ করি সার্ভার থেকে ট্রাফিক যে প্রতিক্রিয়া জানানো উচিত, আমি অনুরোধটি দেখতে পাচ্ছি তবে সার্ভারটি কখনও ফাইলটির সাথে সাড়া দেয় না

আমি একটি কম্পিউটার চালাচ্ছি Fedora 17(আমি জানি এটি জীবনের শেষ, তবে এটি বর্তমানে পরিবর্তনযোগ্য নয়)

আমি পেতে চেষ্টা করছি tftpএটা চালু রাখার জন্য, আমি করুন tftp (ইনস্টল yum install -y tftp-server) এবং চালানোর জন্য সেট করতে চান, খোলা UDPপোর্ট 69, এবং ফোল্ডার অনুমতি সেট, কিন্তু এটি কিছু মানবে না, এখানে কিছু আউটপুট এবং কনফিগ ফাইল

আমি যখন tftp চালাব [সার্ভারের আইপি] পরীক্ষা করান

কোন সাহায্যের ব্যাপকভাবে প্রশংসা হবে

SELinux:

# setenforce 0
setenforce: SELinux is disabled

tftp config:

cat /etc/xinetd.d/tftp 
# default: off
# description: The tftp server serves files using the trivial file transfer \
#   protocol.  The tftp protocol is often used to boot diskless \
#   workstations, download configuration files to network-aware printers, \
#   and to start the installation process for some operating systems.
service tftp
{
    socket_type     = dgram
    protocol        = udp
    wait            = yes
    user            = root
    server          = /usr/sbin/in.tftpd
    server_args     = -s /copos/tftp -vvv
    disable         = no
    per_source      = 11
    cps         = 100 2
    flags           = IPv4
}

The Directory:

# ls -lah /copos/tftp/
total 48K
drwxrwxrwx   4 root      root      4.0K Feb  3 14:42 .
drwxr-xr-x. 31 coposuser coposuser 4.0K Feb  3 14:46 ..
drwxrwxrwx   3 root      root      4.0K Feb  3 14:42 clonezilla
-rwxrwxrwx   1 root      root       27K Feb  3 14:42 pxelinux.0
drwxrwxrwx   2 root      root      4.0K Feb  3 14:42 pxelinux.cfg
-rwxrwxrwx   1 root      root         9 Feb  3 14:42 test

The Port is opened:

# netstat -anp|grep 69|grep xinet 
udp        0      0 0.0.0.0:69              0.0.0.0:*                           3533/xinetd

আমি এই বিষয়টি আরও ভালভাবে ব্যাখ্যা করার জন্য কেবল এটিকে উচ্চারণ করেছি
টিম

ফেডোরা 17 সাপোর্টের বাইরে। সমর্থন প্রাচীনতম সংস্করণ ফেডোরা 20.
সেভেন

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

উত্তর:


0

আপনি হয় ফায়ারওয়াল বিধি অ্যাক্সেস ব্লক করতে পারে

অথবা

আপনার / কোপো ডিরেক্টরিতে সম্পূর্ণ অনুমতি নেই।

আপনি এটি করে এটি অনুধাবন করতে সক্ষম হওয়া উচিত:

tail -f /var/log/messages

আপনি একটি ফাইল ডাউনলোড করার চেষ্টা করার সময়। যদি আপনি কোনও এন্ট্রি না পান তবে এটি ফায়ারওয়াল ইস্যু, যদি আপনি কিছু পান তবে:

Feb  3 18:50:48 host1 in.tftpd[10298]: RRQ from 192.168.4.190 filename test.xml
Feb  3 18:50:48 host1 in.tftpd[10298]: sending NAK (0, Permission denied) to 192.168.4.190

তারপরে এটির অনুমতি সংক্রান্ত সমস্যা

এছাড়াও মনে রাখবেন যে 69 বন্দরটিতে একা ক্যাপচার করা আপনাকে সমস্ত ট্রেস প্রদর্শন করবে না। Tftp সার্ভার স্থানান্তরের জন্য 69 এর চেয়ে আলাদা উত্স পোর্ট ব্যবহার করবে। এই কারণেই যদি কিছু এনএটি জড়িত থাকে তবে সাধারণত tftp ভেঙে যায়।

সুতরাং সম্পূর্ণ বিনিময় সাধারণত উদাহরণস্বরূপ এর মতো হয়:

client requests file via tftp (source port random_client -> dest port 69)
server send back tftp file (source port random_server -> dest port random_client)

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


আমি আমার জবাবটি আপডেট করেছিলাম যে NAT টিএফটিপি স্থানান্তরেও বিপর্যয় ঘটায়।
রিকার্ডো

এটি ফায়ারওয়াল ইস্যু ছিল, আমি iptables অক্ষম করেছিলাম এবং এটি কাজ করেছিল
টিম
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.