חיבור QGIS ל‑PostGIS מאחורי VPN: שלב אחר שלב

QGIS קורא כל נתיב שספקי הנתונים שלו יכולים להגיע אליו, כך ש‑VPN פעיל הוא רק חצי מההגדרה. המנהרה נותנת למחשב השולחני נתיב ומדיניות פתרון שמות; הפרויקט עדיין צריך את נקודת הקצה של השירות, את פרוטוקול הספק ואת פרטי ההזדהות שהשירות יקבל. אלו שלוש רשומות נפרדות, והקלדת המאזין הציבורי של ה‑VPN בשדה של מסד נתונים אינה אף אחת מהן. המדריך הזה עוקב אחרי שכבה אחת של PostGIS מטופס ה‑QGIS ועד שורה שמוחזרת, ומציין את הגבול שכל שלב מוכיח.

מתחילים מהשכבה, לא מה‑VPN

כל סוג שכבה מגיע לסוג אחר של נקודת קצה. שכבת PostGIS פותחת חיבור PostgreSQL עם מארח, פורט, מסד נתונים ותפקיד. שכבת WMS או WFS מביאה כתובת URL של שירות ואז מנתחת מסמך יכולות. קובץ shapefile בשיתוף רשת זקוק רק לנתיב קובץ שמערכת ההפעלה יכולה לפתוח. מכיוון שאלו שלושה מנגנונים שונים, פרויקט ריק לא אומר לכם דבר עד שתדעו איזה מהם אתם מנפים.

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

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

הזינו את נקודת הקצה הפרטית שהמפעיל הנפיק

טופס ה‑PostgreSQL ב‑QGIS משקף את השדות ש‑libpq מצפה להם, לכן מלאו אותו באותו סדר שבו חיבור משורת פקודה היה עושה. שירות ומארח מקבלים את מכונת מסד הנתונים, פורט מקבל את המאזין שהשרת באמת פותח, ומסד נתונים מקבל את הקטלוג הספציפי ולא את ברירת המחדל של השרת. אחסנו את הסיסמה בתצורת אימות ולא בקובץ הפרויקט, כדי שפרויקט משותף לא יישא פרטי הזדהות.

הפרידו בין שני השמות לפני שתקלידו משהו. שם השער שייך ללקוח ה‑VPN ושם מסד הנתונים שייך ל‑QGIS, ולעיתים רחוקות מדובר באותו מארח.

VPN gateway:   vpn.gis.lab.example       (profile only, not a data source)
Database host: db.gis.lab.example:5432   (PostGIS service)
Database name: gis_prod
TLS mode:      verify-full

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

שמרו על מצב ה‑TLS של מסד הנתונים בנפרד מהמנהרה

ה‑SSL בשם של מוצר VPN מתאר את המנהרה, לא את הפעלת מסד הנתונים. QGIS מעביר את מצב ה‑SSL של PostgreSQL ל‑libpq, ומצב זה קובע אם הלקוח מאמת את תעודת השרת ואם הוא בודק את שם המארח שבתוכה. verify-fullעושה את שניהם, ולכן זה המצב שכדאי לשמור עליו כשהתעודה נושאת את שם השירות.

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

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

בדקו כל גבול לפי הסדר וקראו את הכשל הראשון

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

getent hosts db.gis.lab.example
nc -vz db.gis.lab.example 5432
psql "host=db.gis.lab.example port=5432 dbname=gis_prod sslmode=verify-full" -c 'select 1'
curl -sS 'https://wms.gis.lab.example/ows?service=WMS&request=GetCapabilities' | head -c 200

תשובה ריקה מgetent היא בעיית פתרון שמות, לא בעיית מסד נתונים. nc שנדחה או שפג זמנו אומר שנתיב או כלל חומת אש חסרים, וזה תיקון בצד השער. שגיאת TLS מpsql אומרת שהתעודה או השם שגויים, בעוד password authentication failed אומרת שהגעתם ל‑PostgreSQL והבעיה היא פרטי ההזדהות. עבור שכבת WMS, הקריאה curl מחזירה את XML היכולות ש‑QGIS היה מנתח, כך שדף התחברות ב‑HTML בפלט הזה מסביר מיד שכבה ריקה.

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

כאשר הפרויקט נפתח עם שכבות ריקות

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

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

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