VPN ಗೇಟ್‌ವೇ ಅಪ್‌ಡೇಟ್ ವಿಫಲವಾಗುತ್ತದೆ: ಹೊರಹೋಗುವ ದಾರಿ ತೆರೆಯುವ ಮೊದಲು ಹಂತವನ್ನು ಓದಿ
ವಿಫಲವಾದ ಅಪ್‌ಡೇಟ್ ಕಾಣೆಯಾದ ಪೋರ್ಟ್ ಅನ್ನಲ್ಲ, ಒಂದು ಹಂತವನ್ನು ಹೆಸರಿಸುತ್ತದೆ. ಸಂದೇಶವನ್ನು ಅದರ ಮಾಲೀಕರೊಂದಿಗೆ ಹೊಂದಿಸಿ, ಪ್ರಾಕ್ಸಿ ಮಾರ್ಗವನ್ನು ಓದಿ, ನಂತರ ನಿರ್ವಹಣಾ ನೀತಿಯನ್ನು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ನಿರ್ಧರಿಸಿ.
ಭದ್ರತಾ ಅಪ್‌ಡೇಟ್‌ಗಳನ್ನು ಸ್ಥಾಪಿಸಲು ನಿರಾಕರಿಸುವುದು ಬೇರೆಯವರ ಸಮಸ್ಯೆಯಾಗಲು ಒಂದು ಕೆಟ್ಟ ವಾರದಷ್ಟೇ ದೂರದಲ್ಲಿದೆ, ಮತ್ತು ಕ್ಲೈಂಟ್‌ಗಳನ್ನು ಒಳಗೆ ಬಿಡುವ ಗೇಟ್‌ವೇ ಆ ಅಭ್ಯಾಸವನ್ನು ಬೆಳೆಸಲು ಸುಲಭವಾದ ಸ್ಥಳ. ಸಾಮಾನ್ಯ ಕಾರಣ ಕಾಣೆಯಾದ ಮಾರ್ಗವಲ್ಲ, ಕಾಣೆಯಾದ ನಿರ್ಧಾರ: ಕ್ಲೈಂಟ್ ಫಾರ್ವರ್ಡಿಂಗ್ ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಸಂಕುಚಿತವಾಗಿರುವಾಗ ಹೋಸ್ಟ್ ಸ್ವತಃ ಒಂದು ಭಂಡಾರವನ್ನು ಹೇಗೆ ತಲುಪಬೇಕೆಂದು ಯಾರೂ ಹೇಳಲಿಲ್ಲ. ಆ ನಿರ್ಧಾರ ಸ್ಪಷ್ಟವಾಗಿ ತೆಗೆದುಕೊಳ್ಳಬೇಕು, ಮತ್ತು ಅದು ಒಂದು ಮಧ್ಯಾಹ್ನ ಹೊರಹೋಗುವ ನೀತಿಯನ್ನು ಆಫ್ ಮಾಡುವುದಕ್ಕಿಂತ ಸಂಕುಚಿತವಾಗಿರಬೇಕು.
ನಾಲ್ಕು ಹಂತಗಳು, ನಾಲ್ಕು ವಿಭಿನ್ನ ಮಾಲೀಕರು
ಅಪ್‌ಡೇಟ್ ವೈಫಲ್ಯವು ಒಂದು ಹೆಸರಿಸಲಾದ ಹಂತ, ಸಂದೇಶ ಅದನ್ನು ಹೇಳಿದರೂ ಹೇಳದಿದ್ದರೂ, ಮತ್ತು ಪ್ರತಿ ಹಂತ ಬೇರೆ ಮಾಲೀಕರಿಗೆ ಸೇರಿದೆ. ಪರಿಹರಿಸಲಾಗದ ಹೆಸರು ರಿಜಾಲ್ವರ್‌ನ ಪ್ರಶ್ನೆ. ಸಮಯ ಮೀರುವ ಸಂಪರ್ಕ ಸಾರಿಗೆ, ಪ್ರಾಕ್ಸಿ ಅಥವಾ ದೂರದ ತುದಿಯ ಪ್ರಶ್ನೆ. TLS ಗುರುತಿನ ದೋಷ ವಿಶ್ವಾಸದ ಪ್ರಶ್ನೆ, ಮತ್ತು ತಿರಸ್ಕರಿಸಿದ ಭಂಡಾರ ಮೆಟಾಡೇಟಾ ಸಹಿಯ ಪ್ರಶ್ನೆ. ನಾಲ್ಕು ಹಂತಗಳು, ನಾಲ್ಕು ಮಾಲೀಕರು, ಮತ್ತು ಪೋರ್ಟ್ ನಿಯಮ ಯಾವಾಗಲೂ ಅವುಗಳಲ್ಲಿ ಒಂದಕ್ಕೆ ಮಾತ್ರ ಉತ್ತರಿಸುತ್ತದೆ.
| The failure text mentions | Which component owns it | What you check first | What you must not change |
|---|---|---|---|
| a name that will not resolve | the resolver policy for this host | which resolver is used, and whether its path is permitted | nothing in the firewall: no repository packet has left yet |
| a connection that times out | routing, proxy or the far end | the destination, port and proxy the manager actually attempts | the egress policy, before you know that destination |
| a TLS identity mismatch | trust configuration and the server's identity | the chain the manager is presented with | verification settings, which only hide the mismatch |
| rejected archive metadata | the repository's signing metadata | whether the source carries valid, trusted metadata | the signature check, which is not a routing question |
ಪಿಂಗ್ ಮತ್ತು ಹೆಸರು ಪರಿಹಾರ ಜನರು ಮೊದಲು ಆಶ್ರಯಿಸುವ ಎರಡು ಪರೀಕ್ಷೆಗಳು, ಮತ್ತು ಎರಡೂ ಯಾರೂ ಕೇಳದ ಪ್ರಶ್ನೆಗಳಿಗೆ ಉತ್ತರಿಸುತ್ತವೆ. ಎಕೋ ಪ್ರತಿಕ್ರಿಯೆ ಭಂಡಾರ ಸಂಪರ್ಕಕ್ಕಿಂತ ಬೇರೆ ಪ್ರೋಟೋಕಾಲ್ ಬಳಸುತ್ತದೆ, ಮತ್ತು ಯಶಸ್ವಿ ಹುಡುಕಾಟ ಡೌನ್‌ಲೋಡ್ ಪರೀಕ್ಷಿಸದೆ ಹೆಸರು ಪರಿಹಾರದಲ್ಲಿ ನಿಲ್ಲುತ್ತದೆ. ಎರಡೂ ನಿಜವಾದ ವಹಿವಾಟು ವಿಫಲವಾಗುವಾಗ ಪಾಸ್ ಆಗಬಹುದು, ಮತ್ತು ಎರಡೂ ಮಾರ್ಗಕ್ಕೆ ಸಂಬಂಧವಿಲ್ಲದ ಕಾರಣಗಳಿಂದ ವಿಫಲವಾಗಬಹುದು.
ಮ್ಯಾನೇಜರ್ ನಿಜವಾಗಿ ತೆಗೆದುಕೊಳ್ಳುವ ಮಾರ್ಗವನ್ನು ಓದಿ
ಕಾನ್ಫಿಗರ್ ಮಾಡಿದ ಮೂಲ URIಗಳು ಮತ್ತು ಪ್ರಾಕ್ಸಿಯ ನಿಜವಾದ ಜೋಡಣೆಯನ್ನು ಪರಿಶೀಲಿಸಿ, ಅವುಗಳಲ್ಲಿ ಒಂದನ್ನು ಊಹಿಸುವ ಬದಲು. ಸಾಮಾನ್ಯ HTTPಗಾಗಿ ಬರೆದ ನಿಯಮ ಭಂಡಾರ HTTPS ಮಾತನಾಡುವಾಗ ದುರಸ್ತಿಯಲ್ಲ, ಮತ್ತು ಪ್ರಾಕ್ಸಿಯನ್ನು ಕಡ್ಡಾಯ ಮಾಡುವ ಸಂಸ್ಥೆ ಮಾರ್ಗವನ್ನು ಈಗಾಗಲೇ ಆಯ್ಕೆ ಮಾಡಿದೆ. ಪ್ಯಾಕೇಜ್ ಮ್ಯಾನೇಜರ್‌ಗಳು ಪರಿಸರ ಚರಗಳು ಮತ್ತು ತಮ್ಮ ಸಂರಚನೆಯನ್ನು ಗೌರವಿಸುತ್ತವೆ, ಮತ್ತು ಹೋಸ್ಟ್-ನಿರ್ದಿಷ್ಟ ಸೆಟ್ಟಿಂಗ್‌ಗಳು ಜಾಗತಿಕ ಸೆಟ್ಟಿಂಗ್ ಅನ್ನು ಮೀರಿಸಬಹುದು. ಸಂವಾದಾತ್ಮಕ ಬ್ರೌಸರ್ ಮಾಡುವುದು ಮ್ಯಾನೇಜರ್ ಮಾಡಬೇಕೆಂದೇನಿಲ್ಲ.
apt-get update -o Debug::Acquire::http=true
apt-config dump | grep -i proxy
env | grep -i proxyAPT ಸಾರಿಗೆ ದಾಖಲೆಗಳು ಯಾವ ಸೆಟ್ಟಿಂಗ್ ಯಾವ URI ಯೋಜನೆಗೆ ಅನ್ವಯಿಸುತ್ತದೆ ಮತ್ತು ಹೋಸ್ಟ್-ನಿರ್ದಿಷ್ಟ ಆಯ್ಕೆಗಳನ್ನು ಹೇಗೆ ಬರೆಯಲಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ವಿವರಿಸುತ್ತವೆ. ಆದೇಶಗಳ ಔಟ್‌ಪುಟ್ ಅನ್ನು ಟಿಕೆಟ್‌ನೊಂದಿಗೆ ಇರಿಸಿ, ಏಕೆಂದರೆ ಇದು ಪ್ರಾಕ್ಸಿ ಸಮಸ್ಯೆಯನ್ನು ಕಾಣೆಯಾದ ಮಾರ್ಗದಿಂದ ಎಷ್ಟೇ ಪಿಂಗ್ ಫಲಿತಾಂಶಗಳಿಗಿಂತ ವೇಗವಾಗಿ ಬೇರ್ಪಡಿಸುತ್ತದೆ. ಮ್ಯಾನೇಜರ್ ಪ್ರಯತ್ನಿಸುವ ನಿಖರವಾದ ಗಮ್ಯಸ್ಥಾನ, ಪೋರ್ಟ್ ಮತ್ತು ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ಬರೆಯಿರಿ, ಮತ್ತು ಫೈರ್‌ವಾಲ್ ಬದಲಾವಣೆ ತಿಂಗಳುಗಳಲ್ಲಿ ಹಳೆಯದಾಗುವ ಊಹಿಸಿದ ಮಿರರ್ ವಿಳಾಸಕ್ಕಿಂತ ಆ ದಾಖಲೆಯ ಮೇಲೆ ನಿಂತಿರಲಿ.
ನಿರ್ವಹಣಾ ನೀತಿಯನ್ನು ಆಯ್ಕೆಮಾಡಿ, ವಿನಾಯಿತಿ ಅಲ್ಲ
ಮೂರು ನೀತಿಗಳು ಸಮರ್ಥನೀಯ: ಸುರಂಗದ ಮೂಲಕ ನಿರ್ವಹಣೆ, ನಿರ್ವಹಿತ ಅಪ್‌ಡೇಟ್ ಪ್ರಾಕ್ಸಿಯ ಮೂಲಕ ನಿರ್ವಹಣೆ, ಅಥವಾ ಸಂಕುಚಿತ ಅಧಿಕಾರ ಪಡೆದ ನೇರ ಮಾರ್ಗದ ಮೂಲಕ ನಿರ್ವಹಣೆ. ಪ್ರತಿಯೊಂದೂ ಅದಕ್ಕೆ ಹೊಂದುವ ರಿಜಾಲ್ವರ್ ಜೋಡಣೆಯನ್ನು ಸೂಚಿಸುತ್ತದೆ. ಸಮರ್ಥಿಸಲಾಗದ್ದು ಸುರಂಗ ಬಿದ್ದ ಪ್ರತಿ ಬಾರಿ ಮೌನವಾಗಿ ಅಪರಿಮಿತ ಪರ್ಯಾಯ ಮಾರ್ಗವಾಗುವ ವಿನಾಯಿತಿ.
ಆಯ್ಕೆ ಮಾಡಿದ ನೀತಿಯನ್ನು ಮಾಲೀಕರೊಂದಿಗೆ ಬರೆಯಿರಿ, ಏಕೆಂದರೆ ಮುಂದಿನ ನಿರ್ವಾಹಕರು ನಿಯಮವನ್ನು ಕಂಡುಕೊಳ್ಳುತ್ತಾರೆ, ಅದರ ಹಿಂದಿನ ತರ್ಕವನ್ನಲ್ಲ. ಅನುಮತಿಯನ್ನು ಇರುವ ಫೈರ್‌ವಾಲ್ ಮತ್ತು ನೆಟ್‌ವರ್ಕ್ ಮಾಲೀಕರ ಮೂಲಕ ಅನ್ವಯಿಸಿ, ನಿಯಮಗಳನ್ನು ಖಾಲಿ ಮಾಡುವ ಅಥವಾ ಒಂದು ಹೋಸ್ಟ್‌ಗೆ ಎರಡನೇ ನೀತಿ ಮ್ಯಾನೇಜರ್ ಸೇರಿಸುವ ಬದಲು. ನಿಜವಾದ ಮೂಲ ಬಳಸುವ ವಿಳಾಸ ಕುಟುಂಬಗಳು ಮತ್ತು ಸೇವಾ ಅಂತ್ಯಬಿಂದುಗಳನ್ನು ಒಳಗೊಳ್ಳಿ, ಮತ್ತು ಭಂಡಾರ ಸ್ಥಳಾಂತರಗೊಂಡಾಗ ಪಟ್ಟಿಯನ್ನು ಪರಿಶೀಲಿಸಿ.
ವಿಶ್ವಾಸವನ್ನು ದುರ್ಬಲಗೊಳಿಸದೆ ಪರಿಶೀಲಿಸಿ
ಯಶಸ್ವಿ ಸಾರಿಗೆ ಪರಿಶೀಲನೆಯನ್ನು ಸಡಿಲಿಸುವ ಅನುಮತಿ ಅಲ್ಲ: ಆರ್ಕೈವ್ ದೃಢೀಕರಣ ಮತ್ತು TLS ಸರ್ವರ್ ಗುರುತು ಎರಡು ಪ್ರತ್ಯೇಕ ಪರಿಶೀಲನೆಗಳು, ಮತ್ತು ಅವುಗಳಲ್ಲಿ ಯಾವುದನ್ನಾದರೂ ಆಫ್ ಮಾಡುವುದು ದೋಷವನ್ನು ಮರೆಯಾಗಿಸುತ್ತದೆ ಅದೇ ಸಮಯದಲ್ಲಿ ಹೋಸ್ಟ್ ಏನನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಬದಲಾಯಿಸುತ್ತದೆ. ತಡೆಯುವ ಪ್ರಾಕ್ಸಿ ನೆಟ್‌ವರ್ಕ್ ಮಾಲೀಕರ ವಿಶ್ವಾಸ ನಿರ್ಣಯ, ಪರಿಶೀಲನೆಯನ್ನು ಸ್ಥಳೀಯವಾಗಿ ಆಫ್ ಮಾಡುವ ಕಾರಣವಲ್ಲ, ಮತ್ತು ಭಂಡಾರದ ರುಜುವಾತುಗಳು ಹಂಚಿದ ರೋಗನಿರ್ಣಯದಲ್ಲಿರಬಾರದು, ಏಕೆಂದರೆ ವಿವರವಾದ ಲಾಗ್ ಅವನ್ನು ಸೋರಿಸಲು ಸುಲಭವಾದ ಸ್ಥಳ.
ಬದಲಾವಣೆಯನ್ನು ನಿಯಂತ್ರಿತ ಮೆಟಾಡೇಟಾ ಮರುಪ್ರಾಪ್ತಿ ಮತ್ತು ನಂತರ ಒಂದು ಅನುಮೋದಿತ ಪ್ಯಾಕೇಜ್ ವಹಿವಾಟಿನೊಂದಿಗೆ ಸ್ವೀಕರಿಸಿ, ನಂತರ ಸುರಂಗ ಬಿದ್ದಾಗ ಏನಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ಪರೀಕ್ಷಿಸಿ. ಅಡಚಣೆಯ ಸಮಯದಲ್ಲಿ ಮೌನವಾಗಿ ವಿಸ್ತರಿಸುವ ನಿರ್ವಹಣಾ ಮಾರ್ಗ ಮುಚ್ಚಿ ವಿಫಲವಾಗುವ ಮಾರ್ಗಕ್ಕಿಂತ ಕೆಟ್ಟದು, ಮತ್ತು ಫಲಿತಾಂಶ ಹೆಸರಿಸಿದ ಮಾಲೀಕ ಮತ್ತು ಸೀಮಿತ ವ್ಯಾಪ್ತಿಯ ಅಪ್‌ಡೇಟ್ ಮಾರ್ಗವಾಗಿರಬೇಕು.