July 2007 - Posts
אז אחרי ה RemoteApps וה Session Broker הגיע זמנו של ה TS Gateway לקבל את הסקירה שלו...
ה TS Gateway הוא למעשה מאין Proxy המאפשר התחברות ב rdp לשרתים בתוך הרשת הארגונית וזאת ע"י גישה בפורט 443 (https) ולא ע"י גישה ב rdp סטנדרטי (3389) מה שמאפשר למעשה למשתמשים להתחבר בצורה מאובטחת ומוצפנת לשרתים ברשת הארגונית מכל מקום בו פתוח אותו הפורט של https (והסיכוי שהוא יהיה פתוח הוא גדול יותר מאשר ש rdp יהיה פתוח) ללא צורך ה vpn client או פתרונות מורכבים אחרים.
_thumb.png)
למעשה מי שמכיר את התחום יימצא לוודאי דמיון ל Citrix Secure Gateway אשר עושה את אותו העניין בדיוק, העברת ICA על גבי https.
אז כן, ה TS Gateway לא מביא איזה בשורה וטכנולוגיה מרעישה חדשה, אבל הוא עושה את העבודה שלשמה הוא קיים, העברת rdp על גבי https בצורה חלקה ויותר מזה, הוא כולל בתוכו יכולות נוספות, כמו רשימת המשתמשים שיכולים ליצור connection דרך ה TS Gateway לרשת הארגונית, לאיזה שרתים הם יכולים לגשת, לראות את המשתמשים המחוברים לרשת דרך ה TS Gateway, לוגים לגבי התחברות המשתמשים ועבודה עם NAP (או Network Access Protection) אשר מאפשר להגדיר "דרישות סף" לכניסה לרשת, למשל עדכינותם של עידכוני האבטחה המותקנים על התחנה, תוכנות מסוימות, הגדרות מחשב מיוחדות ועוד.
ה TS Gateway הוא role השייך לקבוצת ה Terminal Service Roles אבל זה לא אומר שה TS Gateway יהיה גם Terminal Server, מה שאומר ששרת ה TS Gateway איננו חלק מחוות ה TS של הארגון, לרוב ה TS Gateway יישב בכלל ב DMZ ושרתי ה TS עצמם ב LAN הארגוני.
הפעלת ה TS Gateway מורכבת למעשה מחמישה שלבים:
-
התקנת ה TS Gagteway role על השרת המיועד.
-
יצירת SSL certificate עבור שרת ה TS Gateway (זאת מכיוון שההצפנה נעשית ע"י TLS 1.0), זה יכול להיות certificate פנימי אשר נוצר ע"י CA מקומי, ceritificate חיצוני (Verisign, Thawte,וכו'), או self-signed certificate אשר ניתן ליצור במהלך התקנת ה TS Gateway role, את ה certificate יש לייצא ולייבא למחשבי המשתמשים.
חשוב ששם ה certificate יהיה זהה לשם שיוגדר בשדה ה TS Gateway אצל המשתמשים.
-
יצירת TS CAP, או Terminal Services Connection Authorization Policy, פה מגדירים את רשימת המשתמשים אשר להם תיהיה הרשאה לעבוד עם ה TS Gateway.
-
יצירת TS RAP, או Terminal Services Resource Authorization Policy, רשימת השרתים אליהם תיהיה גישה דרך ה TS Gateway.
-
הגדרת מספר ה sessions המקסימלי שיעבדו דרך ה TS Gateway.
לאחר סיום הגדרת השרת, נותרו שני דברים להגדרה במחשבים המרוחקים, ייבוא ה certificate והגדרת כתובת ה TS Gateway ב RDP client.
אני לא אתעקב על איך מייבאים certificate, אלה אתמקד בהגדרות ה client (גירסא 6 ומעלה), בהגדרות ה rdp client בוחרים ב advanced ובוחרים את הגדרות ה TS Gateway.
בהגדרות ה TS Gateway ישנם שלוש אפשרויות, לזהות את כתובת ה TS Gateway בצורה אוטומטית (ע"י group policy), הגדרה ידנית של כתובת ה TS Gateway, או לא להשתמש ב TS Gateway בכלל להתחבר ישירות לשרתים/מחשבים.
כמו שאפשר לראות, תחת ההגדרה הידנית ישנן שתי הגדרות נוספות, צורת ה logon שמאפשר לבחור האם לעשות authentication ע"י שם משתמש וסיסמא או ע"י smart card והאופציה "לדלג" על כתובות פנימיות (סגמנט ה ip הנוכחי), כלומר לא להשתמש ב הגדרות ה TS Gatewayעבור הכתובות הפנימיות ולהתחבר אליהן ישירות.
לאחר כל ההגדרות, נותר רק להתחבר לשרת המרוחק, כאמור הפלוס הגדול של ה TS Gateway שמספיק להחזיק connection אחד אשר יהיה טוב גם מהרשת הפנימית וגם מבחוץ, כלומר, כאשר נתחבר למשל מהבית, נשאיר את הכתובת הפנימית של השרת בכתובת אליה נרצה להתחבר וה TS Gateway יעשה את ההמרה לבד.
שלב ההתחברות מורכב משני שלבים, כאשר נלחץ על connect נתבקש לספק שם משתמש וסיסמא לשרת המרוחק, לאחר מכן נצטרך לספק שם משתמש וסיסמא לעבודה עם ה TS Gateway, אם המשתמש מוגדר ב TS CAP אזי ה connection יווצר ונתחבר ישירות לשרת המרוחק, אם המשתמש לא נמצא ב TS CAP או השרת המרוחק לא נמצא ב TS RAP או שה certificate לא נמצא, ה connection יידחה.
אם עברנו את כל המכשולים, נתחבר לשרת המבוקש וע"י בדיקה עם netstat יהיה אפשר לראות שכל התעבורה עוברת דרך ה TS Gateway.
לדוגמא ככה זה נראה אצלי:
TCP 192.168.1.4:51224 ts_gw:https ESTABLISHED
TCP 192.168.1.4:51225 ts_gw:https ESTABLISHED
אפשר גם לראות את פרטי ה sessions אשר עובדים דרך ה TS Gateway (וגם לנתק אותם אם ממש רוצים) ב Monitoring ב TS Gateway Manager בשרת ה TS Gateway עצמו.
לדוגמא:
לפני שבוע ומשהו כתבתי על איטיות בשרתי Citrix עם Trend Micro, אז במשך כל הזמן הזה לא היה שום דבר רשמי של Trend אשר מדבר על הנושא הזה, למעשה במשך השבוע האחרון מהנדסי Trend היו עסוקים בהגעה ללקוחות כדי לשחזר את הבעיה ולנסות להבין למה זה קורה (אני יודע שהם ביקרו אצל לקוחות בגרמניה ובאנגליה).
אתמול סופסוף הגיעה הודעה רשמית על כך ש Trend מודעים לבעיה ושהתיקון אמור לצאת ב 31/7 (קישור), למעשה התיקון כבר קיים כמה ימים ונוסה במספר חברות, אבל רק ב 31 הוא יהפוך להיות public.
האיטיות התחילה להתרחש אחרי עידכון ה scan engine בו נוספה יכולת חדשה אשר מאפשרת תאימות למערכת ניהול תצורה בשם Clear View, לשם כך נוספה טבלה חדשה אשר תפקידה לעשות logging לגישה לקבצים, למעשה כאשר קובץ נסגר לא עם ה PID שאיתו הוא נפתח, אותו קובץ נרשם בטבלה החדשה.
פתיחה וסגירה של קבצים מתבצעת כל הזמן בתהליכי logon ו- logoff עם PID-ים שונים, מה שגורם לטבלה החדשה לגדול עד כדי טירוף.
מכאן גם אפשר להבין למה אתחול ה real time service "שחרר" את השרת, כאשר מאתחילים את ה service הטבלה מתנקת ומתחילה ספירה מחודשת.
ב hotfix המיוחל Trend פשוט הפסיקו את ההשוואה של ה PID הפותח לסוגר של הקובץ, וכך הורידו את גודל הטבלה ביותר מפי 1000, למעשה בבדיקה שנערכה אצל אחד הלקוחות נבדק שרת עם רק משתמש אחד והטבלה כבר הכילה עשרות אלפי רשומות, לאחר התקנת ה hotfix הגול ירד ל 10 רשומות בלבד.
אז מה אנחנו לומדים מכל הפיאסקו הזה? QA QA ושוב פעם QA!
היום אחד משרתי המעבדה שלי נתקע במהלך האתחול (עשיתי לו restart אבל משום מה הוא נתקע באחד השלבים כנראה), לא היתה גישה אליו ב rdp אבל כן היתה גישה ל services שלו ובכלל ה rpc עבד.
אחרי שניסיתי כמה פעמים shutdown /m ללא הועיל נזכרתי שכאשר עוצרים את ה RPC השרת יעשה לעצמו restart תוך 30 שניות וכדי לעצור את ה RPC צריך "להרוג" את svchost.exe הרלוונטי.
אז כדי לראות את ה PID's של הפרוססים עשיתי tasklist /s remoteserver, יצא משהו כזה:
C:\Documents and Settings\gfeldman>tasklist /s remoteserver
Image Name PID Session Name Session# Mem Usage ========================= ======== ================ =========== ============ System Idle Process 0 0 16 K System 4 0 220 K smss.exe 280 0 448 K csrss.exe 328 0 4,304 K winlogon.exe 352 0 7,236 K services.exe 400 0 4,928 K lsass.exe 412 0 9,420 K svchost.exe 612 0 3,096 K svchost.exe 668 0 3,756 K svchost.exe 728 0 4,528 K svchost.exe 756 0 5,548 K svchost.exe 792 0 25,400 K spoolsv.exe 964 0 5,508 K msdtc.exe 992 0 4,372 K vmsrvc.exe 1084 0 2,908 K svchost.exe 1112 0 2,244 K inetinfo.exe 1196 0 8,480 K svchost.exe 1264 0 2,280 K svchost.exe 1588 0 5,484 K svchost.exe 1696 0 4,660 K csrss.exe 932 Console 2 2,656 K winlogon.exe 588 Console 2 4,792 K svchost.exe 2140 0 4,140 K sqlservr.exe 2668 0 6,940 K wmiprvse.exe 3792 0 6,676 K logon.scr 3572 Console 2 1,660 K wmiprvse.exe 1444 0 5,836 K
רשמתי לי את כל ה PID's של svchost (היו ממש לא מעט), והתחלתי "להרוג" אותם אחד אחד (taskkill).
C:\Documents and Settings\Administrator>taskkill /s remoteserver/PID 848 SUCCESS: The process with PID 848 has been terminated.
C:\Documents and Settings\Administrator>taskkill /s remoteserver /PID 904 SUCCESS: The process with PID 904 has been terminated.
C:\Documents and Settings\Administrator>taskkill /s remoteserver /PID 964
ERROR: The RPC server is unavailable.
למזלי ה PID השני היה המתאים וכבר בנסיון השלישי ראיתי שה RPC למטה, מה שאומר שהשרת התחיל לספור 30 שניות עד לאתחול המיוחל.
אלו היו 30 שניות על איך לאתחל שרת סורר בלי לקום מהכיסא.
ב 28 ליוני Trend Micro שיחררו fix ל- Trend Micro OfficeScan (אני יודע שזה משפיע על גירסה 8 ו 7.3) ואני חושב שהוא גם משדרג את ה Engine Version ל 8.5.
עד כאן הכל טוב ויפה, אבל מאז אותו תאריך, שרתי Citrix (אני חושב שזה ישפיע אותו הדבר גם על TS רגיל, אבל לא ראיתי את זה בעיניים) עובדים לאט עד כדי טירוף, לאחר שמאתחלים את ה services של ה officescan הכל משתחרר וממשיך לעבוד רגיל בין חצי שעה לכמה שעות (פעם ה restart החזיק מעמד למשך יום שלם ובזמן האחרון זה מחזיק משהו כמו חצי שעה) וכשעוצרים את ה services בכלל השרת עובד ללא בעיה.
לפי מה שידוע עכשיו, זה קורה בשרתי Citrix PS4 ו- PS4.5, וכמו שכבר ציינתי, אני חושב שההתנהגות תיהיה דומה על שרתי TS רגילים (אבל אל תתפסו אותי במילה...).
Trend Micro מודעים לעניין ואת האמת מתנהגים קצת משונה, בהתחלה הם אמרו שהתקלה נגרמת עקב שינויים בעבודת ה scan engine וסיפקו key ברג'סטרי שיפתור את הבעיה, אז זהו, שהוא לא פתר כלום, אחרי עוד כמה ימים הם אמרו שחזרה ל scan engine 8.3 יפתור את העניין, ובאופן מפתיע (או שלא...) גם זה לא ממש שם סוף לפיאסקו.
בנתיים כבר יש כמה חברות שמאסו בלחכות לתיקון המיוחל ועברו לתוכנות אנטיוירוס אחרות, אבל לא לכולם זה כ"כ פשוט, לפעמים מדובר בעשרות ומאות שרתים, יש צורך בללמוד את המוצר החדש, להסיר את הקיים להתקין את החדש, תהליך לא פשוט (ואני בכלל לא מדבר על הכסף שכל זה יעלה), ולכל השאר נותר רק לחכות ל trend micro שיועילו בטובם לסיים את כל העניין הזה ולהוציא כבר תיקון לבעיה.
עד שלא יהיה תיקון נראה שהדרך היחידה (נניח שלעשות disable ל officescan לא נכללת בחשבון) היא לעשות restart ל- services של officescan כל 20 דקות.
נראה לי שהכי פשוט זה להכין קובץ batch שעושה את העבודה לתזמן אותו כל 20 דקות.
לדוגמא (אני לא סגור איזה services הם הבעיתיים אז אני מאתחל את כולם) :
sc stop tmlisten
sc stop OfcPfwSvc
sc stop ntrtscan
timeout /T 30 /NOBREAK
sc start tmlisten
sc start OfcPfwSvc
sc start ntrtscan |
בכל אופן, אני אעדכן אם יהיה משהו חדש בקשר לזה.
Citrix הוציאו לא מזמן troubleshooting guide (לא ממש מצאתי את השם העברי לעניין) לשלל המוצרים שלהם.
המדריך ממש מפורט ומחולק לפי מה השיוך של התקלה (הדפסה,התחברות וכו') ומה המוצר.
בתוך המסמך ישנם קישורים לתיקונים מומלצים וקישורים לדפי המוצר באתר Citrix.
למעשה, Citrix support מצפה שלפני פניה אליהם הלקוח יבצע את השלבים במסמך בכדי להבין טוב יותר מה הבעיה ולקצר את משך הטיפול.
מאוד מומלץ להשתמש בו גם בלי קשר לפניה לתמיכת Citrix, כי נראה לי שלא מעט תקלות יפתרו תוך כדי עבודה עם המדריך.
Citrix - Brief Troubleshooting Guide
אתמול נתקלתי בכלי שממש מצא חן בעיני לעבודה עם Active Directory של sysinternals (בעצם של מיקרוסופט), ומסתבר שהוא יצא רק בתחילת השבוע.
ה Active Directory Explorer מציג את ה AD Database והאובייקטים שלו לצפיה קלה בתצורת ה Explorer.
ניתן להתחבר ישירות ל AD או לעבוד ב offline עם snapshot שהכיננו מראש (את ה snapshot ניתן לעשות גם כן עם ה AD Explorer).
נוסף על זה, אפשר להשוות בין שני מצבים של ה AD, למשל בין sanpshot שלקחנו לפני שבוע לבין המצב עכשיו.
אפשר להגדיר favorites locations לגישה מהירה יותר בעתיד, לחפש, לשנות ולמחוק (בזהירות, כן...) אובייקטים ב AD.
Active Directory Explorer
אתמול נתקלתי בתוכנה מאוד נחמדה לניהול האפליקציות ב Citrix PS4, היא נקראת Published Applications Utility או בקיצור PAU.
היא מאפשר לבצע כמה פעולות שלא ניתנות לביצוע עם ה Management Console הסטנדרטי של Citrix.
מה ניתן לעשות עם ה PAU:
- לייצא/לייבא את האפליקציות המפובלשות בחווה.
יכול מאוד לעזור בתהליכי מיגרציה בין חוות, במקום ליצור את כל האפליקציות מחדש, פשוט מייצאים את הרשימה מהחווה הישנה ומייבאים לחווה החדשה. - לשייך משתמשים לכמה אפליקציות במקביל.
ב CMC הדיפולטיבי, אם רוצים לשייך משתמשים לכמה אפליקציות, יש צורך לעבור כל אפליקציה ולשייך אליה את המשתמשים הרלוונטים. - לשנות שמות של אפליקציות ע"י Find & Replace.
ניתן להריץ find&replace בדיוק כמו במסמך טקסט ולשנות שמות אפליקציה. - להסתיר/לבטל אפליקציות.
ניתן להסתיר ו/או לעשות disable למספר אפליקציות במקביל. - לייצא/לייבא רשימת שרתים לכל אפליקציה.
- לייצא את הגדרות האפליקציות של החווה לקובץ csv.
הגירסא הנוכחית (1.0) תומכת בנתיים רק ב PS4, תמיכה ב PS4.5 כנראה תגיע בזמן הקרוב.
אה... והתוכנה בנתיים חופשית, דרושה רק הרשמה באתר.
להורדה: PAU
בהמשך לפוסט על מה חדש ב Windows Server 2008 Terminal Server ובהמשך לפוסט על Windows Server 2008 TS RemoteApps, המשך של סקירת ה feature-ים החדשים לעומק.
והיום.... TS Session Broker.
ה Session Broker מכיל למעשה שני אלמנטים, הראשון זה הפעלת load balancing לשרתים (עפ"י מיקרוסופט יעבוד טוב עד 5 שרתים) והשני מיועד לאפשר למשתמשים להתחבר בחזרה ל sessions שלהם בחוות ה TS אשר עובדת עם load balancing.
בטח חלקכם תוהים, מה כבר כל הסיפור, הרי כבר יש לנו את ה Session Directory שיודע לחבר את המשתמשים ל disconnected sessions שלהם עוד מ Windows Server 2003, קודם כל זה נכון, זה באמת קיים... אבל, זה הדבר היחידי שזה עושה, אין שום נגיעה ב load balancing וה session directory קיים רק בגרסת ה enterprise של ה Windows server 2003.
אז איך על העניין הזה עובד, session broker הוא role השייך ל Terminal Services, אבל אין שום צורך להתקין את ה TS עצמו כדי שהשרת הרלוונטי יהיה ה session broker של חוות ה TS.
בכדי ליצור "חוות TS" ולגרום לשרתים לעבוד עם ה session broker יש צורך במספר דברים,להתקין את ה session broker role על אחד השרתים (לווא דווקא TS), להגדיר את שרתי ה TS שיהיו חברים ב Farm ולהגדיר רשומת DNS עם כתובות כל שרתי ה TS כדי שיהיה סוג של load balancing לפני ההתחברות.
למשל, אלה ההגדרות שמוגדרות באחד משרתי ה TS אצלי:
כמו שאפשר לראות, אין פה יותר מדי הגדרות, סה"כ מה שיש פה זה אפשרות להגדיר האם השרת יהיה חבר בחווה עם session broker, מהו שרת ה session broker שלי, מה שם החווה שלי, האם להכניס את השרת לשרתים המשתתפים ב load balanacing ומה המשקל שרוצים לתת לשרת יחסית לשרתים האחרים בחווה (מאין הגדרה מספרית שאנחנו ניתן כדי להגדיר מי השרתים החזקים יותר).
מבחינת ה DNS, אני יוצר רשומה חדשה עם שם החווה שלי (לא חובה, אבל מומלץ) ומקשר לרשומה הזאת את ה ip-ים של שרתי ה TS שלי אשר אני רוצה לכלול בחווה (ה round robin מופעל ב default בשרתי ה DNS של Windows 2003 ו- 2008).
למעשה, ה load balancing נעשה על ידי חלוקה וספירה של sessions בשרתים, אבל ישנם עוד כמה דברים שעוזרים לייצב את המערכת כולה, הראשון ה black hole protection ומובנה בתוך ה session broker, שלמעשה מונע העמסת השרת בכניסות חדשות (login throttling) ופה מגיע סוג של חח למיקרוסופט, כי כמה שנותים לזלזל ב TS הרגיל שלהם (ואני מאמין ד"א שזה ייעלם מהעולם ממש עוד מעט), Citrix הוסיפו את אותו ה feature רק בגרסא האחרונה של ה Presentation Server.
הדבר השני הוא האפשרות לקבוע מספר מרבי של session על שרת ספציפי, ככה שאם אם יש לנו שרת אחד חלש יחסית לאחרים בחווה, אני ארצה להגביל את מספר ה sessions עליו לאותו מספר שבו אני אראה שהוא יוכל לחיות איתו בשלום, אין GUI לעניין הזה, אז נצטרך לשאת פעמינו ל registry ולהגדיר את העניין שם...
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\UserSessionLimit,
דבר נוסף, הוא ה session sharing, עם המשתמש פתח session נגיד עם RemoteApp של Word על שרת מסוים בחווה, כשהוא ירצה להתחבר ל RemoteApp אחר ה session broker יפנה אותו לשרת שאליו המשתמש כבר מחובר, פה יש בעיתיות מסוימת כי מבחינת ה session broker כל שרתי ה TS בחווה דומים ולכולם יש את כל האפליקציות של האחרים ואם זה לא ככה המשתמש יקבל הודעת שגיאה שהאפליקציה לא נמצאה (את האמת, אני לא מבין למה הם לא הוסיפו בדיקה האם האפליקציה קיימת בכלל או לא, זה לא נראה דבר כ"כ מטורף).
עכשיו רק נותר רק לראות איך כל התהליך של חיבור משתמשים לחווה מתרחש...
ובדוגמאות שאני פה, אני אתייחס לתצורה שלי (שני שרתי TS מוגדרים לעבוד עם session broker, שם החווה שלי הוא Commart_TS_Farm, ומוגדר dns round robin בין שני השרתים).
1. המשתמש מתחבר לשרת TS ע"י התחברות למעשה לחווה, (כותב Commart_TS_Farm ב RDP client למשל).
2. הוא מתחיל התחברות לשרת הראשון שהוא קיבל מה DNS (כאמור, מוגדר לי round robin), אם השרת לא זמין מסיבה כזאת או אחרת, הוא ממשיך לשרת הבא ברשימה.
3. כשנוצר connection לשרת, נעשית בדיקה האם הוא חבר ב Session Broker והוא משתתף ב load balancing של החווה.
4. אם כן, השלב הראשון הוא לבדוק האם למשתמש אשר מנסה להתחבר ישנם disconnected sessions באחד מהשרתים, אם כן, אז המשתמש מופנה ל session הישן שלו.
5. אם אין למשתמש שום disconnected sessions בחווה, נעשית ספירה של ה sessions על השרתים (גם הפעילים וגם המנותקים), נלקח בחשבון המשקל שניתן לכל שרת והאם השרת פתוח להתחברות או לא.
6.לאחר כל החישובים המשתמש מופנה לשרת הפחות עמוס בחווה (לפי החישובים בסעיף הקודם).
קצת להמחשה של כל העניין:
סיכומים, עניינים...
כל העניין הזה נראה די מבטיח את האמת, וכן, אני רואה שיש פה סיבוכיות קצת מיותרת ואין התייחסות ל load balancing עפ"י עומס או כל דבר פרט לספירת sessions והתחשבות בנתונים יבשים אחרים, וגם די מוזר לי את האמת למה מיקרוסופט מדגישים בכל פעם שכל הסיפור הזה יעבוד טוב עד למשהו כמו 7 שרתים, כי טכנולוגית אני לא רואה למה זה לא יכול להחזיק גם עם עשרות שרתים, אולי כל זה נועד כדי למנוע בריחה מסיבית של חברות בינוניות מה Presentation Server (ובעיקר ממנו, כי למיקרוסופט ו Citrix יש שותפות עתיקת יומין, ולא נראה שיש רצון מצד שתי החברות לפגוע כך או אחרת אחת בשניה) וכל החלופות השונות.