Autentificarea FTP funcționează, dar listarea folderelor se blochează: de ce

Numele de utilizator funcționează, parola funcționează, iar clientul spune că este conectat. Apoi așteaptă la infinit o listare de folder, sau prima transferare de fișier, și nimic din datele de autentificare nu explică asta. FTP deschide o a doua conexiune pentru fiecare listare și fiecare fișier, și exact acea a doua conexiune eșuează. Autentificarea dovedește doar că prima conversație funcționează.

Faceți verificările în ordine. Fiecare elimină un alt strat, așa că opriți-vă la prima care produce o anomalie.

Separați mai ântâi cele două conexiuni

O conexiune de control transportă comenzi și răspunsuri pe portul de ascultare al serverului. O conexiune de date transportă listarea directorului sau corpul fișierului, iar în modul pasiv serverul își alege punctul final și îl anunță în răspunsul PASV sau EPSV. Permiterea portului 21 nu spune nimic despre accesibilitatea portului de date, și exact de aceea o autentificare reușește în timp ce fiecare listare expiră. Ghidul WinSCP despre modurile FTP explică această separare și cerințele ei de rețea.

Dacă clientul se află în spatele VPN-ului, calea datelor traversează același tunel, dar nu neapărat aceeași politică.

Citiți adresa din răspunsul PASV

Rulați un client detaliat și citiți răspunsul în loc să ghiciți. curl -v ftp://user@host/ tipărește linia PASV cu adresa și portul dorite de server, iar clientul se conectează apoi exact la acea adresă. Dacă este o adresă privată care nu înseamnă nimic pe partea clientului a tunelului, conexiunea de date nu merge nicăieri în timp ce canalul de control rămâne sănătos.

Comparați acea adresă cu adresa la care clientul a ajuns efectiv. Neconcordanța este răspunsul, și de obicei provine din NAT sau dintr-un server configurat cu o adresă internă.

Verificați intervalul de porturi și politica tunelului

Servere pasive alocă porturi de date dintr-un interval configurat, iar acel interval trebuie permis prin VPN și prin orice firewall de pe traseu. O politică ce permite 21 și nimic altceva este o politică doar pentru autentificare. Confirmați intervalul cu cel care administrează serverul, apoi testați un port din el în loc să presupuneți că întregul interval se comportă la fel.

Canalele de control criptate fac asta mai dificilă, pentru că un intermediar nu mai poate rescrie adresa anunțată din mers.

Știți când ajută EPSV sau o variantă de rezervă

EPSV returnează un port fără o adresă separată, ceea ce elimină eșecul adresei greșite atunci când ambele capete îl acceptă. Unor clienți li se poate spune și să ignore adresa anunțată și să refolosească destinația conexiunii de control. Ambele sunt instrumente legitime pentru o topologie anume, nu o soluție universală.

Nu dezactivați TLS doar pentru a lăsa un instrument auxiliar să inspecteze sesiunea. Asta schimbă un protocol funcțional pe un model de amenințare stricat.

Confirmați cu o listare și o transferare

După ce politica de adresă sau de port se schimbă, deschideți o sesiune nouă pe aceeași cale VPN și listați un director. Apoi transferați un fișier mic, pentru că o listare și o transferare pot urma căi de cod diferite pe unele servere. Verificați în jurnalul clientului o conexiune de date către adresa și portul așteptate și confirmați că octeții au ajuns.

Țineți FTP, FTPS și SFTP separate în minte în timp ce faceți asta. O modificare de port pasiv nu este o setare SFTP, iar corecția nu se transferă între protocoale.