MULTI: ಕ್ಲೈಂಟ್ನಿಂದ ತಪ್ಪು ಮೂಲ ವಿಳಾಸ: ಅದು ಯಾರ ವಿಳಾಸ?
ಒಳಗಿನ ಮೂಲವು ಅದನ್ನು ತಲುಪಿಸಿದ ಕ್ಲೈಂಟ್ಗೆ ಹೊಂದಿಕೆಯಾಗುವುದಿಲ್ಲ. ಅದನ್ನು ಟನೆಲ್ ಹಂಚಿಕೆ, ಕ್ಲೈಂಟ್ನ ಹಿಂದಿನ LAN, ಅಥವಾ ನಕಲಿ ಗುರುತಿಗೆ ಹೊಂದಿಸಿ.
ಸರ್ವರ್ ಲಾಗ್ MULTI: bad source address from client ಮುದ್ರಿಸುತ್ತದೆ, ಪ್ಯಾಕೆಟ್ ಬಿಡುತ್ತದೆ, ಮತ್ತು ಸೆಷನ್ ಸಂಪರ್ಕದಲ್ಲೇ ಇರುತ್ತದೆ. ಈ ಸಂಯೋಜನೆ ಸಂದೇಶವನ್ನು ದೃಢೀಕರಣ ವೈಫಲ್ಯ ಎಂದು ಓದುವವರನ್ನು ಗೊಂದಲಕ್ಕೀಡುಮಾಡುತ್ತದೆ. ಹಾಗಲ್ಲ: ಕ್ಲೈಂಟ್ ದೃಢೀಕರಿಸಲ್ಪಟ್ಟಿದೆ, ಮತ್ತು ಬಂದ ಪ್ಯಾಕೆಟ್ ಒಳಗಿನ ಮೂಲ ವಿಳಾಸವನ್ನು ಹೊತ್ತಿತ್ತು, ಅದನ್ನು ಸರ್ವರ್ ಆ ಕ್ಲೈಂಟ್ ಪ್ರತಿಗೆ ಜೋಡಿಸಲಾಗಲಿಲ್ಲ. ಪರಿಶೀಲನೆ ತಲುಪಿಸುವ ಮೊದಲೇ ನಡೆಯುತ್ತದೆ, ಆದ್ದರಿಂದ ಟನೆಲ್ ಆರೋಗ್ಯಕರವಾಗಿ ಕಾಣುತ್ತದೆ, ಆದರೆ ಅದರ ಮೂಲಕ ಉಪಯುಕ್ತವಾದದ್ದು ಏನೂ ಹಾದುಹೋಗುವುದಿಲ್ಲ.
ತಲುಪಿಸುವ ಮೊದಲು ಸರ್ವರ್ ಏನನ್ನು ಹೋಲಿಸುತ್ತದೆ
ಕ್ಲೈಂಟ್ನಿಂದ ಬರುವ ಪ್ರತಿ ಪ್ಯಾಕೆಟ್ಗೂ, ಬಳಕೆದಾರ ಸ್ಥಳದ ಸರ್ವರ್ ಟನೆಲ್ ಒಳಗಿನ ಮೂಲ ವಿಳಾಸವನ್ನು ನೋಡಿ ತನ್ನ ಒಳಗಿನ ಮಾರ್ಗನಿರ್ದೇಶನ ಸ್ಥಿತಿಗೆ ಆ ವಿಳಾಸ ಯಾವ ಕ್ಲೈಂಟ್ನದು ಎಂದು ಕೇಳುತ್ತದೆ. ಮಾಲೀಕರು ಬೇರೆ ಪ್ರತಿಯಾಗಿದ್ದರೆ, ಅಥವಾ ಮಾಲೀಕರೇ ಇಲ್ಲದಿದ್ದರೆ, ಪ್ಯಾಕೆಟ್ ತೆಗೆದುಹಾಕಲ್ಪಡುತ್ತದೆ ಮತ್ತು ಎಚ್ಚರಿಕೆ ಹೊರಡುತ್ತದೆ.
ಟನೆಲ್ ಇಂಟರ್ಫೇಸ್ ಮೂಲಕ ಸಾಮಾನ್ಯ ತಲುಪಿಸುವಿಕೆ ಎಂದಿಗೂ ನಡೆಯುವುದಿಲ್ಲ.
ಈ ಕ್ರಮವು ಜನರನ್ನು ಗೊಂದಲಕ್ಕೀಡುಮಾಡುವ ವಿವರವನ್ನು ವಿವರಿಸುತ್ತದೆ: ಹೋಸ್ಟ್ ಫೈರವಾಲ್ನ ಕೌಂಟರ್ಗಳು ಚಲಿಸುವುದಿಲ್ಲ, ಏಕೆಂದರೆ ಪ್ಯಾಕೆಟ್ ಎಂದಿಗೂ ಫೈರವಾಲ್ ತಲುಪಲಿಲ್ಲ. ಹೋಸ್ಟ್ನಲ್ಲಿ ಹಿಮ್ಮುಖ ಮಾರ್ಗ ಶೋಧನೆಯನ್ನು ಸರಿಹೊಂದಿಸುವುದು ಇಲ್ಲಿ ಏನನ್ನೂ ಬದಲಿಸುವುದಿಲ್ಲ, ಏಕೆಂದರೆ ನಿರಾಕರಣೆ ಡೀಮನ್ನ ಸ್ವಂತ ಜೋಡಣೆ ಪರಿಶೀಲನೆಯಲ್ಲಿ ಸಂಭವಿಸಿದೆ. ಸಂದೇಶವನ್ನು ಮಾಲೀಕತ್ವದ ಬಗ್ಗೆ ಒಂದು ಹೇಳಿಕೆಯಾಗಿ ಓದಿ, ನಂತರ ಮೂರು ಸನ್ನಿವೇಶಗಳಲ್ಲಿ ಯಾವುದು ಅದನ್ನು ಸೃಷ್ಟಿಸಿತು ಎಂದು ಕಂಡುಹಿಡಿಯಿರಿ.
ಹೊಂದಿಕೆಯಾಗದ ಒಳಗಿನ ವಿಳಾಸದ ಮೂರು ಮೂಲಗಳು
ಕ್ಲೈಂಟ್ ತನಗೆ ಹಂಚಿಕೆಯಾಗದ ವಿಳಾಸದಿಂದ, ಯಾರೂ ತನ್ನದು ಎಂದು ಘೋಷಿಸದ ಜಾಲದಿಂದ, ಅಥವಾ ಈಗಾಗಲೇ ಮಾಲೀಕರಿರುವ ಗುರುತಿನ ನಕಲಿನಿಂದ ಕಳುಹಿಸುತ್ತಿರಬಹುದು. ಮೂರೂ ಒಂದೇ ಲಾಗ್ ಸಾಲನ್ನು ಸೃಷ್ಟಿಸುತ್ತವೆ. ಅವು ನೀವು ಏನನ್ನು ಬದಲಿಸಬೇಕು ಎಂಬುದರಲ್ಲಿ ಭಿನ್ನ. ವಿಳಾಸ ಮತ್ತು ಪ್ರಸ್ತುತ ಹಂಚಿಕೆ ಪಟ್ಟಿಯಿಂದ ಪ್ರಾರಂಭಿಸಿ, ಈ ಎರಡು ಸತ್ಯಗಳಿಗೆ ಪ್ರಕರಣವನ್ನು ಆರಿಸಲು ಬಿಡಿ.
ಅವುಗಳನ್ನು ಬೇರ್ಪಡಿಸಲು ಎರಡು ಸತ್ಯಗಳು ಬೇಕು: ಲಾಗ್ನಲ್ಲಿ ನಿರಾಕರಿಸಲ್ಪಟ್ಟ ವಿಳಾಸ, ಮತ್ತು ಸರ್ವರ್ ಪ್ರಸ್ತುತ ಎಂದು ಪರಿಗಣಿಸುವ ಹಂಚಿಕೆಗಳು. ಎರಡನೆಯದು ಚಾಲನೆಯಲ್ಲಿರುವ ಪ್ರತಿಯ ಸ್ಥಿತಿ ಅಥವಾ ನಿರ್ವಹಣೆ ನೋಟದಿಂದ ಲಭ್ಯವಿದೆ, ಮತ್ತು ಸಂಪರ್ಕಿಸಲು ಯೋಗ್ಯವಾದ ಏಕೈಕ ಪ್ರಾಧಿಕಾರ ಅದೇ, ಏಕೆಂದರೆ ಸಂರಚನಾ ಫೈಲ್ ಉದ್ದೇಶಗಳನ್ನು ದಾಖಲಿಸುತ್ತದೆ, ಪ್ರಸ್ತುತ ಸ್ಥಿತಿಯನ್ನಲ್ಲ.
ಏನನ್ನಾದರೂ ಬದಲಿಸುವ ಮೊದಲು ಎರಡನ್ನೂ ದಾಖಲಿಸಿ, ನಂತರ ವರ್ಗೀಕರಿಸಿ. ನಂತರ ತೆಗೆದ ಸ್ಕ್ರೀನ್ಶಾಟ್ ಎಚ್ಚರಿಕೆಯನ್ನು ಸೃಷ್ಟಿಸಿದ ಸ್ಥಿತಿಯ ದಾಖಲೆಯಲ್ಲ. ಸಮಯ ಮುದ್ರೆಯನ್ನೂ ಇರಿಸಿ, ಏಕೆಂದರೆ ಹಂಚಿಕೆಗಳು ಸೆಷನ್ಗಳ ನಡುವೆ ಸರಿಯುತ್ತವೆ.
| Rejected source is | Likely cause |
|---|---|
| The client's own tunnel address | Static assignment conflict, wrong profile, or manual address change |
| A host behind that client | Missing internal ownership for that prefix |
| An address belonging to another session | Two devices sharing one identity or one static address |
ಕ್ಲೈಂಟ್ನ ಹಿಂದಿನ LAN ಮತ್ತು iroute
ಸೈಟ್ ಕ್ಲೈಂಟ್ ತನ್ನದೇ ಖಾಸಗಿ ಜಾಲವನ್ನು ಮಾರ್ಗನಿರ್ದೇಶಿಸಿದಾಗ, ಆ ಜಾಲವನ್ನು ಕ್ಲೈಂಟ್ನದು ಎಂದು ಘೋಷಿಸಬೇಕು. iroute ನಮೂದನ್ನು ಹೊಂದಿರುವ ಕ್ಲೈಂಟ್-ನಿರ್ದಿಷ್ಟ ಫೈಲ್ ಅದನ್ನು ಮಾಡುತ್ತದೆ, ಮತ್ತು ನಮೂದು ಕ್ಲೈಂಟ್ ಸಾಗಿಸಲು ಅನುಮತಿಸಿದ ಪೂರ್ವಪ್ರತ್ಯಯವನ್ನು ಹೆಸರಿಸುತ್ತದೆ.
ಅದೇ ಪೂರ್ವಪ್ರತ್ಯಯವನ್ನು ಟನೆಲ್ಗೆ ತೋರಿಸುವ ಕೆರ್ನೆಲ್ ಮಾರ್ಗವು ಪ್ರತ್ಯೇಕ ಅಗತ್ಯವಾಗಿದೆ, ಮತ್ತು ಅದನ್ನು ಸೇರಿಸುವುದು ಡೀಮನ್ನ ಒಳಗಿನ ಮಾಲೀಕತ್ವದಲ್ಲಿ ಏನನ್ನೂ ಬದಲಿಸುವುದಿಲ್ಲ.
# /etc/openvpn/server/ccd/site-b
iroute 192.168.70.0 255.255.255.0ಪರಿಣಾಮಕಾರಿ ಗುರುತು ಫೈಲ್ ಹೆಸರಿಗೆ ಹೊಂದುತ್ತದೆ ಎಂದು ಖಚಿತಪಡಿಸಿ, ಏಕೆಂದರೆ ಹೊಂದಿಕೆಯಾಗದಿರುವುದು ಫೈಲ್ ಎಂದಿಗೂ ಲೋಡ್ ಆಗುವುದಿಲ್ಲ ಎಂದರ್ಥ ಮತ್ತು ಲಕ್ಷಣವು ಕಾಣೆಯಾದ ನಮೂದಿನಂತೆಯೇ ಇರುತ್ತದೆ. ಎಚ್ಚರಿಕೆಯನ್ನು ಸುಮ್ಮನಾಗಿಸಲು ಅಗಲವಾದ iroute ಸೇರಿಸಬೇಡಿ, ಏಕೆಂದರೆ ಅದು ಅನಿರೀಕ್ಷಿತ ಮೂಲವನ್ನು ಅಧಿಕೃತ ಮೂಲವನ್ನಾಗಿ ಮಾಡುತ್ತದೆ ಮತ್ತು ಕ್ಲೈಂಟ್ ಅದನ್ನು ಏಕೆ ಕಳುಹಿಸಿತು ಎಂಬುದಕ್ಕೆ ಉತ್ತರಿಸುವುದಿಲ್ಲ. OpenVPN 2.6 ಕೈಪಿಡಿ iroute, duplicate-cn ಮತ್ತು ಗುರುತು ನಕ್ಷೆಯನ್ನು ಪ್ರತ್ಯೇಕ ನಿಯಂತ್ರಣಗಳಾಗಿ ದಾಖಲಿಸುತ್ತದೆ.
ಎರಡು ಯಂತ್ರಗಳಲ್ಲಿ ಒಂದೇ ಗುರುತು
ಎರಡನೇ ಲ್ಯಾಪ್ಟಾಪ್ಗೆ ನಕಲಿಸಿದ ಪ್ರೊಫೈಲ್ ಅದೇ ಪ್ರಮಾಣಪತ್ರ ಮತ್ತು ಅದೇ ಸಾಮಾನ್ಯ ಹೆಸರನ್ನು ಹೊತ್ತಿದೆ. ಸರ್ವರ್ ಸೆಟ್ಟಿಂಗ್ಗಳ ಆಧಾರದ ಮೇಲೆ ಹೊಸ ಸಂಪರ್ಕವು ಹಳೆಯದನ್ನು ಬದಲಿಸಬಹುದು, ಮತ್ತು ಮಾಲೀಕತ್ವ ಹೊಂದಿರುವ ಪ್ರತಿ ಜೋಡಣೆ ಪರಿಶೀಲನೆಯನ್ನು ಗೆಲ್ಲುತ್ತದೆ.
ಇದು ದೋಷವನ್ನು ಮಧ್ಯಂತರವಾಗಿ ಕಾಣಿಸುವಂತೆ ಮಾಡುತ್ತದೆ, ಮತ್ತು ಎರಡೂ ಸಾಧನಗಳು ಎಚ್ಚರವಾಗಿರುವಾಗ ಮಾತ್ರ ಅದು ಕಾಣಿಸುತ್ತದೆ.
ನಕಲಿ ಸಾಮಾನ್ಯ ಹೆಸರುಗಳಿಗೆ ಅನುಮತಿ ನೀಡುವುದು ಎರಡೂ ಸಂಪರ್ಕಿಸಲು ಬಿಡುತ್ತದೆ, ಆದರೆ ಅವುಗಳಿಗೆ ಸ್ವತಂತ್ರ ಸ್ಥಿರ ವಿಳಾಸಗಳನ್ನಾಗಲಿ ಸ್ವತಂತ್ರ ಮಾಲೀಕತ್ವವನ್ನಾಗಲಿ ನೀಡುವುದಿಲ್ಲ. ಎರಡು ಸಾಧನಗಳು ಒಟ್ಟಿಗೆ ಇರಬೇಕಾದರೆ, ಪ್ರತಿಯೊಂದಕ್ಕೂ ತನ್ನದೇ ಗುರುತು ಮತ್ತು ತನ್ನದೇ ಹಂಚಿಕೆ ಇರುವಂತೆ ಅವನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ನೋಂದಿಸಿ. ನಕಲಿ ಸೆಟ್ಟಿಂಗ್ ಅನ್ನು ಈ ಎಚ್ಚರಿಕೆಯ ಪರಿಹಾರ ಎಂದು ಪರಿಗಣಿಸುವುದು ಒಗಟನ್ನು ಅಲ್ಲಿಯೇ ಬಿಡುತ್ತದೆ ಮತ್ತು ಇನ್ನೊಂದನ್ನು ಸೇರಿಸುತ್ತದೆ.
ಜೋಡಣೆ ಬದಲಾಗಿದೆ ಎಂದು ಸಾಬೀತುಪಡಿಸಿ
ಸಂರಚನೆಯ ಮಾಲೀಕರ ಮೂಲಕ ಸರಿಪಡಿಸುವಿಕೆಯನ್ನು ಅನ್ವಯಿಸಿ, ನಂತರ ಹೊಸ ನೀತಿ ಲೋಡ್ ಆಗಲು ಪೀಡಿತ ಕ್ಲೈಂಟ್ ಅನ್ನು ಮತ್ತೆ ಸಂಪರ್ಕಿಸಿ.
ಅದೇ ಹರಿವನ್ನು ಪುನರಾವರ್ತಿಸಿ ಮತ್ತು ಮೂರು ವಿಷಯಗಳನ್ನು ಖಚಿತಪಡಿಸಿ: ಪ್ಯಾಕೆಟ್ನ ಒಳಗಿನ ಮೂಲ, ಸರ್ವರ್ ಅದನ್ನು ಜೋಡಿಸುವ ಕ್ಲೈಂಟ್ ಪ್ರತಿ, ಮತ್ತು ನಂತರ ಗಮ್ಯಸ್ಥಾನದ ವರ್ತನೆ.
ಎಚ್ಚರಿಕೆ ನಿಂತರೂ ಅಪ್ಲಿಕೇಶನ್ ಇನ್ನೂ ವಿಫಲವಾದರೆ, ಸಮಸ್ಯೆ ಮಾಯವಾಗಿಲ್ಲ, ಸ್ಥಳಾಂತರಗೊಂಡಿದೆ. ಮುಂದಕ್ಕೆ ರವಾನೆ, ಫೈರವಾಲ್ ನಿಯಮಗಳು ಮತ್ತು ಹಿಂತಿರುಗುವ ಮಾರ್ಗ ಪ್ರತ್ಯೇಕ ಹಂತಗಳು, ಮತ್ತು ಜೋಡಣೆ ಪರಿಶೀಲನೆ ದಾಟುವುದು ಎಂದರೆ ಪ್ಯಾಕೆಟ್ಗೆ ಟನೆಲ್ ಬಿಡಲು ಅನುಮತಿ ಸಿಕ್ಕಿದೆ ಎಂದಷ್ಟೇ.