NAT કરતા VPN ગેટવે પાછળ FTP યાદીઓ કેમ અટકી જાય છે
લોગિન અને PWD સફળ થાય છે, જ્યારે NAT ફક્ત હેડર ફરી લખે ત્યારે LIST અને RETR અટકી જાય છે. FTP સહાયક ક્યાં બેસવો જોઈએ અને નિષ્ક્રિય મોડ કેવી રીતે સુધારવો તે જુઓ.
લોગિન કામ કરે છે, PWD કામ કરે છે, અને પછી LIST અટકી જાય છે જ્યાં સુધી ક્લાયન્ટ હાર ન માને અથવા બીજા ડેટા મોડમાં ન જાય. એ વિભાજન જ સહી છે: પોર્ટ 21 સુધીનું નિયંત્રણ જોડાણ સ્વસ્થ છે, જ્યારે ડેટા જોડાણ એવા સરનામા કે પોર્ટથી બને છે જ્યાં સામેનો છેડો પહોંચી શકતો નથી. NAT પણ કરતા VPN ગેટવે પાછળ, સામાન્ય દોષિત એ 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 પેલોડમાંનું સરનામું પકડો, અને પૂછો કે કયું ઉપકરણ એ સરનામું અનુવાદિત કરે છે. ત્યાં સહાયક જોડો, એક ટ્રાન્સફર દરમિયાન અપેક્ષા યાદી જુઓ, પછી સર્વર પર નિષ્ક્રિય મોડ સુધારો અને ગેટવે નિયમમાં શ્રેણી પ્રતિબિંબિત કરો.
ડેટા-માર્ગની નિષ્ફળતાને બલ્ક-ટ્રાન્સફર નિષ્ફળતાથી અલગ રાખો, કારણ કે તે તમને અલગ સેટિંગ્સ તરફ લઈ જાય છે.