SYN מופנה יכול להגיע ל-Squid בעוד הלקוח עדיין ממתין לפקיעת זמן. בתצורת DNAT גם חבילת החזרה חייבת להגיע לשער שמחזיק במצב התרגום.

שקלו את ה-LAN ההיפותטי הזה:

client 192.168.40.25 → gateway 192.168.40.1
                         DNAT → proxy 192.168.40.10
proxy 192.168.40.10 → client 192.168.40.25 directly

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

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

אל תסירו SNAT בשביל יומנים יפים יותר בלי לאמת את מסלול החזרה. החלה רחבה שלו גם משנה ACL של מקור וייחוס; קבלו את התוצאה הזו כחלק מהתכנון.

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

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

מאמרים קשורים