Ինչու են FTP ցանկերը կախվում NAT անող VPN դարպասի հետևում
Մուտքն ու PWD-ն անցնում են, բայց LIST-ն ու RETR-ը կանգ են առնում, երբ NAT-ը վերագրում է միայն վերնագրերը: Տեսեք, որտեղ պիտի լինի 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 |
Տեղադրեք օգնականն այնտեղ, որտեղ կատարվում է թարգմանությունը
Linux-ում բեռնվածքի վերագրումը կատարում է 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-ի վրա կախվելը մատնանշում է սեսիայի առաջին տվյալների կապը, որտեղ պիտի աշխատեն և՛ հասցեի վերագրումը, և՛ սպասումը։ RETR-ի վրա կախվելը աշխատող LIST-ից հետո մատնանշում է հենց փոխանցումը, այսինքն պասիվ միջակայքը կամ թունելի MTU-ն։ Այդ երկրորդ ստորագրությունը բեռնվածքի խնդիր չէ, և օգնականի կարգավորումները չեն ուղղի այն։
TLS-ի վրա FTP-ն հանում է այն բեռնվածքը, որը կարդում է օգնականը։ Միջանկյալ արկղը չի կարող վերագրել PORT կամ PASV արժեք, որը չի կարող վերծանել, ուստի մնում են TLS-ը վերջացնող պրոքսին, սահմանափակ միջակայքում հասանելի հասցե գովազդող սերվերը կամ այլ փոխանցման արձանագրություն։
Ստուգումների կարճ հերթականություն
Աշխատեք ախտանիշից դեպի դուրս։ Հաստատեք, որ LIST-ը ձախողվում է, մինչ PWD-ն հաջողվում է, բռնեք հասցեն PORT-ի կամ 227-ի բեռնվածքի մեջ և հարցրեք, թե որ սարքն է թարգմանում այդ հասցեն։ Կցեք օգնականն այնտեղ, հետևեք սպասումների ցանկին մեկ փոխանցման ընթացքում, ապա ուղղեք պասիվ ռեժիմը սերվերի վրա և արտացոլեք միջակայքը դարպասի կանոնում։
Տվյալների ուղու ձախողումը առանձին պահեք զանգվածային փոխանցման ձախողումից, որովհետև դրանք տանում են տարբեր կարգավորումների։