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 పేలోడ్ లోపలి చిరునామాను పట్టుకోండి, ఏ పరికరం ఆ చిరునామాను అనువదిస్తుందో అడగండి. అక్కడ సహాయకుడిని కనెక్ట్ చేయండి, ఒక బదిలీ సమయంలో అంచనాల జాబితాను గమనించండి, తర్వాత సర్వర్లో నిష్క్రియ మోడ్ను సరిచేసి గేట్వే నియమంలో పరిధిని ప్రతిబింబించండి.
డేటా మార్గ వైఫల్యాన్ని బల్క్ బదిలీ వైఫల్యం నుండి వేరుగా ఉంచండి, ఎందుకంటే అవి వేర్వేరు సెట్టింగ్లకు తీసుకెళ్తాయి.