ההתחברות ל-FTP עובדת אבל רשימת התיקיה נתקעת: מדוע
התחברויות FTP ורשימות תיקיות משתמשות בשני חיבורים שונים. כשרשימה נתקעת, בדקו את כתובת הנתונים הפסיבית ואת טווח הפורטים, לא את הסיסמה.
שם המשתמש עובד, הסיסמה עובדת, והלקוח אומר שהוא מחובר. ואז הוא ממתין לנצח לרשימת תיקיה, או להעברת הקובץ הראשונה, ושום דבר בפרטי ההתחברות לא מסביר זאת. FTP פותח חיבור שני לכל רשימה ולכל קובץ, והחיבור השני הזה הוא שנכשל. ההתחברות רק מוכיחה שהשיחה הראשונה עובדת.
בצעו את הבדיקות לפי הסדר. כל אחת שוללת שכבה אחרת, אז עצרו בראשונה שמפיקה אנומליה.
הפרידו תחילה בין שני החיבורים
חיבור בקרה נושא פקודות ותשובות בפורט ההאזנה של השרת. חיבור נתונים נושא את רשימת הספרייה או את גוף הקובץ, ובמצב פסיבי השרת בוחר את נקודת הקצה שלו ומכריז עליה בתגובת PASV או EPSV. אישור פורט 21 לא אומר דבר על נגישות פורט הנתונים, וזו בדיוק הסיבה שהתחברות מצליחה בעוד כל רשימה נגמרת בזמן. המדריך של WinSCP למצבי FTP מפרט את ההפרדה ואת דרישות הרשת שלה.
אם הלקוח נמצא מאחורי ה-VPN, נתיב הנתונים חוצה את אותה מנהרה אך לא בהכרח את אותה מדיניות.
קראו את הכתובת בתגובת PASV
הריצו לקוח מפורט וקראו את התגובה במקום לנחש. curl -v ftp://user@host/ מדפיס את שורת PASV עם הכתובת והפורט שהשרת רוצה, ולכתובת הזו הלקוח מתחבר בהמשך. אם זו כתובת פרטית שאינה אומרת דבר בצד הלקוח של המנהרה, חיבור הנתונים לא הולך לשום מקום בעוד ערוץ הבקרה נשאר תקין.
השוו את הכתובת הזו לכתובת שהלקוח הגיע אליה בפועל. אי-ההתאמה היא התשובה, והיא מגיעה בדרך כלל מ-NAT או משרת שהוגדר עם כתובת פנימית.
בדקו את טווח הפורטים ואת מדיניות המנהרה
שרתים פסיביים מקצים פורטי נתונים מטווח מוגדר, וטווח זה חייב להיות מאושר דרך ה-VPN וכל חומת אש בנתיב. מדיניות שמאשרת 21 ושום דבר אחר היא מדיניות להתחברות בלבד. אשרו את הטווח עם מי שמפעיל את השרת, ואז בדקו פורט אחד ממנו במקום להניח שכל הטווח מתנהג אותו דבר.
ערוצי בקרה מוצפנים מקשים על זה, כי תיבת ביניים כבר לא יכולה לשבט את הכתובת המוכרזת תוך כדי תנועה.
דעו מתי EPSV או חלופה עוזרים
EPSV מחזיר פורט בלי כתובת נפרדת, מה שמסיר את כשל הכתובת השגויה כששני הקצוות תומכים בו. אפשר גם לומר לחלק מהלקוחות להתעלם מהכתובת המוכרזת ולעשות שימוש חוזר ביעד חיבור הבקרה. שניהם כלים לגיטימיים לטופולוגיה מסוימת, לא פתרון כולל.
אל תכבו TLS רק כדי שכלי עזר יבדוק את ההפעלה. זה מחליף פרוטוקול עובד במודל איומים שבור.
אשרו עם רשימה והעברה
לאחר שינוי מדיניות הכתובת או הפורט, פתחו הפעלה חדשה באותו נתיב VPN ורשמו ספרייה. אחר כך העבירו קובץ קטן, כי רשימה והעברה יכולות לעבור בנתיבי קוד שונים בשרתים מסוימים. בדקו ביומן הלקוח חיבור נתונים לכתובת ולפורט הצפויים ואשרו שהביטים הגיעו.
שמרו על FTP, FTPS ו-SFTP בנפרד בראש בזמן שאתם עושים זאת. שינוי פורט פסיבי אינו הגדרה של SFTP, והתיקון לא עובר בין פרוטוקולים.