proto udp או tcp-client: איזה מהם השרת שלך שומע?

פרופיל שעבד בחודש שעבר מגיע כעת לפקיעת זמן, ומישהו מציע להחליף את proto udp ב-proto tcp-client. לפעמים זה הצעד הנכון, ולפעמים נוצר לקוח שמתחבר ליציאה שבה דבר אינו מאזין, מפני שהשרת מעולם לא הוגדר לתעבורה האחרת. ההנחיה מתארת איך הצד שלכם מדבר; היא אינה יכולה ליצור מאזין בצד השני. קראו את הפרופיל ואת השרת יחד לפני שתשנו את מי מהם.

קראו את התעבורה שהחיבור הנבחר משתמש בה

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

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

אם בקובץ יש שורת proto אחת סמוך לראש וכמה רשומות remote מתחתיה, השורה הזו היא ברירת המחדל לכל remote שאינו עוקף אותה. עריכה מקומית של ברירת המחדל אינה עושה דבר לרשומת remote שמציינת תעבורה משל עצמה.

grep -nE '^(remote|proto)\b' client.ovpn

UDP ו-TCP אינם הגדרת מהירות

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

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

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

מה tcp-client באמת אומר

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

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

grep -nE '^proto\b' /etc/openvpn/server/server.conf
ss -lntp | grep openvpn

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

כשהפרופיל מיובא אך אינו מתחבר לעולם

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

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

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

רשמו את התעבורה העובדת

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

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

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