記録:vsftpd vmwareでNatファイアウォールを使用したPASVモードの構築
4110 ワード
キーワード:vsftpd、Centos、nat、pasv、vmware
タイトルがちょっと拗ねています.サーバにvmware仮想マシンをインストールし、Centos 5.4のLinuxシステムを構築しました.上にftpサーバを1台配置するつもりで、vsftpdを採用しています.ネットワーク環境は,サーバが固定IPを持っているため,仮想マシン下のCentosに接続するにはnat方式を採用している.vsftpdはパッシブモード(pasv)を採用し、傍受ポートはデフォルトの21を採用し、データ通信高ポートは9010-9015を使用してlinuxのファイアウォールにこれらのポートを開放した.コマンドは次のとおりです.
プロファイル:/etc/vsftpd/vsftpd.conf関連pasvセクション:
そして仮想マシン上でnatポートマッピングを行いました.
ftpユーザーを追加し、プロセスを省略します.
その後、サーバにflashfxpで仮想マシン(内部IP、192.168.17.128を使用)のvsftpdにログインし、問題なく、データ接続ポートも9010から9015の間にあります.
そしてノートの上でflashfxpを使ってvsftpdに接続し、IPはサーバーの実際のIPに記入し、ポートはnatがマッピングした9021に記入し、接続を開始し、ユーザーにログインすることができますが、リストの時に開いたデータポートは、設定された9010-9015ではなく、ランダムで、例えば10534などで、リストとデータの転送ができません.
その後Googleは、/etc/vsftpd/vsftpd.confプロファイルに2つのパラメータを追加しました
vsftpdを再起動しますが、問題は相変わらずです.
その後ftpの21ポートも変更して9011に変更して、データポートは9012-9015に変更して、ftpの取引先のポートは9011に変更して、接続はすべて正常です.
最後の構成は次のとおりです.
pasv_addressは実際のサーバアドレスであり、ドメイン名であってもよい.
これらの問題は、ポートマッピングサーバ9021->仮想マシン21の上にあると推測される.サーバ21->仮想マシン21の場合、問題は発生しない可能性がありますが、21ポートはサーバによって占有されており、テストされていません.一方、9010～9015ポートは、直接マッピングされており、中間にポート変換は存在しないため、正常に使用できます.この道理は、よく分からないので、大侠たちが評価することを歓迎します.
タイトルがちょっと拗ねています.サーバにvmware仮想マシンをインストールし、Centos 5.4のLinuxシステムを構築しました.上にftpサーバを1台配置するつもりで、vsftpdを採用しています.ネットワーク環境は,サーバが固定IPを持っているため,仮想マシン下のCentosに接続するにはnat方式を採用している.vsftpdはパッシブモード(pasv)を採用し、傍受ポートはデフォルトの21を採用し、データ通信高ポートは9010-9015を使用してlinuxのファイアウォールにこれらのポートを開放した.コマンドは次のとおりです.
/sbin/iptables -I INPUT -p tcp --dport 21 -j ACCEPTT
/sbin/iptables -I INPUT -p tcp --dport 9010 -j ACCEPT
/sbin/iptables -I INPUT -p tcp --dport 9011 -j ACCEPT
/sbin/iptables -I INPUT -p tcp --dport 9012 -j ACCEPT
/sbin/iptables -I INPUT -p tcp --dport 9013 -j ACCEPT
/sbin/iptables -I INPUT -p tcp --dport 9014 -j ACCEPT
/sbin/iptables -I INPUT -p tcp --dport 9015 -j ACCEPT
/etc/rc.d/init.d/iptables save
/etc/init.d/iptables statusプロファイル:/etc/vsftpd/vsftpd.conf関連pasvセクション:
pasv_enable=YES
pasv_min_port=9010
pasv_max_port=9015そして仮想マシン上でnatポートマッピングを行いました.
9021 -> 21
9010 -> 9010
9011 -> 9011
9012 -> 9012
9013 -> 9013
9014 -> 9014
9015 -> 9015ftpユーザーを追加し、プロセスを省略します.
その後、サーバにflashfxpで仮想マシン(内部IP、192.168.17.128を使用)のvsftpdにログインし、問題なく、データ接続ポートも9010から9015の間にあります.
そしてノートの上でflashfxpを使ってvsftpdに接続し、IPはサーバーの実際のIPに記入し、ポートはnatがマッピングした9021に記入し、接続を開始し、ユーザーにログインすることができますが、リストの時に開いたデータポートは、設定された9010-9015ではなく、ランダムで、例えば10534などで、リストとデータの転送ができません.
その後Googleは、/etc/vsftpd/vsftpd.confプロファイルに2つのパラメータを追加しました
pasv_address=example.hostname.com
pasv_addr_resolve=YESvsftpdを再起動しますが、問題は相変わらずです.
その後ftpの21ポートも変更して9011に変更して、データポートは9012-9015に変更して、ftpの取引先のポートは9011に変更して、接続はすべて正常です.
最後の構成は次のとおりです.
listen_port=9011
pasv_enable=YES
pasv_min_port=9012
pasv_max_port=9015
pasv_addr_resolve=YES
pasv_address=example.hostname.compasv_addressは実際のサーバアドレスであり、ドメイン名であってもよい.
これらの問題は、ポートマッピングサーバ9021->仮想マシン21の上にあると推測される.サーバ21->仮想マシン21の場合、問題は発生しない可能性がありますが、21ポートはサーバによって占有されており、テストされていません.一方、9010～9015ポートは、直接マッピングされており、中間にポート変換は存在しないため、正常に使用できます.この道理は、よく分からないので、大侠たちが評価することを歓迎します.