WinSCP FTPS מתחבר דרך ה-proxy אך אינו יכול להציג רשימת קבצים
בדקו גם את חיבור הנתונים הפסיבי וגם את חיבור הבקרה כאשר משתמשים ב-HTTP CONNECT עבור FTPS.
התחברות FTPS מוכיחה שחיבור הבקרה עבד. רשימת תיקייה דורשת חיבור נוסף, ולכן proxy יכול לאפשר את ההתחברות ולחסום את הצעד הבא.
עבור שרת FTPS מפורש, הגדירו את מסלול הבקרה ואת המצב הפסיבי עם WinSCP .NET:
var options = new WinSCP.SessionOptions
{
Protocol = WinSCP.Protocol.Ftp,
HostName = "ftp.example.net",
PortNumber = 21,
UserName = ftpUser,
Password = ftpPassword,
FtpSecure = WinSCP.FtpSecure.Explicit,
FtpMode = WinSCP.FtpMode.Passive
};
options.AddRawSettings("ProxyMethod", "3");
options.AddRawSettings("ProxyHost", "proxy.example.net");
options.AddRawSettings("ProxyPort", "8080");ההגדרה ProxyMethod עם הערך 3 בוחרת HTTP CONNECT. פתחו את האפשרויות הללו דרך מחזור החיים הרגיל של WinSCP Session ביישום, והוסיפו את ההגדרות הגולמיות ProxyUsername ו-ProxyPassword כאשר המתווך דורש אימות.
עקבו אחרי כשל הרשימה
בדקו ביומן ההפעלה את נקודת הקצה הפסיבית של הנתונים שאושרה ואת כשל החיבור שלה. ה-proxy חייב לאפשר את היעד והפורט האלה, וגם את נקודת הקצה של בקרת FTP. לכן כלל שמתיר CONNECT רק לפורט הבקרה יכול לקבל את ההתחברות ולדחות את הרשימה.
שינוי פורט הבקרה בלבד אינו מתקן מסלול נתונים חסום. השתמשו בנקודת הקצה של הנתונים שנרשמה ביומן בעת בדיקת מדיניות הרשת.
הדוגמה הזו מפעילה FTPS מפורש בפורט 21 ומנהלת משא ומתן על TLS. עבור נקודת קצה של FTPS משתמע, השתמשו במצב FtpSecure המתאים ובפורט השרת. בשני המקרים, השתמשו בשם המארח האמיתי של TLS של השרת ובתצורת אימות האישורים.