NAT ਕਰਨ ਵਾਲੇ VPN ਗੇਟਵੇ ਪਿੱਛੇ FTP ਸੂਚੀਆਂ ਕਿਉਂ ਅਟਕ ਜਾਂਦੀਆਂ ਹਨ
ਲੌਗਇਨ ਅਤੇ PWD ਸਫਲ ਹੁੰਦੇ ਹਨ, ਪਰ ਜਦੋਂ NAT ਸਿਰਫ਼ ਹੈਡਰ ਮੁੜ ਲਿਖਦਾ ਹੈ ਤਾਂ LIST ਅਤੇ RETR ਰੁਕ ਜਾਂਦੇ ਹਨ। ਦੇਖੋ FTP ਸਹਾਇਕ ਕਿੱਥੇ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਪੈਸਿਵ ਮੋਡ ਕਿਵੇਂ ਠੀਕ ਕਰਨਾ ਹੈ।
ਲੌਗਇਨ ਕੰਮ ਕਰਦਾ ਹੈ, PWD ਕੰਮ ਕਰਦਾ ਹੈ, ਅਤੇ ਫਿਰ LIST ਅਟਕ ਜਾਂਦਾ ਹੈ ਜਦ ਤੱਕ ਕਲਾਇੰਟ ਹਾਰ ਨਹੀਂ ਮੰਨਦਾ ਜਾਂ ਕਿਸੇ ਹੋਰ ਡੇਟਾ ਮੋਡ ਵਿੱਚ ਨਹੀਂ ਜਾਂਦਾ। ਇਹ ਵੰਡ ਹੀ ਨਿਸ਼ਾਨ ਹੈ: ਪੋਰਟ 21 ਤੱਕ ਕੰਟਰੋਲ ਕਨੈਕਸ਼ਨ ਸਿਹਤਮੰਦ ਹੈ, ਜਦ ਕਿ ਡੇਟਾ ਕਨੈਕਸ਼ਨ ਅਜਿਹੇ ਪਤੇ ਜਾਂ ਪੋਰਟ ਤੋਂ ਬਣ ਰਿਹਾ ਹੈ ਜਿੱਥੇ ਦੂਜਾ ਸਿਰਾ ਪਹੁੰਚ ਨਹੀਂ ਸਕਦਾ। ਜੋ VPN ਗੇਟਵੇ ਖੁਦ ਵੀ NAT ਕਰਦਾ ਹੈ, ਉਸ ਪਿੱਛੇ ਆਮ ਦੋਸ਼ੀ ਉਹ FTP ਕਮਾਂਡ ਹੈ ਜਿਸ ਦਾ ਪੇਲੋਡ 10.8.0.6 ਵਰਗਾ ਟਨਲ ਪਤਾ ਦੱਸਦਾ ਹੈ। ਹੈਡਰ ਅਨੁਵਾਦ ਉਸ ਮੁੱਲ ਨੂੰ ਕਦੇ ਨਹੀਂ ਛੂਹਦਾ।
ਅੱਗੇ ਇਹ ਹੈ ਕਿ ਉਹ ਮੁੱਲ ਕਿੱਥੋਂ ਆਉਂਦਾ ਹੈ ਅਤੇ ਕਿਹੜਾ ਬਾਕਸ ਉਸ ਨੂੰ ਬਦਲ ਸਕਦਾ ਹੈ।
ਟੁੱਟਦਾ ਪੇਲੋਡ ਹੈ, ਟਨਲ ਨਹੀਂ
FTP ਡੇਟਾ ਦੇ ਅੰਤ ਬਿੰਦੂ ਨੂੰ ਕੰਟਰੋਲ ਸਟਰੀਮ ਦੇ ਅੰਦਰ ਰੱਖਦਾ ਹੈ। ਐਕਟਿਵ ਮੋਡ ਵਿੱਚ ਕਲਾਇੰਟ ਆਪਣੇ ਪਤੇ ਅਤੇ ਪੋਰਟ ਨਾਲ PORT ਭੇਜਦਾ ਹੈ, ਅਤੇ ਸਰਵਰ ਉਸ ਜੋੜੀ ਨੂੰ ਵਾਪਸ ਕਾਲ ਕਰਦਾ ਹੈ। ਪੈਸਿਵ ਮੋਡ ਵਿੱਚ ਸਰਵਰ ਜੋੜੀ ਨਾਲ 227 ਦਾ ਜਵਾਬ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਕਲਾਇੰਟ ਉਸ ਦੀ ਥਾਂ ਉਸੇ ਨੂੰ ਕਾਲ ਕਰਦਾ ਹੈ।
ਦੋਵੇਂ ਰੂਪ ਇੱਕੋ ਕਿਸਮ ਦਾ ਬਿਆਨ ਲੈ ਕੇ ਚੱਲਦੇ ਹਨ: ਇਸ ਪਤੇ 'ਤੇ, ਇਸ ਪੋਰਟ 'ਤੇ ਜੁੜੋ। ਜੋ ਯੰਤਰ ਸਿਰਫ਼ IP ਅਤੇ TCP ਹੈਡਰ ਮੁੜ ਲਿਖਦਾ ਹੈ, ਉਹ ਬਿਆਨ ਨੂੰ ਜਿਉਂ ਦਾ ਤਿਉਂ ਛੱਡ ਦਿੰਦਾ ਹੈ, ਇਸ ਲਈ ਇੱਕ ਸਿਰਾ ਉਸ ਪਤੇ ਤੱਕ ਪਹੁੰਚਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਰਹਿੰਦਾ ਹੈ ਜੋ ਸਿਰਫ਼ ਟਨਲ ਦੇ ਦੂਜੇ ਪਾਸੇ ਹੈ। ਕੰਟਰੋਲ ਕਨੈਕਸ਼ਨ ਪਹਿਲਾਂ ਹੀ ਸਿਹਤਮੰਦ ਐਲਾਨੇ ਜਾਣ ਤੋਂ ਬਾਅਦ ਡੇਟਾ ਕਨੈਕਸ਼ਨ ਰੁਕ ਜਾਂਦਾ ਹੈ।
ਤਿੰਨ ਮੋਡ, ਤਿੰਨ ਪੇਲੋਡ
ਹੇਠਾਂ ਦਿੱਤੀ ਸਾਰਣੀ ਦਿਖਾਉਂਦੀ ਹੈ ਕਿ ਕਿਸ ਪਾਸੇ ਨੂੰ ਕਾਲ ਕਰਨ ਲਈ ਕਿਹਾ ਜਾ ਰਿਹਾ ਹੈ, ਅਤੇ ਸਿਰਫ਼ ਹੈਡਰ ਬਦਲਣ ਵਾਲਾ NAT ਇਸ ਬਾਰੇ ਕੀ ਕਰ ਸਕਦਾ ਹੈ।
ਆਖਰੀ ਕਾਲਮ ਨੂੰ ਪਹਿਲਾਂ ਅਸਫਲ ਹੋਣ ਵਾਲੀ ਚੀਜ਼ ਵਜੋਂ ਪੜ੍ਹੋ। ਐਕਟਿਵ ਮੋਡ ਵਿੱਚ ਨਿੱਜੀ ਪਤੇ 'ਤੇ ਕਾਲ ਸਰਵਰ ਕਰਦਾ ਹੈ; ਪੈਸਿਵ ਮੋਡ ਵਿੱਚ ਕਲਾਇੰਟ ਕਰਦਾ ਹੈ; FTPS ਵਿੱਚ ਪੇਲੋਡ ਸਾਈਫਰਟੈਕਸਟ ਹੁੰਦਾ ਹੈ ਅਤੇ ਵਿਚਕਾਰਲੇ ਬਾਕਸ ਕੋਲ ਕੰਮ ਕਰਨ ਲਈ ਹੋਰ ਵੀ ਘੱਟ ਹੁੰਦਾ ਹੈ।
| Mode | Value in the control stream | Who dials whom | Header-only NAT leaves |
|---|---|---|---|
| Active (PORT) | client address and port | server dials the client | a server dialing an unreachable tunnel address |
| Passive (227) | server address and port | client dials the server | a client dialing an address it cannot route to |
| FTPS | the same values, inside TLS | as above | ciphertext, so no rewrite happens at all |
ਸਹਾਇਕ ਨੂੰ ਉੱਥੇ ਰੱਖੋ ਜਿੱਥੇ ਅਨੁਵਾਦ ਹੁੰਦਾ ਹੈ
ਲੀਨਕਸ 'ਤੇ ਪੇਲੋਡ ਮੁੜ ਲਿਖਣ ਦਾ ਕੰਮ nf_conntrack_ftp ਸਹਾਇਕ ਕਰਦਾ ਹੈ। ਇਹ ਕੰਟਰੋਲ ਕਨੈਕਸ਼ਨ 'ਤੇ ਨਜ਼ਰ ਰੱਖਦਾ ਹੈ, ਜਿਸ ਪੋਰਟ 'ਤੇ ਗੱਲ ਹੋਈ ਉਹ ਸਿੱਖਦਾ ਹੈ, ਡੇਟਾ ਪ੍ਰਵਾਹ ਲਈ ਇੱਕ ਉਮੀਦ ਬਣਾਉਂਦਾ ਹੈ, ਅਤੇ NAT ਬਾਕਸ 'ਤੇ ਪੇਲੋਡ ਦੇ ਅੰਦਰਲਾ ਪਤਾ ਅਤੇ ਪੋਰਟ ਮੁੜ ਲਿਖਦਾ ਹੈ। ਇਹ ਸਿਰਫ਼ ਉਸ ਯੰਤਰ 'ਤੇ ਮਦਦ ਕਰਦਾ ਹੈ ਜੋ ਕਲਾਇੰਟ ਦੇ ਪਤੇ ਦਾ ਅਨੁਵਾਦ ਕਰਦਾ ਹੈ। ਇਸ ਨੂੰ ਕਲਾਇੰਟ 'ਤੇ, ਜਾਂ ਸਿਰਫ਼ ਪ੍ਰਵਾਹ ਅੱਗੇ ਭੇਜਣ ਵਾਲੇ ਰਾਊਟਰ 'ਤੇ ਲੋਡ ਕਰਨ ਨਾਲ ਸੈਸ਼ਨ ਵਿੱਚ ਕੁਝ ਨਹੀਂ ਬਦਲਦਾ।
ਇਹ ਤਿੰਨ ਕਮਾਂਡ ਦਿਖਾਉਂਦੀਆਂ ਹਨ ਕਿ ਮਾਡਿਊਲ ਮੌਜੂਦ ਹੈ ਜਾਂ ਨਹੀਂ, ਜੁੜਿਆ ਹੋਇਆ ਹੈ ਜਾਂ ਨਹੀਂ, ਅਤੇ ਸੈਸ਼ਨ ਖੁੱਲ੍ਹਾ ਹੋਣ ਸਮੇਂ ਉਮੀਦ ਹੈ ਜਾਂ ਨਹੀਂ:
modprobe nf_conntrack_ftp
lsmod | grep nf_conntrack_ftp
conntrack -L expect | grep ftpਮਾਡਿਊਲ ਲੋਡ ਕਰਨਾ ਇਸ ਨੂੰ ਜੋੜਨ ਦੇ ਬਰਾਬਰ ਨਹੀਂ ਹੈ। 4.7 ਤੋਂ ਕਰਨਲ net.netfilter.nf_conntrack_helper=0 ਨਾਲ ਆਉਂਦੇ ਹਨ, ਇਸ ਲਈ ਸਹਾਇਕ ਸਪੱਸ਼ਟ ਨਿਯਮ ਦੀ ਉਡੀਕ ਕਰਦਾ ਹੈ, ਜਿਵੇਂ iptables -t raw -A PREROUTING -p tcp --dport 21 -j CT --helper ftp। ਜੇ ਟ੍ਰਾਂਸਫਰ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਿਆਂ ਉਮੀਦਾਂ ਦੀ ਸੂਚੀ ਖਾਲੀ ਰਹੇ, ਤਾਂ ਜੋੜਨਾ ਜਾਂਚਣਾ ਹੈ, ਮਾਡਿਊਲ ਨਹੀਂ।
ਪੈਸਿਵ ਮੋਡ: ਸਰਵਰ ਨੂੰ ਦੱਸੋ ਕਿ ਕੀ ਘੋਸ਼ਿਤ ਕਰਨਾ ਹੈ
ਪੈਸਿਵ ਮੋਡ ਨੂੰ ਨਿਸ਼ਚਿਤਕ ਬਣਾਉਣਾ ਸੌਖਾ ਹੈ ਕਿਉਂਕਿ ਸਰਵਰ ਨੂੰ ਦੱਸਿਆ ਜਾ ਸਕਦਾ ਹੈ ਕਿ 227 ਜਵਾਬ ਵਿੱਚ ਕੀ ਰੱਖਣਾ ਹੈ। vsftpd ਵਿੱਚ ਇਹ pasv_address ਹੈ, ਨਾਲ pasv_min_port ਅਤੇ pasv_max_port; ProFTPD MasqueradeAddress ਅਤੇ PassivePorts ਵਰਤਦਾ ਹੈ। ਇਹ ਪਹਿਲਾਂ ਸੈੱਟ ਕਰੋ, ਕਿਉਂਕਿ ਸਹੀ ਘੋਸ਼ਿਤ ਪਤਾ ਉਸ ਪਾਸੇ ਕੁਝ ਵੀ ਮੁੜ ਲਿਖਣ ਦੀ ਲੋੜ ਹਟਾ ਦਿੰਦਾ ਹੈ।
ਫਿਰ ਠੀਕ ਉਹੀ ਪੋਰਟ ਰੇਂਜ ਗੇਟਵੇ ਰਾਹੀਂ ਲੰਘਣ ਦਿਓ, ਜਿਵੇਂ -A FORWARD -i tun0 -p tcp --dport 30000:30100 -j ACCEPT, ਤਾਂ ਜੋ ਨਿਯਮ ਸਰਵਰ ਵੱਲੋਂ ਘੋਸ਼ਿਤ ਨਾਲ ਮੇਲ ਖਾਵੇ।
ਦੋਵੇਂ ਸੈਟਿੰਗਾਂ ਨੂੰ ਸਹਿਮਤ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਇੱਕ ਸਰਵਰ ਨੂੰ 30000-30100 ਘੋਸ਼ਿਤ ਕਰਨ ਲਈ ਕਿਹਾ ਜਾਵੇ ਜਦ ਕਿ ਗੇਟਵੇ 40000-40100 ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ, ਤਾਂ ਉਹ ਸਭ ਤੋਂ ਘੱਟ ਮਦਦਗਾਰ ਢੰਗ ਨਾਲ ਅਸਫਲ ਹੁੰਦਾ ਹੈ: ਕੰਟਰੋਲ ਗੱਲਬਾਤ ਸਿਹਤਮੰਦ ਦਿਸਦੀ ਹੈ ਅਤੇ ਹਰ ਡੇਟਾ ਕਨੈਕਸ਼ਨ ਮਰ ਜਾਂਦਾ ਹੈ। ਹੋਰ ਕੁਝ ਡੀਬੱਗ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਸੰਖਿਆਵਾਂ ਦੀ ਤੁਲਨਾ ਕਰੋ।
ਅਸਫਲਤਾ ਦੇ ਦੋ ਨਿਸ਼ਾਨ, ਅਤੇ FTPS ਕੀ ਹਟਾਉਂਦਾ ਹੈ
LIST 'ਤੇ ਅਟਕਣਾ ਸੈਸ਼ਨ ਦੇ ਪਹਿਲੇ ਡੇਟਾ ਕਨੈਕਸ਼ਨ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ, ਜਿੱਥੇ ਪਤੇ ਦਾ ਮੁੜ ਲਿਖਣ ਅਤੇ ਉਮੀਦ ਦੋਵੇਂ ਕੰਮ ਕਰਨੇ ਹਨ। ਕੰਮ ਕਰਦੇ LIST ਤੋਂ ਬਾਅਦ RETR 'ਤੇ ਅਟਕਣਾ ਖੁਦ ਟ੍ਰਾਂਸਫਰ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ, ਭਾਵ ਪੈਸਿਵ ਰੇਂਜ ਜਾਂ ਟਨਲ ਦਾ MTU। ਉਹ ਦੂਜਾ ਨਿਸ਼ਾਨ ਪੇਲੋਡ ਦੀ ਸਮੱਸਿਆ ਨਹੀਂ ਹੈ, ਅਤੇ ਸਹਾਇਕ ਦੀਆਂ ਸੈਟਿੰਗਾਂ ਇਸ ਨੂੰ ਠੀਕ ਨਹੀਂ ਕਰਨਗੀਆਂ।
TLS ਉੱਤੇ FTP ਉਸ ਪੇਲੋਡ ਨੂੰ ਹਟਾ ਦਿੰਦਾ ਹੈ ਜੋ ਸਹਾਇਕ ਪੜ੍ਹਦਾ ਹੈ। ਵਿਚਕਾਰਲਾ ਬਾਕਸ ਅਜਿਹਾ PORT ਜਾਂ PASV ਮੁੱਲ ਮੁੜ ਨਹੀਂ ਲਿਖ ਸਕਦਾ ਜਿਸ ਨੂੰ ਉਹ ਡੀਕ੍ਰਿਪਟ ਨਹੀਂ ਕਰ ਸਕਦਾ, ਇਸ ਲਈ ਬਚੀਆਂ ਚੋਣਾਂ ਹਨ TLS ਖਤਮ ਕਰਨ ਵਾਲਾ ਪ੍ਰਾਕਸੀ, ਸੀਮਿਤ ਰੇਂਜ ਵਿੱਚ ਪਹੁੰਚਯੋਗ ਪਤਾ ਘੋਸ਼ਿਤ ਕਰਨ ਵਾਲਾ ਸਰਵਰ, ਜਾਂ ਵੱਖਰਾ ਟ੍ਰਾਂਸਫਰ ਪ੍ਰੋਟੋਕਾਲ।
ਜਾਂਚਾਂ ਦਾ ਛੋਟਾ ਕ੍ਰਮ
ਲੱਛਣ ਤੋਂ ਬਾਹਰ ਵੱਲ ਕੰਮ ਕਰੋ। ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ PWD ਸਫਲ ਹੁੰਦਿਆਂ LIST ਅਸਫਲ ਹੁੰਦਾ ਹੈ, PORT ਜਾਂ 227 ਪੇਲੋਡ ਦੇ ਅੰਦਰਲਾ ਪਤਾ ਫੜੋ, ਅਤੇ ਪੁੱਛੋ ਕਿ ਕਿਹੜਾ ਯੰਤਰ ਉਸ ਪਤੇ ਦਾ ਅਨੁਵਾਦ ਕਰਦਾ ਹੈ। ਉੱਥੇ ਸਹਾਇਕ ਜੋੜੋ, ਇੱਕ ਟ੍ਰਾਂਸਫਰ ਦੌਰਾਨ ਉਮੀਦਾਂ ਦੀ ਸੂਚੀ ਦੇਖੋ, ਫਿਰ ਸਰਵਰ 'ਤੇ ਪੈਸਿਵ ਮੋਡ ਠੀਕ ਕਰੋ ਅਤੇ ਗੇਟਵੇ ਨਿਯਮ ਵਿੱਚ ਰੇਂਜ ਪ੍ਰਤੀਬਿੰਬਿਤ ਕਰੋ।
ਡੇਟਾ-ਮਾਰਗ ਦੀ ਅਸਫਲਤਾ ਨੂੰ ਬਲਕ-ਟ੍ਰਾਂਸਫਰ ਅਸਫਲਤਾ ਤੋਂ ਵੱਖ ਰੱਖੋ, ਕਿਉਂਕਿ ਉਹ ਤੁਹਾਨੂੰ ਵੱਖਰੀਆਂ ਸੈਟਿੰਗਾਂ ਵੱਲ ਲੈ ਜਾਂਦੀਆਂ ਹਨ।