NAT කරන VPN ගේට්වේ එකක් පිටුපස FTP ලැයිස්තු එල්ලී යන්නේ ඇයි
පිවිසුම සහ PWD සාර්ථක වන අතර, NAT මාතෘකා පමණක් නැවත ලියන විට 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 පේලෝඩය තුළ ඇති ලිපිනය අල්ලා ගන්න, සහ එම ලිපිනය පරිවර්තනය කරන්නේ කුමන උපාංගයදැයි අසන්න. එහි සහායකයා සම්බන්ධ කරන්න, එක් මාරු කිරීමක් අතරතුර අපේක්ෂා ලැයිස්තුව නිරීක්ෂණය කරන්න, පසුව සේවාදායකයේ නිෂ්ක්රීය ප්රකාරය නිවැරදි කර ගේට්වේ රීතියේ පරාසය පිළිබිඹු කරන්න.
දත්ත මාර්ගයේ අසාර්ථකත්වය තොග මාරු කිරීමේ අසාර්ථකත්වයෙන් වෙන් කර තබන්න, මන්ද ඒවා ඔබව විවිධ සැකසුම් වෙත ගෙන යයි.