אין צורך בגילוי Bonjour כדי להדפיס דרך VPN

כנראה אמרו לכם שהדפסה מ-iPhone דרך VPN מחייבת שגילוי Bonjour יחצה את המנהרה. האמונה הזו מפנה אנשים לגשרי TAP וממסרי multicast שלא מתקנים דבר. AirPrint מקבל יעד מפורש: פרופיל תצורה יכול לתת לטלפון את הכתובת, נתיב המשאב והיציאה של מדפסת. הגילוי לא חייב לקרות בכלל כדי שהרשומה הזו תופיע בגיליון ההדפסה. מה שהמטען לא עושה הוא ליצור את המסלול, לגרום למדפסת שאינה AirPrint לדבר IPP או לאשר את העבודה.

המיתוס מתחיל בתצפית נכונה

Bonjour הוא multicast מקומי-לקישור מעצם תכנונו. מנהרה מנותבת מנקודה לנקודה אינה נושאת את הקבוצות האלה, ולכן טלפון ב-VPN לא יכול לעיין במדפסות ב-LAN המרוחק, וגם מחשב נייד באותה מנהרה לא יכול. המסקנה הנכונה אינה שההדפסה זקוקה לגשר; היא שהעיון זקוק למנגנון מסירה אחר, ורשימה מפורשת היא המנגנון הזה.

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

מה המטען באמת נושא

המטען com.apple.airprint מכיל מערך של מילוני מדפסת. כל מילון מקבל IPAddress, שיכול להיות כתובת מילולית או שם מארח, ResourcePath, Port אופציונלי ו-ForceTLS אופציונלי. Apple מתעדת את Port ואת ForceTLS מ-iOS 11 ואילך, ולכן צי מעורב צריך להבהיר זאת לפני הפריסה.

הנתיב הוא השדה שאנשים מנחשים. ResourcePath משקף את הערך rp ברשומת ה-Bonjour של המדפסת _ipps._tcp או _ipp._tcp. הוא לעתים קרובות ipp/print במדפסות מודרניות ללא דרייברים ולעתים קרובות ספציפי ליצרן בדגמים ישנים יותר. העתקת נתיב מדגם אחר יוצרת תור שמופיע ואז דוחה כל עבודה.

פריט במערך נראה כך, עם ערכי מציין מקום שאינם נקודת קצה שנבדקה:

<dict>
    <key>ResourcePath</key>
    <string>ipp/print</string>
    <key>IPAddress</key>
    <string>printer-07.office.example</string>
    <key>Port</key>
    <integer>8631</integer>
    <key>ForceTLS</key>
    <true/>
</dict>

הקטע הזה אינו פרופיל. זהו פריט אחד ממערך AirPrint בתוך מטען, והמטען עדיין זקוק למטא-נתונים משלו בתוספת חתימה או מסירה דרך MDM. מילון המדפסת של AirPrint הוא ההפניה למשמעויות השדות.

אספו את הערכים מהמדפסת, לא מתוצאת חיפוש

ב-Mac שכבר מדפיס להתקן, ippfind או dns-sd -B _ipp._tcp מציג את המופע המפורסם, וממשק האינטרנט של המדפסת עצמה בדרך כלל מפרט את נתיב ה-IPP ואת היציאה. רשמו את כל ארבעת הערכים בהערת הפריסה כדי שהאדם הבא לא יצטרך לגזור אותם שוב מצילום מסך.

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

מסירה, ואז שני כשלים מנוגדים

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

למדפסת שמופיעה אך נכשלת בכל עבודה יש בעיית מסלול, יציאה, נתיב או TLS, ואף אחת מהן אינה נפתרת על ידי המטען.

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

שמרו על הרשומה ניתנת לתחזוקה

העדיפו שם מארח על פני כתובת מילולית היכן שאתם שולטים באזור, כדי ששינוי כתובת לא יפסול כל פרופיל מותקן. שם המארח הזה חייב להיפתר מהטלפון כשהמנהרה פעילה, מה שמחזיר אותו לשיחת split-DNS ולא לשיחת ההדפסה.

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

שום דבר מזה לא הופך מדפסת ליכולה ב-AirPrint. המטען מפרסם יעד, וההתקן עדיין חייב לדבר IPP.