DNS Caching חלק א – Client Caching

סדרת מאמרים  בסיסיים אלו לגבי שירות ה DNS יעסוק ברשומות DNS שנשמרות ב CACHE הן בשרת והן בתחנות. המדריכים יגע בנקודות כמו זמן השמירה ב cache, יחסי הגומלין בין ה services שאחראים על שמירת ה cache ועוד. המדריכים יתמקדו בסביבות דומיין, אבל אפשר להקיש ממנו גם לגבי סביבת workgroup. חלק א' של הסדרה ייתן פירוט כללי ביותר על dns client service.

ברמת התחנה הבודדת ה service שאחראי על ה cache של התחנה מול שרת DNS נקרא DNS CLIENT. חשוב להבין שה service הזה לא אחראי על עצם היכולת של המחשב לבצע שאילתא ברשת, אלא אך ורק על cache של רשומות DNS, לכן השם של ה service קצת מטעה, ואפשר בטעות לחשוב שמדובר ב service שאחראי על כל יכולות ה DNS של המחשב. כמובן שגם לשרת DNS עצמו יש dns client service, וה service הזה מתפקד בדיוק כמו בתחנה רגילה.

אז איפה בדיוק נוכל לראות ש serviceהזה בא לידי ביטוי?

כולנו מכירים את פקודת IPCONFIG. כאשר הפקודה מורצת עם ה flag של /DISPLAYDNS, היא פונה ל service ומאחזרת ממנו את רשומות ה DNS ששמורות בו. אם נעשה disable ל service, כאשר נריץ את הפקודה IPCONFIG/DISPLAYDNS נגלה שאין לנו גישה לרשומות ה DNS.

כמובן שרשומות ה DNS לא נמחקו, הן פשוט לא נגישות ברגע שה service כבוי. לכן כל פנייה DNS-ית שהייתה יכולה להתקצר בעקבות שימוש ב CACHE, גם היא לא רלוונטית. כמובן שגם אי אפשר לשמור רשומות שמקבלים resolving משאילתות שמבצעים כאשר ה service כבוי (שוב, יש לזכור שגם שה service כבוי, יש יכולת לבצע שאילתא).

פקודה נוספת שלא תרוץ היא מחיקת רשומות ה DNS ששמורות ב CACHE, בעזרת הפקודה IPCONFIG/FLUSHDNS, שוב כי אין גישה ל CACHE בכלל.

שתי הערות אגב לגבי IPCONFIG/FLUSHDNS :

א.  חשוב לציין שאם ישנן רשומות שמופיעות בקובץ ה host שבמחשב (נמצא ב Windows\System32\drivers\etc), אז גם אחרי שננקה את ה cache בעזרת הפקודה הזו, הרשומות שמופיעות בקובץ ה host עדיין יופיעו בעת הרצת הפקודה, כל זאת בהנחה שה service מורץ. אם הוא כבוי, כמובן שלא תהיה גישה גם להצגת רשומות ה host.

ב. לעתים הכרחי להשתמש בפקודה הזו, למרות שזה ימחק רשומות שבהן אנו משתמשים, וזה בגלל שה DNS CLIENT אוגר גם רשומות שלא קיבלו מענה, ומגדיר אותן כרשומות שאין אפשרות לעשות להם resolving. למשל, נניח שניסיתי לתקשר עם מחשב computer3 בדומיין שלי, מחשב שכלל אינו קיים :

איפה יכולה להתעורר הבעיה? תתארו שאחר כך כן מתווסף מחשב כזה, ועכשיו ב cache שלי הוא שמור כלא קיים. תהיה לי בעיה לתקשר איתו, עד שהוא ינוקה מה cache.

אז הנה ניתוח קצר של רשומת DNS :

Record Name – שם הרשומה אותה קיבלנו כתשובה. יכולים להיות מקרים שבהם יש הבדל בין הכותרת לבין השדה הראשון. ההבדל בין הכותרת לבין השדה הזה, זה שבכותרת נמצא השאילתא במדויק, בשדה הזה (Record Name) מופיע ה FQDN, קרי, מדביקים לשאילתא את שם הדומיין שאליו היא שייכת. הנה דוגמה שבה רואים את ההבדל בין הכותרת לבין השדה :

Record Type – מספר שמייצג ערך של שהוא סוג הרשומה. לרשומה  מסוג A, רשומה שממפה שם ל IP, ניתן המספר 1. לרשומה מסוג PTR למשל, רשומה שממפה IP לשם, ניתן המספר 12. המידע פה הוא בעצם metadata (מידע על המידע) אין לו משמעות מעשית.

Time To Live – הזמן  שבו תשמר הרשומה ב cache של ה dns client. הזמן נקבע ע"י שרת ה DNS, במאפייני ה SOA של ה zone אליו שייכת הרשומה. הנה פה :

A RECORD – הרשומה שנותנת את ה IP עצמו, שהכרחי להמשך ההתקשרות בשכבה הבסיסית יותר – שכבת התקשורת.

מהי כתובת 127.0.0.1 ואיך מסדרים בעיות שמתעוררות (חלק א') ?

זהו חלק א' מתוך שניים על כתובת 127.0.0.1 (Loopback). החלק הזה ייתן מידע בסיסי ביותר על הגדרות התקשורת במחשב בדגש על כתובת ה Loopback.

כאשר כרטיס הרשת שבמחשב מחובר למודם, נתב, מתאם שיחות או כל חומרת רשת אחרת, הוא מקבל ממנה נתוני תקשורת ההכרחיים ליצירת המשך ההתקשורת. הפקודה המוכרת לכולנו, המציגה את הנתונים אותם מקבל כרטיס הרשת היא פקודת IPCONFIG. הנה דוגמה לפקודה זו :

בפקודה רואים את הנתונים "ששאב" כרטיס הרשת מחומרת התקשורת אליה הוא מחובר. כתובת ה IPV6, כתובת ה IPV4, המיסוך ושער ברירת המחדל (כתובת הנתב בדוגמה למעלה). אם ברצוננו להציג פרטים נוספים כמו כתובת MAC או כתובת שרת ה DNS (שהוא בדרך כלל הנתב עצמו שמפנה לשרתי DNS), הזמן שנשאר להחזקת כתובת ה IP שהתקבלה ע"י שירות DHCP ועוד, נשתמש בדגל all. :

ipconfig /all.

הנתונים המוצגים כאן מוכרים לכולנו, אבל הם ברמת כרטיס הרשת. ישנם עוד הגדרות תקשורת, הנוגעות לרמת מערכת ההפעלה.

כידוע לכולנו כמעט כל התקשורת היום מתבצע (עדיין) בסט הפרוטוקלים TCP\IP כאשר גרסת פרוטוקול ה IP שבה משתמשים, הן בתקשורת LAN והן בתקשורת WAN, היא 4 – IPV4.

הגדרות התקשורת האלו מוטמעות בתוך מערכת הפעלה, ונותנים לכל מחשב IP שמייצג את תקינות הגדרות התקשורת (TCP\IP) במערכת ההפעלה. כתובת ה IP הזו היא 127.0.0.1. הכתובת הזו נמצאת אמנם בתחום של Class A (יחד עם כל כתובות שנמצאות במיסוך של 255.0.0.0 – מיסוך ששייך ל Class A), אבל כתובות אלו לא מחולקות בכלל משום רכיב תקשורת.

איך בודקים את זה ? 

בדיקה פשוטה בכל מחשב תגלה שכאשר אנו שולחים פינג לכתובת הזו, אנו מקבלים תשובה (replay). התשובה הזו מעידה שהגדרות ה התקשורת (TCP\IP) תקינות במערכת ההפעלה. הנה דוגמה :

חשוב מאד להבין, שלהגדרות תקשורת אלו יש קשר עקיף בלבד לכרטיס הרשת שמחובר או אפילו לא מחובר למחשב. אבל הן בעיקר למערכת ההפעלה. ואפשר להוכיח את זה בקלות : שמתי את כרטיס הרשת היחיד שלי (כרטיס רשת קווי) במצב disable (מבוטל או לא זמין) :

המחשב כרגע לא מסוגל לתקשר בכלל עם אף חומרת רשת אליה הוא מחובר. המחשב מבודד לחלוטין. אם בכל זאת אעשה פינג לכתובת 127.0.0.1 נקבל תשובה תקינה לחלוטין :

שוב, התשובה לעובדה שמקבלים פינג תקין, היא שהפינג לא בודק את יכולות התקשורת של כרטיס הרשת, אלא רק את הגדרות תקשורת ה TCP\IP במערכת ההפעלה. הגדרות אלו כרגע תקינות, אפילו שכרטיס הרשת במצב disable, או אפילו שבכלל לא מחובר כרטיס רשת למחשב!!!

ציינתי למעלה שלהגדרות אלו יש רק קשר עקיף לכרטיס הרשת ספציפי, וזה כי אפשר לבטל את ההגדרות האלו ברמת כרטיס רשת ספציפי ולא ברמת מערכת ההפעלה. עושים את זה ב GUI, ע"י זה שמורידים את סימן ה V מהצ'קבוקס INTERNET PROTOCOL TCP\IPV4 :

איפה רואים את זה ?

כדי לקבל פרטים על הגדרות התקשורת של TCP\IP גרסה 4 (או כל גרסה אחרת). נשתמש בכלי ה NETSH המוכר לכולנו דרך ה CMD, נפעיל כמובן את ה CMD עם הרשאות מנהל .

 הבהרה קטנה לפני השימוש בכלי : בניגוד לפקודות כמו IPCONFIG או TRACERT, המוכרות לכולנו, NETSH הוא ממש כלי שורת פקודה, הוא לא פקודה קטנה עם כמה פרמטרים. אלא כלי חזק ביותר שבאמצעותו אפשר להגיע לנתונים או לבצע פעולות שאין אפשרות להגיע אליהן דרך הממשק הגרפי (GUI). מדובר באחד מכלי ה Shell היותר נרחבים שקיימים במערכת ההפעלה.

אז על מנת לראות את תצורות התקשורת של TCP\IP נשתמש בפקודה הבאה :

netsh int ip show config

הסבר קצר :

המילה הראשונה מייצגת את הכלי (NETSH).

המילה השנייה (int) מייצגת את זה שאנו פונים לממשק מסוים.

המילה השלישית (ip) מייצגת את הממשק שאנו פונים אליו, במקרה הזה כברירת מחדל "ip" מייצג את גרסה 4. אם למשל נרצה להגיע להגדרות גרסה 6, נקיש IP6.

צמד המילים בסוף (show config) מבצע בפועל את פעולת הצגת ההגדרות.

כאשר הפעלתי את הפקודה, כרטיס הרשת היה במצב זמין. הנה התמונה אותו קיבלתי :

שימו לב לדבר היפה בפקודה הזו, שבנוסף להגדרות כרטיס הרשת (כתובת 192.168.1.101 ), מוצגות לנו גם הגדרות ה TCP\IP במערכת ההפעלה (הכותרת מודגשת בצהוב). זאת אומרת, הפקודה  הספציפית הזו היא יותר יסודית במובנים מסוימים מפקודה IPCONFIG.

כאשר כרטיס הרשת יהיה על מצב disable או שבכלל אין כרטיס רשת, אמנם לא יוצגו נתוני כרטיס הרשת, אבל כן יוצגו הגדרות התקשורת TCP\IP. הנה דוגמה :

עד כאן החלק הראשון מתוך שניים. החלק השני יעסוק בבעיות שיכולת להיווצר הקשורות לכתובת הזו ופתרון להן.

הגדרה נכונה של חומת האש של מיקרוסופט

Windows Firewall ו – Windows Firewall with advanced security הן  שתי ישויות שונות במערכות הפעלה של מיקרוסופט – 7 Windows . השילוב בניהן מהווה דוגמה טובה לתכנון שאינו נהיר למשתמש במקרה הטוב, ואולי אפילו לקוי, במקרה הרע.  על מנת להראות זאת, אשתמש בדוגמה שכמעט כל משתמש בווינדוס מכיר – חיבור VPN. רק לצורך ההבהרה, במאמר הזה אשמש בקיצור FW בכל פעם שאדבר על ה Windows Firewall, וב FWAS בכל פעם שאדבר על ה Windows Firewall with advanced security.

ראשית, הקדמה קצרה לגבי חיבור VPN. חיבורי VPN שמשתמשים בהצפנת המידע פונים לשרת ה VPN המרוחק בפורט 1701 כאשר פרוטוקול ההצפנה הוא L2TP, או בפורט 1723 כאשר פרוטוקול ההצפנה הוא PPTP. כמובן שבאמצעות ה Firewall הפשוט בווינדוס 7, יש לנו את האפשרות לחסום, בלי ליצור RULE מיוחד, את היכולת להוציא מהמחשב חיבורי VPN. הפורטים המנוהלים ע"י חומת האש מקוטלגים לקבוצות שנקבעו ע"י מיקרוסופט כמובן. הקבוצה אליה משויכים חיבורי ה VPN נקראת Routing and Remote Access.

כאשר נפתח את ה FW, בתפריט הצדדי נבחר באופציית " Allow program through firewall windows 7", נדפדף לקטגוריית Routing and Remote Access, נראה שהקבוצה הזו מסומנת ב V כברירת מחדל (אמורה להיות מסומנת) :

אם נלך ל FWAS אכן נוכל לראות שהקטגוריה מאופשרים (מחולקת לתתי קטגוריות שמאופשרות) גם כאשר מיקום הרשת הוא ציבורי וגם כאשר הוא פרטי, בדיוק כמו שנקבע בתמונה המוצגת למעלה ב FW :

נניח שאני רוצה לחסום חיבורי VPN מהמחשב שלי. אם נוריד את ה V מהצ'קבוקס של  Routing and Remote Access, בעייני כל אחד זה נראה כאילו הסרנו לחלוטין את האפשרות להתחבר מהמחשב בחיבור VPN.

ה FAWS מתעדכן בהתאם ונראה כך :

אז מה בדיוק הולך פה? הכל נראה שמוגדר כמו שצריך, האינטראקציה בין ה FW ל – FAWS עובדת מעולה. ב FW   ה V  הוסר, ה RULE  ב FWAS  מתעדכן בהתאם ועובר למצב disable, ויש הרושם שביטלנו את היכולת להתחבר ב VPN.

אך כאשר אני מפעיל איזה חייגן VPN רגיל על המחשב, Surprise Surprise, החיבור לשרת המרוחק עובד כמו גדול.

למה?

משום שעקרונית, ה RULES שנמצאים ב FAWS מתנהלים כמו ה GROUP POLICY – GP . כידוע, ה GP מתנהל, בגדול, על שלוש קונפיגורציות כלליות :

1. Not Configured – ברירת המחדל. הכלל "אינו מוגדר", והוא או מאופשר או לא מאופשר, לפי ההגדרות ברג'יסטרי.

2. אפשור של RULE מסוים (enable).

3. ביטול של RULE מסוים (disable).

ליד כל  RULE ב GP יש הסבר קצר מה קורה כאשר הכלל נמצא על מצב של Not Configured – האם הוא מאופשר או לא.

אז אם נעשה את האנלוגיה בין ה GP ל FWAS, ה Not Configured של ה GP הוא שווה ערך ל Disable של ה FWAS- אם הכלל לא הוגדר, לפי איזה ערך ברירת מחדל הוא יעבוד. אז במקרה שלנו, בחיבור VPN שמיוצג ע"י קבוצת Routing and Remote Access, אם הכלל "אינו מוגדר" – Disable, אז ברירת המחדל היא שהחיבור מאופשר (נשמע קצת מבלבל, אבל ככה זה).

לכן, אם לצורך הדוגמה אני רוצה לחסום את היכולת שלי להתחבר לשרת VPN כאשר פרוטוקול ההצפנה הוא PPTP, אני צריך להגיע ל FAWS ולשנות את ה RULE הספציפי עצמו (לפי פרופיל מיקום הרשת public/private כמובן) ל RULE שחוסם, ולא מאפשר (אין צורך ליצור RULE מיוחד), ואז לשים את ה RULE עצמו על מצב enable (חשוב לזכור) :

עכשיו כאשר ננסה להפעיל חיבור VPN עם פרוטוקול הצפנת PPTP, כאשר חומת האש תזהה ב Packets את הפורט המרוחק 1723, תיזרק לנו מיד איזו שגיאה. חיבור ב L2TP יעבוד כמובן כרגיל.

אז מי  שקצת חוקרים ימצא ישר פתרון לשאלה כמו "למה הורדתי את ה V מהצ'קבוקס בחומת האש ואני עדיין יכול להתחבר?" אבל בשביל למשתמש הרגיל הנושא הזה קצת יותר מבלבל, ועדיף למיקרוסופט שתגדיר את הדברים בצורה ברורה יותר בעתיד.