La uzantnomo funkcias, la pasvorto funkcias, kaj la kliento diras, ke ĝi estas konektita. Poste ĝi atendas eterne dosierujan liston aŭ la unuan dosieran transigon, kaj nenio en la legitimiloj klarigas tion. FTP malfermas duan konekton por ĉiu listo kaj ĉiu dosiero, kaj ĝuste tiu dua konekto malsukcesas. La ensaluto nur pruvas, ke la unua konversacio funkcias.

Farigu la kontrolojn laŭ ordo. Ĉiu ekskludas malsaman tavolon, do haltu ĉe la unua, kiu montras anomalion.

Unue apartigu la du konektojn

Rega konekto portas komandojn kaj respondojn ĉe la aŭskulta pordo de la servilo. Dena konekto portas la dosierujan liston aŭ la dosieran korpon, kaj en pasiva reĝimo la servilo elektas sian finpunkton kaj anoncas ĝin en la respondo PASV aŭ EPSV. Permesi pordon 21 diras nenion pri tio, ĉu la dena pordo estas atingebla, kaj ĝuste tial ensaluto sukcesas dum ĉiu listo tempolimas. La gvidilo de WinSCP pri FTP-reĝimo klarigas la dividon kaj ĝiajn retajn postulojn.

Se la kliento sidas malantaŭ la VPN, la dena vojo transiras la saman tunelon sed ne nepre la saman politikon.

Legu la adreson en la respondo PASV

Rulu detaleman klienton kaj legu la respondon anstataŭ diveni. curl -v ftp://user@host/ presas la linion PASV kun la adreso kaj pordo, kiujn la servilo volas, kaj ĝuste al tiu adreso la kliento poste konektiĝas. Se ĝi estas privata adreso, kiu signifas nenion ĉe la klienta flanko de la tunelo, la dena konekto iras nenie dum la rega kanalo restas sana.

Komparu tiun adreson kun la adreso, kiun la kliento efektive atingis. Miskongruo estas la respondo, kaj ĝi kutime venas de NAT aŭ de servilo agordita kun interna adreso.

Kontrolu la pordan intervalon kaj la tunelan politikon

Pasivaj serviloj asignas denajn pordojn el agordita intervalo, kaj tiu intervalo devas esti permesita tra la VPN kaj ajna fajroŝirmilo sur la vojo. Politiko, kiu permesas 21 kaj nenion alian, estas politiko nur por ensaluto. Konfirmu la intervalon ĉe tiu, kiu administras la servilon, poste testu unu pordon el ĝi anstataŭ supozi, ke la tuta intervalo kondutas same.

Ĉifritaj regaj kanaloj malfaciligas tion, ĉar meza skatolo ne plu povas reverki la anoncitan adreson dumfluge.

Sciu, kiam EPSV aŭ rezervaĵo helpas

EPSV redonas pordon sen aparta adreso, kio forigas la fiaskon pro malĝusta adreso kiam ambaŭ flankoj subtenas ĝin. Al iuj klientoj ankaŭ eblas ordoni ignori la anoncitan adreson kaj reuzi la celon de la rega konekto. Ambaŭ estas legitimaj iloj celantaj specifan topologion, ne ĝenerala solvo.

Ne malŝaltu TLS nur por ke helpilo inspektu la seancon. Tio interŝanĝas funkciantan protokolon kontraŭ rompita minacmodelo.

Konfirmu per listo kaj transigo

Post kiam la adresa aŭ porda politiko ŝanĝiĝis, malfermu freŝan seancon laŭ la sama VPN-vojo kaj listigu dosierujon. Poste transigu malgrandan dosieron, ĉar listo kaj transigo povas preni malsamajn kodvojojn ĉe iuj serviloj. Kontrolu en la klienta protokolo denan konekton al la atendata adreso kaj pordo, kaj konfirmu, ke la bajtoj alvenis.

Tenu FTP, FTPS kaj SFTP aparte en la kapo dum vi faras tion. Ŝanĝo de pasiva pordo ne estas SFTP-agordo, kaj la ripeto ne transiĝas inter protokoloj.

Rilataj artikoloj