A felhasználónév működik, a jelszó működik, és a kliens azt mondja, hogy csatlakozott. Aztán örökké vár egy mappalistára vagy az első fájlátvitelre, és a hitelesítő adatokban semmi nem magyarázza ezt. Az FTP minden listához és minden fájlhoz második kapcsolatot nyit, és éppen ez a második kapcsolat hibázik. A bejelentkezés csak azt bizonyítja, hogy az első beszélgetés működik.

Végezze el az ellenőrzéseket sorrendben. Mindegyik más réteget zár ki, ezért álljon meg az elsőnél, amely rendellenességet mutat.

Először válassza szét a két kapcsolatot

A vezérlőkapcsolat a kiszolgáló figyelő portján szállítja a parancsokat és a válaszokat. Az adatkapcsolat a könyvtárlistát vagy a fájl törzsét szállítja, és passzív módban a kiszolgáló kiválasztja a végpontját, és bejelenti a PASV vagy EPSV válaszban. A 21-es port engedélyezése semmit nem mond arról, hogy az adatport elérhető-e, és pontosan ezért sikerül a bejelentkezés, míg minden lista időtúllépéssel megszakad. A WinSCP útmutatója az FTP-módokhoz kifejti ezt a szétválasztást és annak hálózati követelményeit.

Ha a kliens a VPN mögött van, az adatút ugyanazon az alagúton halad át, de nem feltétlenül ugyanazon a szabályzaton.

Olvassa el a címet a PASV válaszban

Futtasson részletes klienst, és olvassa el a választ a találgatás helyett. curl -v ftp://user@host/ kinyomtatja a PASV sort a kiszolgáló által kívánt címmel és porttal, és a kliens ezután pontosan erre a címre csatlakozik. Ha ez olyan privát cím, amely az alagút kliensoldalán semmit nem jelent, az adatkapcsolat sehová nem jut, míg a vezérlőcsatorna egészséges marad.

Hasonlítsa össze ezt a címet azzal a címmel, amelyet a kliens ténylegesen elért. Az eltérés a válasz, és általában NAT-tól vagy belső címmel beállított kiszolgálótól származik.

Ellenőrizze a porttartományt és az alagút szabályzatát

A passzív kiszolgálók beállított tartományból osztanak ki adatportokat, és ezt a tartományt engedélyezni kell a VPN-en és az údvonal bármely tűzfalán keresztül. Az a szabályzat, amely 21-et engedélyez és semmi mást, csak bejelentkezési szabályzat. Erősítse meg a tartományt a kiszolgálót üzemeltetővel, majd teszteljen egy portot belőle, ahelyett hogy feltételezné, hogy az egész tartomány ugyanúgy viselkedik.

A titkosított vezérlőcsatornák ezt nehezebbé teszik, mert egy köztes eszköz már nem tudja átírni a bejelentett címet menet közben.

Tudja, mikor segít az EPSV vagy egy tartalék megoldás

Az EPSV külön cím nélkül ad vissza egy portot, ami megszünteti a rossz cím miatti hibát, ha mindkét vég támogatja. Egyes klienseknek azt is meg lehet mondani, hogy hagyják figyelmen kívül a bejelentett címet, és használják újra a vezérlőkapcsolat célját. Mindkettő legitim eszköz egy adott topológiához, nem általános megoldás.

Ne kapcsolja ki a TLS-t csak azért, hogy egy segédeszköz megvizsgálhassa a munkamenetet. Ez egy működő protokollt cserél fel egy hibás fenyegetésmodellre.

Erősítse meg listával és átvitellel

Miután a cím- vagy portszabályzat megváltozott, nyisson új munkamenetet ugyanazon a VPN-údvonalon, és listázza ki a könyvtárat. Ezután vigyen át egy kis fájlt, mert a lista és az átvitel egyes kiszolgálókon különböző kódutakat járhat. Ellenőrizze a kliens naplójában a várt címre és portra menő adatkapcsolatot, és erősítse meg, hogy a bájtok megérkeztek.

Tartsa fejben külön az FTP-t, az FTPS-t és az SFTP-t, míg ezt teszi. A passzív port megváltoztatása nem SFTP-beállítás, és a javítás nem terjed át a protokollok között.

Kapcsolódó cikkek