NAT ചെയ്യുന്ന VPN ഗേറ്റ്‍വേയുടെ പിന്നിൽ FTP ലിസ്റ്റുകൾ എന്തുകൊണ്ട് തൂങ്ങിക്കിടക്കുന്നു
NAT ഹെഡറുകൾ മാത്രം മാറ്റിയെഴുതുമ്പോൾ ലോഗിനും PWD-യും വിജയിക്കുമ്പോൾ LIST-ഉം RETR-ഉം നിലയ്ക്കുന്നു. FTP സഹായി എവിടെയായിരിക്കണം, നിഷ്ക്രിയ മോഡ് എങ്ങനെ ശരിയാക്കാം എന്നു കാണുക.
ലോഗിൻ പ്രവർത്തിക്കുന്നു, PWD പ്രവർത്തിക്കുന്നു, പിന്നെ ക്ലൈന്റ് വിട്ടുകളയുകയോ മറ്റൊരു ഡാറ്റാ മോഡിലേക്ക് മാറുകയോ ചെയ്യുന്നതുവരെ LIST തൂങ്ങിക്കിടക്കുന്നു. ഈ വിഭജനമാണ് അടയാളം: പോർട്ട് 21-ലേക്കുള്ള നിയന്ത്രണ കണക്ഷൻ ആരോഗ്യകരമാണ്, എന്നാൽ ഡാറ്റാ കണക്ഷൻ മറുവശത്തിന് എത്താൻ കഴിയാത്ത ഒരു വിലാസത്തിൽ നിന്നോ പോർട്ടിൽ നിന്നോ നിർമ്മിക്കുന്നു. NAT-ഉം ചെയ്യുന്ന VPN ഗേറ്റ്‍വേയുടെ പിന്നിൽ സാധാരണ കുറ്റക്കാരൻ, പേലോഡിൽ 10.8.0.6 പോലുള്ള ഒരു ടണൽ വിലാസം പേരിടുന്ന FTP കമാൻഡാണ്. ഹെഡർ പരിഭാഷ ആ മൂല്യത്തെ ഒരിക്കലും സ്പർശിക്കുന്നില്ല.
തുടർന്ന് വരുന്നത് ആ മൂല്യം എവിടെ നിന്ന് വരുന്നു, ഏത് ബോക്സിനാണ് അത് മാറ്റാൻ അനുവാദമുള്ളത് എന്നതാണ്.
തകരുന്നത് പേലോഡാണ്, ടണലല്ല
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 പേലോഡിനുള്ളിലെ വിലാസം പിടിക്കുക, ഏത് ഉപകരണമാണ് ആ വിലാസം പരിഭാഷപ്പെടുത്തുന്നതെന്ന് ചോദിക്കുക. അവിടെ സഹായിയെ ബന്ധിപ്പിക്കുക, ഒരു കൈമാറ്റത്തിനിടയിൽ പ്രതീക്ഷകളുടെ പട്ടിക നിരീക്ഷിക്കുക, പിന്നീട് സെർവറിൽ നിഷ്ക്രിയ മോഡ് ശരിയാക്കി ഗേറ്റ്‍വേ നിയമത്തിൽ ശ്രേണി പ്രതിഫലിപ്പിക്കുക.
ഡാറ്റാ പാതയിലെ പരാജയത്തെ ബൾക്ക് കൈമാറ്റ പരാജയത്തിൽ നിന്ന് വേർതിരിച്ച് നിർത്തുക, കാരണം അവ വ്യത്യസ്ത ക്രമീകരണങ്ങളിലേക്ക് നയിക്കുന്നു.