ಸರ್ವರ್ಗೆ ಲಾಕ್ ಆದ ಪ್ರೊಫೈಲ್ TLS ಪ್ರಾಕ್ಸಿಯ ಹಿಂದೆ ವಿಫಲವಾಗುತ್ತದೆ: ಯಾವ ಪೀಳಿಗೆ?
Access Server 2.8 ಮತ್ತು 2.9 ಸರ್ವರ್ಗೆ ಲಾಕ್ ಆದ ಪ್ರೊಫೈಲ್ಗಳನ್ನು ಬೇರೆ ರೀತಿಯಲ್ಲಿ ನಿರ್ಮಿಸುತ್ತವೆ. ಫ್ರಂಟ್ ಎಂಡ್ ಬದಲಿಸುವ ಮೊದಲು ನಿಮ್ಮ ಪ್ರಾಕ್ಸಿ ಯಾವ ಮಾರ್ಗವನ್ನು ಮುರಿಯುತ್ತದೆ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸಿ.
ಒಬ್ಬ ಬಳಕೆದಾರ ಸಂಪರ್ಕಿಸಬಹುದು ಮತ್ತೊಬ್ಬ ಸಂಪರ್ಕಿಸಲಾರರು, ಅದೇ ಪೋರ್ಟಲ್ ಮೂಲಕ, ಅದೇ ದಿನ. ಇಬ್ಬರೂ ಸರ್ವರ್ಗೆ ಲಾಕ್ ಆದ ಪ್ರೊಫೈಲ್ಗಳನ್ನು ಹೊಂದಿದ್ದಾರೆ, ಇಬ್ಬರೂ ಒಂದೇ Access Server ಬಿಲ್ಡ್ನಲ್ಲಿದ್ದಾರೆ, ಮತ್ತು ಏಕೈಕ ವ್ಯತ್ಯಾಸ ಅವರ ಪ್ರೊಫೈಲ್ ಯಾವಾಗ ರಚಿಸಲಾಯಿತು ಎಂಬುದು. ಇದು ಗುರುತಿಸಲು ಯೋಗ್ಯವಾದ ಮಾದರಿ, ಏಕೆಂದರೆ "ಸರ್ವರ್ಗೆ ಲಾಕ್ ಆದ" ಎಂಬುದು ಸಂಪರ್ಕ ಕ್ರಮವಲ್ಲ, ನೀತಿಯನ್ನು ಸೂಚಿಸುತ್ತದೆ. Access Server ಆ ಕಲಾಕೃತಿಯ ಎರಡು ಪೀಳಿಗೆಗಳನ್ನು ಬಿಡುಗಡೆ ಮಾಡಿದೆ, ಮತ್ತು TLS ರಿವರ್ಸ್ ಪ್ರಾಕ್ಸಿ ಅವರ ಮಾರ್ಗಗಳಲ್ಲಿ ಒಂದರ ಮುಂದೆ ಮಾತ್ರ ಇದೆ. ನೀವು ಯಾವ ಶಾಖೆಯಲ್ಲಿದ್ದೀರಿ ಎಂಬುದನ್ನು ಮೂರು ಷರತ್ತುಗಳು ನಿರ್ಧರಿಸುತ್ತವೆ.
ಎರಡು ಪೀಳಿಗೆಗಳು, ಎರಡು ಸಂಪರ್ಕ ಕ್ರಮಗಳು
2.8 ರವರೆಗೆ ಜಾರಿಯಲ್ಲಿರುವ ಹಳೆಯ ವಿನ್ಯಾಸದಲ್ಲಿ, ಆಮದು ಮಾಡಿದ ಫೈಲ್ ಸ್ಯೂಡೋ-ಪ್ರೊಫೈಲ್ ಆಗಿದೆ. OpenVPN Connect ಅದನ್ನು HTTPS ಮೂಲಕ Access Server ನ ವೆಬ್ API ಎದುರು ದೃಢೀಕರಣಕ್ಕಾಗಿ ಬಳಸುತ್ತದೆ, ತಾತ್ಕಾಲಿಕ ಬಳಕೆದಾರ-ಲಾಕ್ ಪ್ರೊಫೈಲ್ ಮತ್ತು ಸೆಷನ್ ಟೋಕನ್ ಪಡೆಯುತ್ತದೆ, ಮತ್ತು ನಂತರವೇ VPN ಸ್ಥಾಪಿಸುತ್ತದೆ. ಎರಡು ಸಾರಿಗೆಗಳು ಅನುಕ್ರಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ, ಮತ್ತು ಮೊದಲನೆಯದು ಸಾಮಾನ್ಯ ವೆಬ್ ವಿನಂತಿ.
2.9 ಜೊತೆ ಪರಿಚಯಿಸಿದ ಸ್ವರೂಪವು ಆ ಪ್ರತಿ-ಸಂಪರ್ಕ ಬೂಟ್ಸ್ಟ್ರ್ಯಾಪ್ ಮಾಡುವುದಿಲ್ಲ. ಇದು ಸ್ಥಳೀಯ ಪ್ರೊಫೈಲ್ ಆಗಿದ್ದು, ಹೊಂದಿಕೊಳ್ಳುವ OpenVPN ಕ್ಲೈಂಟ್ಗಳು ಬಳಸಬಹುದು, ಕೇವಲ OpenVPN Connect ಮಾತ್ರವಲ್ಲ. ಅದನ್ನು ಡೌನ್ಲೋಡ್ ಮಾಡುವುದು ಅಥವಾ URL ಮೂಲಕ ಆಮದು ಮಾಡುವುದು ಇನ್ನೂ HTTPS ಒಳಗೊಳ್ಳಬಹುದು — ಅದು ಪ್ರಕಟಣೆಯ ಹಂತ, ಪ್ರತಿ-ಸಂಪರ್ಕ ತಾತ್ಕಾಲಿಕ ಪ್ರೊಫೈಲ್ ಸೆಳೆಯುವುದಲ್ಲ.
| Older server-locked (≤2.8) | Newer server-locked (2.9+) | |
|---|---|---|
| Before the tunnel | Web API call with credentials | Nothing; the profile is already local |
| Client requirement | OpenVPN Connect | Any compatible client |
| What a TLS web proxy can break | The bootstrap, before any VPN attempt | Download only, not the connection |
| Expected HTTP log on connect | A request from the client | Often nothing at all |
ನವೀಕರಣವು ಈಗಾಗಲೇ ನೀಡಲಾದ ಪ್ರೊಫೈಲ್ಗಳನ್ನು ಅಗತ್ಯವಾಗಿ ಮರುಬರೆಯುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಪ್ರಸ್ತುತ ಸರ್ವರ್ ಆವೃತ್ತಿ ಇನ್ನೂ ಹಳೆಯ ಕಲಾಕೃತಿಯನ್ನು ವಿತರಿಸಬಹುದು. ಸರ್ವರ್ ಬಿಲ್ಡ್ ಏನು ಸಾಧ್ಯ ಎಂದು ಹೇಳುತ್ತದೆ, ಈ ಬಳಕೆದಾರ ಏನು ಆಮದು ಮಾಡಿದರು ಎಂದಲ್ಲ.
ನಿಮ್ಮ ಶಾಖೆಯನ್ನು ಆಯ್ಕೆ ಮಾಡುವ ಮೂರು ಷರತ್ತುಗಳು
ಮೊದಲ ಷರತ್ತು ಕಲಾಕೃತಿಯ ಪೀಳಿಗೆ. ಫೈಲ್ ಕೇಳಿ, ಅದು ಹೇಗೆ ತಯಾರಾಯಿತು ಎಂದು ನೋಡಿ, ಮತ್ತು ಅದನ್ನು ಆಮದು ಮಾಡಿದ ಕ್ಲೈಂಟ್ ಆವೃತ್ತಿಯನ್ನು ಗಮನಿಸಿ. ಫೈಲ್ನಿಂದ ಪೀಳಿಗೆಯನ್ನು ನಿರ್ಧರಿಸಲು ಸಾಧ್ಯವಾಗದಿದ್ದರೆ, ಪರೀಕ್ಷಾ ಖಾತೆಗೆ ನೀಡಿದ ಹೊಸ ಪ್ರೊಫೈಲ್ ಸರ್ವರ್ ಇಂದು ಏನು ಉತ್ಪಾದಿಸುತ್ತದೆ ಎಂದು ಹೇಳುತ್ತದೆ, ಮತ್ತು ಇದು ವಿಫಲವಾದ ಬಳಕೆದಾರರಲ್ಲಿರುವ ಮಾಹಿತಿಗಿಂತ ಭಿನ್ನವಾಗಿದೆ.
ಎರಡನೆಯದು ನಿಮ್ಮ ಫ್ರಂಟ್ ಎಂಡ್ ನಿಜವಾಗಿ ಏನನ್ನು ಕೊನೆಗೊಳಿಸುತ್ತದೆ ಎಂಬುದು. TLS ಅನ್ನು ಇಳಿಸುವ ಏಳನೇ ಪದರದ HTTP ರಿವರ್ಸ್ ಪ್ರಾಕ್ಸಿ ನಾಲ್ಕನೇ ಪದರದ TCP ಫಾರ್ವರ್ಡರ್ನಂತೆಯೇ ಅಲ್ಲ, ಮತ್ತು UDP ಫಾರ್ವರ್ಡರ್ ಕೂಡ ಅಲ್ಲ. ಪೋರ್ಟ್ 443 ನಲ್ಲಿ Access Server ನ ಸಾಮಾನ್ಯ ಜೋಡಣೆ OpenVPN TCP ಡೀಮನ್ ಬ್ರೌಸರ್ ಸಂಚಾರವನ್ನು ಗುರುತಿಸಿ ಅದನ್ನು ವೆಬ್ ಸೇವೆಗಳಿಗೆ ಒಪ್ಪಿಸುವಂತೆ ಮಾಡುತ್ತದೆ, ಆದ್ದರಿಂದ ಮುಂದೆ ಸಂಬಂಧವಿಲ್ಲದ HTTPS ಟರ್ಮಿನೇಟರ್ ಸೇರಿಸುವುದು ಆ ಡೀಮನ್ನ ಪ್ರೋಟೋಕಾಲ್ ನಿರ್ವಹಣೆಯನ್ನು ಉಳಿಸುವುದಿಲ್ಲ. ಒಂದೇ ಸಂಖ್ಯೆ 443 ಹಂಚಿಕೊಳ್ಳುವುದು ಎರಡು ವಿನ್ಯಾಸಗಳನ್ನು ಸಮಾನವಾಗಿಸುವುದಿಲ್ಲ.
ಮೂರನೆಯದು ವೈಫಲ್ಯ ಎಲ್ಲಿ ಬೀಳುತ್ತದೆ ಎಂಬುದು. VPN ಮೊದಲಿನ ವೈಫಲ್ಯ ಮತ್ತು ನಿಯಂತ್ರಣ ಕಾಲುವೆಯ ವೈಫಲ್ಯ "ಸಂಪರ್ಕಿಸುತ್ತಿದೆ" ಎಂದು ಮಾತ್ರ ಹೇಳುವ ಕ್ಲೈಂಟ್ನಲ್ಲಿ ಒಂದೇ ರೀತಿ ಕಾಣುತ್ತವೆ, ಆದರೆ ಅವು ಬೇರೆ ಬೇರೆ ಸ್ಥಳಗಳಲ್ಲಿ ಸಾಕ್ಷ್ಯ ಬಿಡುತ್ತವೆ. ಹಳೆಯ ಸ್ವರೂಪ ಬಳಕೆಯಲ್ಲಿದ್ದರೆ ಬೂಟ್ಸ್ಟ್ರ್ಯಾಪ್ ಅಭ್ಯರ್ಥಿ. ಹೊಸ ಸ್ವರೂಪ ಬಳಕೆಯಲ್ಲಿದ್ದರೆ ಖಾಲಿ ವೆಬ್ ಪ್ರವೇಶ ಲಾಗ್ ನಿರೀಕ್ಷಿತವಾಗಿದ್ದು ಯಾವ ದಿಕ್ಕಿನಲ್ಲೂ ಏನನ್ನೂ ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ.
ಕಲಾಕೃತಿ ಹಳೆಯದಾದಾಗ: ಬೂಟ್ಸ್ಟ್ರ್ಯಾಪ್ ಮೊದಲು ವಿಫಲವಾಗುತ್ತದೆ
ಕ್ಲೈಂಟ್ನ ಅಂತಿಮ ಸ್ಥಿತಿಯ ಬದಲು ಅದರ ನಿಜವಾದ ದೋಷವನ್ನು ಓದಿ. ಆಸಕ್ತಿಯ ಕ್ಷೇತ್ರಗಳೆಂದರೆ HTTPS ದೋಷ, ಕ್ಲೈಂಟ್ ನಿರೀಕ್ಷಿಸಿದ ಸರ್ವರ್ ಗುರುತು, ವಿನಂತಿ ಹೋದ ಗಮ್ಯಸ್ಥಾನ, ಮತ್ತು ಪ್ರಮಾಣಪತ್ರ ಪರಿಶೀಲನೆ ಪೂರ್ಣಗೊಂಡಿತೇ ಎಂಬುದು. ನಂತರ ಅವುಗಳನ್ನು ಸರ್ವರ್ ಬದಿಯ ವೆಬ್ ಸೇವೆ ಮತ್ತು ಪ್ರಾಕ್ಸಿ ಲಾಗ್ಗಳೊಂದಿಗೆ ಹೋಲಿಸಿ.
ಬ್ರೌಸರ್ ಲಾಗಿನ್ ಪುಟವನ್ನು ತಲುಪುವುದು ಈ ಕ್ಲೈಂಟ್ನ API ದೃಢೀಕರಣ ಯಶಸ್ವಿಯಾಯಿತು ಎಂಬುದಕ್ಕೆ ಸಾಕ್ಷ್ಯವಲ್ಲ. ಇವು ಬೇರೆ ಬೇರೆ ವಿನಂತಿಗಳು, ಬೇರೆ ಪ್ರಮಾಣಪತ್ರ ನಿರೀಕ್ಷೆಗಳು ಮತ್ತು ಸಾಮಾನ್ಯವಾಗಿ ಬೇರೆ ಹೋಸ್ಟ್ನಾಮ್ಗಳು. ಪೋರ್ಟಲ್ ಸರಿಯಾಗಿ ಸೇವೆ ಸಲ್ಲಿಸಿದರೂ ಕ್ಲೈಂಟ್ ವಿಫಲವಾದರೆ, ಭಿನ್ನಾಭಿಪ್ರಾಯ ಬೂಟ್ಸ್ಟ್ರ್ಯಾಪ್ ಮಾರ್ಗದಲ್ಲಿದೆ, ಬಳಕೆದಾರರ ಪಾಸ್ವರ್ಡ್ನಲ್ಲಿ ಅಲ್ಲ.
TLS ಪರಿಶೀಲನೆಯನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಿ ಅಥವಾ ದೃಢೀಕರಣ ನೀತಿಯನ್ನು ಸಡಿಲಗೊಳಿಸಿ ಹೋಲಿಕೆಯನ್ನು ಯಶಸ್ವಿಗೊಳಿಸಬೇಡಿ. ಅದು ರೋಗನಿರ್ಣಯ ಮಾಡಬಹುದಾದ ಸಂರಚನಾ ಹೊಂದಾಣಿಕೆಯನ್ನು ಕೆಲಸ ಮಾಡುವ ಆದರೆ ಪರಿಶೀಲಿಸದ ಮಾರ್ಗವಾಗಿ ಪರಿವರ್ತಿಸುತ್ತದೆ, ಮತ್ತು ತಾತ್ಕಾಲಿಕ ಪರೀಕ್ಷೆಯನ್ನು ಶಾಶ್ವತ ರಂಧ್ರವಾಗಿ ಪರಿವರ್ತಿಸುವ ಬದಲಾವಣೆ ಅದೇ. Access Server ನ ಸಂಪರ್ಕ-ಪ್ರೊಫೈಲ್ ದಾಖಲೆ ಎರಡೂ ಪೀಳಿಗೆಗಳು ಮತ್ತು ತಾತ್ಕಾಲಿಕ-ಪ್ರೊಫೈಲ್ ಹರಿವನ್ನು ವಿವರಿಸುತ್ತದೆ, ಮತ್ತು ಪ್ರಾಕ್ಸಿಯನ್ನು ದೋಷಿ ಎಂದು ಭಾವಿಸುವ ಮೊದಲು ಪರಿಶೀಲಿಸಬೇಕಾದ ಉಲ್ಲೇಖ ಅದು.
ಕಲಾಕೃತಿ ಹೊಸದಾದಾಗ: ಬದಲಾಗಿ ನಿಯಂತ್ರಣ ಕಾಲುವೆಯನ್ನು ಓದಿ
2.9 ಶೈಲಿಯ ಪ್ರೊಫೈಲ್ನೊಂದಿಗೆ ಕ್ಲೈಂಟ್ ನೇರವಾಗಿ ಸ್ಥಳೀಯ VPN ಅಂತಿಮ ಬಿಂದುವಿಗೆ ಹೋಗುತ್ತದೆ. ಪ್ರೊಫೈಲ್ನಲ್ಲಿನ ಅಂತಿಮ ಬಿಂದುಗಳು, ಬಳಸಿದ ಸಾರಿಗೆ, ಮತ್ತು ನಿಯಂತ್ರಣ ಕಾಲುವೆಯ ದೋಷವನ್ನು ತನಿಖೆ ಮಾಡಿ. ಕ್ಲೈಂಟ್ ಎಂದೂ HTTP ವಿನಂತಿ ನೀಡದಿದ್ದರೆ, ಅದು ವಿನ್ಯಾಸಕ್ಕೆ ಸರಿಹೊಂದುತ್ತದೆ ಮತ್ತು ಲಕ್ಷಣವಲ್ಲ.
ಇಲ್ಲಿ ಪ್ರಾಕ್ಸಿ ಪ್ರಶ್ನೆಯೂ ಆಕಾರ ಬದಲಿಸುತ್ತದೆ. HTTPS ಇಳಿಕೆ ಎಂದೂ ನೋಡದ ಕೇವಲ-TCP ಸ್ಟ್ರೀಮ್ ಅನ್ನು ಮುರಿಯಲಾರದು, ಆದರೆ ಪ್ರೊಫೈಲ್ ಪ್ರಕಟಿಸುವ ಡೌನ್ಲೋಡ್ ಅನ್ನು ಇನ್ನೂ ಮುರಿಯಬಹುದು, ಮತ್ತು ಕೇವಲ-TCP ಫಾರ್ವರ್ಡರ್ UDP ಅನ್ನು ಸ್ವಲ್ಪವೂ ಸಾಗಿಸುವುದಿಲ್ಲ. ಫ್ರಂಟ್ ಎಂಡ್ ಅಪ್ರಸ್ತುತ ಎಂದು ತೀರ್ಮಾನಿಸುವ ಮೊದಲು ಪ್ರೊಫೈಲ್ ಯಾವ ಸಾರಿಗೆ ಬಯಸುತ್ತದೆ ಎಂದು ಪರಿಶೀಲಿಸಿ.
ಒಂದೇ ಸ್ಟ್ರೀಮ್ಗೆ TLS ಪಾಸ್ತ್ರೂ ಸಂಕುಚಿತ ಜೋಡಣೆ. ಅದು UDP ಫಾರ್ವರ್ಡಿಂಗ್ ಒದಗಿಸುವುದಿಲ್ಲ, ಮತ್ತು 443 ನಲ್ಲಿ ಡೀಮನ್ನ ಸ್ವಂತ ಸೇವಾ-ಫಾರ್ವರ್ಡಿಂಗ್ ನಡವಳಿಕೆಯನ್ನು ಮರುಸೃಷ್ಟಿಸುವುದಿಲ್ಲ. ನಿಮ್ಮ ಫ್ರಂಟ್ ಎಂಡ್ ಅವುಗಳಲ್ಲಿ ಒಂದನ್ನು ಮಾಡಿದರೆ ಯಾವುದು ಎಂದು ಹೇಳಿ, ಏಕೆಂದರೆ ಪರಿಹಾರ ಭಿನ್ನವಾಗಿದೆ.
ಸಂಕುಚಿತವಾಗಿ ಉಳಿಯುವ ಪರಿಹಾರಗಳು
ಅತ್ಯಂತ ಕಡಿಮೆ ಹಸ್ತಕ್ಷೇಪದ ಪರಿಶೀಲನೆ ಎಂದರೆ ಪರೀಕ್ಷಾ ಖಾತೆಗೆ ಹೊಸ ಬೆಂಬಲಿತ ಪ್ರೊಫೈಲ್ ರಚಿಸಿ ಅದೇ ದೃಢೀಕರಣ ಅಗತ್ಯಗಳೊಂದಿಗೆ ಉದ್ದೇಶಿತ ಸ್ಥಳೀಯ ಅಂತಿಮ ಬಿಂದುವಿನ ಮೂಲಕ ಸಂಪರ್ಕಿಸುವುದು. ಅದು ಕೆಲಸ ಮಾಡಿ ಉಳಿಸಿಕೊಂಡ ಹಳೆಯ ಪ್ರೊಫೈಲ್ ಮಾಡದಿದ್ದರೆ, ನೀವು ಒಂದು ಹಂತದಲ್ಲಿ ಕಲಾಕೃತಿಯನ್ನು ಸರ್ವರ್ನಿಂದ ಮತ್ತು ಪ್ರಾಕ್ಸಿಯಿಂದ ಪ್ರತ್ಯೇಕಿಸಿದ್ದೀರಿ.
ಬಳಕೆದಾರ-ಲಾಕ್ ಪ್ರೊಫೈಲ್ನ ವಿತರಣೆ ಹಳೆಯ ಬೂಟ್ಸ್ಟ್ರ್ಯಾಪ್ ಅವಲಂಬನೆಯನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ತೆಗೆದುಹಾಕುತ್ತದೆ, ಏಕೆಂದರೆ ವಿಫಲವಾಗಬಹುದಾದ ತಾತ್ಕಾಲಿಕ-ಪ್ರೊಫೈಲ್ ವಿನಿಮಯವಿಲ್ಲ. ಅದನ್ನು ಉದ್ದೇಶಿತ ಬಳಕೆದಾರರಿಗೆ ನೀಡಬೇಕು, ಎಂದೂ ನಿರ್ವಾಹಕರಿಂದ ನಕಲಿಸಬಾರದು, ಮತ್ತು ಅದು ಕ್ಲೈಂಟ್ ಯಾವುದಕ್ಕೆ ಅಧಿಕೃತವಾಗಿದೆ ಎಂಬುದನ್ನು ಬದಲಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಅದನ್ನು ತಾತ್ಕಾಲಿಕ ಉಪಾಯವಲ್ಲ, ನೀತಿ ನಿರ್ಣಯವೆಂದು ಪರಿಗಣಿಸಿ.
ನಂತರ ಪ್ರಕಟಣಾ ವಿನ್ಯಾಸವನ್ನು ಪ್ರತಿ ಅಗತ್ಯ ಮಾರ್ಗವೂ ಇರುವಂತೆ ಸರಿಪಡಿಸಿ: ಡೌನ್ಲೋಡ್ಗಳು ಮತ್ತು ಪೋರ್ಟಲ್ ಬಳಕೆಗೆ ವೆಬ್ ಮಾರ್ಗ, ಮತ್ತು ಪ್ರೊಫೈಲ್ಗಳು ನಿರೀಕ್ಷಿಸುವ ಸಾರಿಗೆಯಲ್ಲಿ ಸ್ಥಳೀಯ VPN ಮಾರ್ಗ. ಪ್ರಾಕ್ಸಿಯ ಕೆಲಸವನ್ನು ಒಂದೇ ಪದರದಲ್ಲಿ ಇರಿಸಿ. ಕೆಲಸ ಮಾಡುವ ಬಳಕೆದಾರ-ಲಾಕ್ ಸುರಂಗ ಆ ಮಾರ್ಗ ಕೆಲಸ ಮಾಡುತ್ತದೆ ಎಂದು ಸಾಬೀತುಪಡಿಸುತ್ತದೆ; ಪ್ರತಿ ಪ್ರಾಕ್ಸಿ ಜೋಡಣೆಯೂ ಪ್ರತಿ ಪೀಳಿಗೆಯನ್ನು ಬೆಂಬಲಿಸುತ್ತದೆ ಎಂದು ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ, ಮತ್ತು ಹಳೆಯ ಬೂಟ್ಸ್ಟ್ರ್ಯಾಪ್ ವೈಫಲ್ಯ ಹೊಸ ಸ್ವರೂಪವನ್ನು ಖಂಡಿಸುವುದಿಲ್ಲ.
- ಪ್ರಾಕ್ಸಿಯನ್ನು ಮುಟ್ಟುವ ಮೊದಲು ಕಲಾಕೃತಿಯ ಪೀಳಿಗೆಯನ್ನು ಗುರುತಿಸಿ.
- ವೈಫಲ್ಯ ಸುರಂಗದ ಮೊದಲು ಸಂಭವಿಸುತ್ತದೆಯೇ ಅಥವಾ ಅದರೊಳಗೆ ಎಂದು ನಿರ್ಧರಿಸಿ.
- ಫ್ರಂಟ್ ಎಂಡ್ ಏನನ್ನು ಕೊನೆಗೊಳಿಸುತ್ತದೆ ಎಂದು ಖಚಿತಪಡಿಸಿ: HTTP, TCP ಸ್ಟ್ರೀಮ್, ಅಥವಾ UDP.
- ನೀತಿ ಬದಲಾಗದೆ ಹೊಸದಾಗಿ ನೀಡಿದ ಪ್ರೊಫೈಲ್ ಅನ್ನು ಸ್ಥಳೀಯ ಅಂತಿಮ ಬಿಂದುವಿನ ಎದುರು ಪರೀಕ್ಷಿಸಿ.