FTP prisijungimas veikia, bet aplankų sąrašas pakimba: kodėl
FTP prisijungimai ir aplankų sąrašai naudoja du skirtingus ryšius. Kai sąrašas pakimba, tikrinkite pasyvų duomenų adresą ir prievadų diapazoną, o ne slaptažodį.
Vartotojo vardas veikia, slaptažodis veikia, o klientas praneša, kad prisijungė. Tada jis amžinai laukia aplanko sąrašo arba pirmojo failo perdavimo, ir niekas prisijungimo duomenyse to nepaaiškina. FTP atidaro antrą ryšį kiekvienam sąrašui ir kiekvienam failui, ir būtent tas antrasis ryšys nepavyksta. Prisijungimas tik įrodo, kad pirmasis pokalbis veikia.
Atlikite patikras iš eilės. Kiekviena atmeta skirtingą sluoksnį, todėl sustokite ties pirmąja, kuri duoda anomaliją.
Pirmiausia atskirkite du ryšius
Valdymo ryšys perduoda komandas ir atsakymus serverio klausymosi prievadu. Duomenų ryšys perduoda katalogo sąrašą arba failo turinį, o pasyviuoju režimu serveris pasirenka savo galinį tašką ir paskelbia jį PASV arba EPSV atsakyme. Leisti 21 prievadą nieko nesako apie tai, ar duomenų prievadas pasiekiamas, ir būtent todėl prisijungimas pavyksta, nors kiekvienas sąrašas baigiasi skirtuoju laiku. WinSCP FTP režimų vadovas paaiškina šį atskyrimą ir jo tinklo reikalavimus.
Jei klientas yra už VPN, duomenų kelias eina tuo pačiu tuneliu, bet nebūtinai ta pačia politika.
Perskaitykite adresą PASV atsakyme
Paleiskite išsamų klientą ir perskaitykite atsakymą, o ne spėliokite. curl -v ftp://user@host/ išspausdina PASV eilutę su adresu ir prievadu, kurių nori serveris, ir būtent prie šio adreso klientas jungiasi toliau. Jei tai privatus adresas, kuris kliento pusėje tunelyje nieko nereiškia, duomenų ryšys niekur neina, o valdymo kanalas lieka sveikas.
Palyginkite šį adresą su adresu, kurį klientas faktiškai pasiekė. Neatitikimas yra atsakymas, ir jis paprastai kyla iš NAT arba serverio, sukonfigūruoto su vidiniu adresu.
Patikrinkite prievadų diapazoną ir tunelio politiką
Pasyvieji serveriai skiria duomenų prievadus iš sukonfigūruoto diapazono, ir tas diapazonas turi būti leidžiamas per VPN ir bet kurią ugniasienę kelyje. Politika, leidžianti 21 ir nieko daugiau, yra tik prisijungimo politika. Patvirtinkite diapazoną su serverį administruojančiu asmeniu, tada išbandykite vieną prievadą iš jo, o ne manykite, kad visas diapazonas elgiasi vienodai.
Šifruoti valdymo kanalai tai apsunkina, nes tarpinis įrenginys nebegali perrašyti paskelbto adreso skrydžio metu.
Žinokite, kada padeda EPSV arba atsarginė galimybė
EPSV grąžina prievadą be atskiro adreso, o tai pašalina klaidingo adreso gedimą, kai abu galai tai palaiko. Kai kuriems klientams galima nurodyti ignoruoti paskelbtą adresą ir naudoti valdymo ryšio paskirties vietą. Abu yra teisėti įrankiai konkrečiai topologijai, o ne universalus sprendimas.
Nebeišjunkite TLS tik tam, kad pagalbinė priemonė patikrintų sesiją. Tai keičia veikiantį protokolą į sulaužytą grėsmių modelį.
Patvirtinkite sąrašu ir perdavimu
Pakeitę adreso arba prievado politiką, atidarykite naują sesiją tuo pačiu VPN keliu ir išvardykite katalogą. Tada perduokite mažą failą, nes sąrašas ir perdavimas kai kuriuose serveriuose gali eiti skirtingais kodo keliais. Patikrinkite kliento žurnale duomenų ryšį su laukiamu adresu ir prievadu ir patvirtinkite, kad baitai atvyko.
Šio darbo metu laikykite FTP, FTPS ir SFTP atskirai galvoje. Pasyvaus prievado pakeitimas nėra SFTP nustatymas, ir pataisymas neperkeliamas tarp protokolų.