Linux VPN ನ ಪ್ರತ್ಯುತ್ತರಗಳು ಕಾಣೆಯಾಗುತ್ತಿವೆಯೇ? rp_filter ಮತ್ತು ಮಾರ್ಗವನ್ನು ಪರಿಶೀಲಿಸಿ

ವಿನಂತಿಗಳು ಯಂತ್ರವನ್ನು ಬಿಡುತ್ತವೆ, VPN ಸಹವರ್ತಿ ಉತ್ತರಿಸುತ್ತದೆ, ಮತ್ತು ಉತ್ತರ ಎಂದಿಗೂ ಸಾಕೆಟ್ ತಲುಪುವುದಿಲ್ಲ. ಸುರಂಗ ಸಕ್ರಿಯವಾಗಿದೆ, ಸಹವರ್ತಿಯ ಲಾಗ್‌ಗಳು ಪ್ಯಾಕೆಟ್ ಕಳುಹಿಸಿದ್ದನ್ನು ತೋರಿಸುತ್ತವೆ, ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್‌ನಲ್ಲಿ ಈ ಮೌನವನ್ನು ವಿವರಿಸುವ ಯಾವುದೂ ಇಲ್ಲ. Linux ನಲ್ಲಿ ಸಾಮಾನ್ಯ ಸಂದೇಹಿತರಲ್ಲಿ ಒಂದು ಹಿಮ್ಮುಖ ಮಾರ್ಗದ ಶೋಧನೆ: ಒಳಬರುವ IPv4 ಪ್ಯಾಕೆಟ್‌ ಅನ್ನು ತಿರಸ್ಕರಿಸಬಹುದು, ಮೂಲ ಮೌಲ್ಯೀಕರಣವು ಕರ್ನಲ್ ಆ ಮೂಲಕ್ಕೆ ನಿರೀಕ್ಷಿಸುವ ಮಾರ್ಗಕ್ಕೆ ಹೊಂದದಿದ್ದಾಗ. ಅದನ್ನು ಕ್ರಮವಾಗಿ ಅನುಸರಿಸುವುದು ಇದು ಕಾರಣವೋ ಅಕಸ್ಮಾತ್ತೋ ಎಂದು ಹೇಳುತ್ತದೆ. ಕಾಣೆಯಾದ ಮಾರ್ಗವನ್ನು ಸರಿಪಡಿಸಲು ಭದ್ರತಾ ನಿಯಂತ್ರಣವನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸದಂತೆಯೂ ಅದು ತಡೆಯುತ್ತದೆ.

ಮೂಲ ಮೌಲ್ಯೀಕರಣ ಏನನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ

ಕರ್ನಲ್ ಪ್ಯಾಕೆಟ್‌ನ ಮೂಲ ವಿಳಾಸವು ಅದು ಬಂದ ಇಂಟರ್ಫೇಸ್‌ಗೆ ಸಮಂಜಸವೇ ಎಂದು ಪರಿಶೀಲಿಸುತ್ತದೆ, ಆ ಮೂಲಕ್ಕೆ ಹಿಂತಿರುಗುವ ಮಾರ್ಗಕ್ಕಾಗಿ ರೂಟಿಂಗ್ ಕೋಷ್ಟಕವನ್ನು ನೋಡುತ್ತದೆ. ಹಿಮ್ಮುಖ ಮಾರ್ಗ ಬೇರೆಡೆಗೆ ತೋರಿಸಿದರೆ, ಯಾವುದೇ ಫೈರ್ವಾಲ್ ನಿಯಮ ಅಥವಾ ಅಪ್ಲಿಕೇಶನ್ ಸಾಕೆಟ್ ಅದನ್ನು ನೋಡುವ ಮೊದಲೇ ಪ್ಯಾಕೆಟ್ ಬಿಡಬಹುದು. ಈ ಪರಿಶೀಲನೆ ಕೆಲವು ಸ್ಪೂಫಿಂಗ್ ಮಾದರಿಗಳನ್ನು ಕಷ್ಟಕರಗೊಳಿಸಲು ಇದೆ, ಮತ್ತು ಅದೇ ಕಾರಣಕ್ಕೆ ಅಸಮ್ಮಿತ ಮತ್ತು ನೀತಿ-ಮಾರ್ಗಿತ ವಿನ್ಯಾಸಗಳು ಅದಕ್ಕೆ ಸಿಕ್ಕಿಹಾಕಿಕೊಳ್ಳುತ್ತವೆ, ಅದೇ ಜಾಲದಲ್ಲಿನ ಪ್ರತಿ ಸಾಮಾನ್ಯ ಕ್ಲೈಂಟ್ ಚೆನ್ನಾಗಿ ಕೆಲಸ ಮಾಡುತ್ತದೆ. ಸಾಮಾನ್ಯ ಕ್ಲೈಂಟ್‌ಗಳಿಗೆ ಸಮ್ಮಿತೀಯ ರೂಟಿಂಗ್ ಇರುತ್ತದೆ, ಮತ್ತು ಪರಿಶೀಲನೆ ಊಹಿಸುವುದು ಅದನ್ನೇ.

ಮುಖ್ಯ ಪದ ಸಮಂಜಸ. ಪ್ಯಾಕೆಟ್ ಸಂಪೂರ್ಣ ಕಾನೂನುಬದ್ಧವಾಗಿದ್ದರೂ ಪರಿಶೀಲನೆಯಲ್ಲಿ ವಿಫಲವಾಗಬಹುದು, ಏಕೆಂದರೆ ಪರೀಕ್ಷಿಸುವುದು ಕಾನೂನುಬದ್ಧತೆಯಲ್ಲ.

ಪರಿಣಾಮಕಾರಿ ಮೋಡ್ ಓದಿ, ಒಂದು ಕ್ಷೇತ್ರವಲ್ಲ

ಮೂರು ಮೋಡ್‌ಗಳಿವೆ: ನಿಷ್ಕ್ರಿಯ, ಕಟ್ಟುನಿಟ್ಟಿನ ಮತ್ತು ಸಡಿಲ. ಕಟ್ಟುನಿಟ್ಟಿನವು ಸಡಿಲಕ್ಕಿಂತ ಬೇರೆ ಮಾರ್ಗದ ನಿರೀಕ್ಷೆಯನ್ನು ಹೇರುತ್ತದೆ, ಮತ್ತು ಜಾಗತಿಕ ಸೆಟ್ಟಿಂಗ್ ಪ್ರತಿ-ಇಂಟರ್ಫೇಸ್ ಸೆಟ್ಟಿಂಗ್‌ಗಳೊಂದಿಗೆ ಸಂವಹನ ಮಾಡುತ್ತದೆ, ಆದ್ದರಿಂದ ಒಂದು ಫೈಲ್ ಓದುವುದು ವಾಸ್ತವವಾಗಿ ಜಾರಿಯಲ್ಲಿರುವದನ್ನು ತಪ್ಪಾಗಿ ವಿವರಿಸಬಹುದು. ಎರಡನ್ನೂ ಓದಿ, ಮತ್ತು ಉತ್ತರವನ್ನು ಸ್ವೀಕರಿಸುವ ಇಂಟರ್ಫೇಸ್‌ನಲ್ಲಿ ಓದಿ, ಡೀಫಾಲ್ಟ್ ಮಾರ್ಗದ ಇಂಟರ್ಫೇಸ್‌ನಲ್ಲಿ ಅಲ್ಲ.

sysctl net.ipv4.conf.all.rp_filter
sysctl net.ipv4.conf.<iface>.rp_filter
ip route get <source-of-the-reply>

ಮೂರನೇ ಸಾಲಿನಲ್ಲಿನ ಮಾರ್ಗ ಹುಡುಕಾಟವೇ ಜನರು ಬಿಟ್ಟುಬಿಡುವ ಭಾಗ. ಕರ್ನಲ್ ಮೂಲದ ಬಗ್ಗೆ ಏನು ನಂಬುತ್ತದೆ ಎಂದು ಅದು ಹೇಳುತ್ತದೆ, ಮತ್ತು ಅದೇ ಪರಿಶೀಲನೆಯ ಇನ್‌ಪುಟ್.

ಪರಿಶೀಲನೆ ಬದಲಿಸುವ ಮೊದಲು ಅಸಾಮರಸ್ಯ ಕಂಡುಹಿಡಿಯಿರಿ

ಉತ್ತರ ಆ ಇಂಟರ್ಫೇಸ್‌ಗೆ ಏಕೆ ಬರುತ್ತದೆ ಮತ್ತು ಅದರ ಹಿಮ್ಮುಖ ಮಾರ್ಗ ಭಿನ್ನವಾಗಿರಬೇಕೆ ಎಂದು ಕಂಡುಹಿಡಿಯಿರಿ. ವಿನಂತಿಗಳನ್ನು ಒಂದು ಮಾರ್ಗದಲ್ಲಿ ಕಳುಹಿಸಿ ಉತ್ತರಗಳನ್ನು ಇನ್ನೊಂದರಲ್ಲಿ ಹಿಂತಿರುಗಿಸುವ ನೀತಿ ನಿಯಮ ಕಾನೂನುಬದ್ಧ ವಿನ್ಯಾಸ, ಮತ್ತು ಕಟ್ಟುನಿಟ್ಟಿನ ಮೌಲ್ಯೀಕರಣ ತಿರಸ್ಕರಿಸುವುದು ಅದೇ ವಿನ್ಯಾಸವನ್ನು. ನೀತಿ-ಮಾರ್ಗದಲ್ಲಿ ಬಳಸುವ ಗುರುತುಗಳು ಇಲ್ಲಿಯೂ ಮುಖ್ಯವಾಗಬಹುದು, ಏಕೆಂದರೆ ಹಿಮ್ಮುಖ ಹುಡುಕಾಟ ಏನು ಹಿಂತಿರುಗಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಅವು ಬದಲಿಸುತ್ತವೆ.

ಹಿಮ್ಮುಖ ಮಾರ್ಗ ಸುಮ್ಮನೆ ಕಾಣೆಯಾಗಿದ್ದರೆ, ಅದನ್ನು ಸೇರಿಸುವುದು ಪರಿಶೀಲನೆಯನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸುವ ಬದಲು ಕಾರಣವನ್ನು ಸರಿಪಡಿಸುತ್ತದೆ. ಕಾಣೆಯಾದ ಮಾರ್ಗ, ಫೈರ್ವಾಲ್ ನಿರಾಕರಣೆ ಮತ್ತು ತಪ್ಪಾದ ಸಂಚಾರ ಆಯ್ಕೆಗಾರ ಎಲ್ಲವೂ ಒಂದೇ ಕಾಣುವ ಲಕ್ಷಣವನ್ನು ಉತ್ಪಾದಿಸುತ್ತವೆ, ಮತ್ತು ಅವುಗಳಲ್ಲಿ ಒಂದೇ ಮೂಲ ಮೌಲ್ಯೀಕರಣಕ್ಕೆ ಸಂಬಂಧಿಸಿದೆ.

ಮೊದಲ ಪ್ರತಿಕ್ರಿಯೆಯಾಗಿ ಮೂಲ ಪರಿಶೀಲನೆಗಳನ್ನು ಜಾಗತಿಕವಾಗಿ ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಬೇಡಿ. ಅದು ನಿರ್ದಿಷ್ಟ ರೋಗನಿರ್ಣಯವನ್ನು ನಂತರ ನೆನಪಿಟ್ಟುಕೊಳ್ಳಬೇಕಾದ ವಿಶಾಲ ವರ್ತನೆ ಬದಲಾವಣೆಗೆ ಬದಲಾಯಿಸುತ್ತದೆ.

ನೀವು ಸಮರ್ಥಿಸಬಹುದಾದ ಆಯ್ದ ಹೊಂದಾಣಿಕೆ

ಕಿರಿದಾದ ಹೊಂದಾಣಿಕೆ ನಿಜವಾಗಿಯೂ ಬೇಕಿದ್ದರೆ, ಅದನ್ನು ಅಗತ್ಯವಿರುವ ಇಂಟರ್ಫೇಸ್‌ಗೆ ಸೀಮಿತಗೊಳಿಸಿ, ಏಕೆ ಎಂದು ಬರೆಯಿರಿ, ಮತ್ತು ಮರುಬೂಟ್ ನಂತರವೂ ಉಳಿಯಲು ಆ ಇಂಟರ್ಫೇಸ್ ಹೊಂದಿರುವ ಸಂರಚನೆಯಲ್ಲಿ ಇರಿಸಿ. ನಂತರ ವಿಫಲವಾದ ನಿಖರವಾದ ಹರಿವನ್ನು ಅದೇ ಮೂಲದಿಂದ ಅದೇ ಗಮ್ಯಕ್ಕೆ ಮತ್ತೆ ಪರೀಕ್ಷಿಸಿ, ಅನುಕೂಲಕರ ಯಾವುದಕ್ಕೋ ping ಮಾಡುವ ಬದಲು.

ಇನ್ನೂ ನಿರಾಕರಿಸಬೇಕಾದ ಪ್ರಕರಣವನ್ನು ಸೇರಿಸಿ. ಆ ಪ್ರಕರಣ ಈಗ ಯಶಸ್ವಿಯಾದರೆ, ಹೊಂದಾಣಿಕೆ ನೀವು ಸರಿಪಡಿಸಲು ಬಯಸಿದ ಒಂದು ಮಾರ್ಗಕ್ಕಿಂತ ಹೆಚ್ಚನ್ನು ದುರ್ಬಲಗೊಳಿಸಿದೆ.

IPv4 ಮತ್ತು IPv6 ಅನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿರಿಸಿ

ಪರಿಚಿತವಾಗಿ ಕಾಣುವ sysctl ಪ್ರತಿ ವಿಳಾಸ ಕುಟುಂಬಕ್ಕೂ ನೀತಿಯಲ್ಲ. IPv6 ತನ್ನದೇ ವರ್ತನೆ ಮತ್ತು ತನ್ನದೇ ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ಹೊಂದಿದೆ, ಮತ್ತು ಒಂದು ಯಂತ್ರ ಒಂದು ಕುಟುಂಬದಲ್ಲಿ ಕಟ್ಟುನಿಟ್ಟಾಗಿ, ಇನ್ನೊಂದರಲ್ಲಿ ಸಡಿಲವಾಗಿರಬಹುದು, ನಿರ್ದಿಷ್ಟ ಗಮ್ಯ ವಿಫಲವಾಗುವವರೆಗೆ ಯಾರೂ ಗಮನಿಸುವುದಿಲ್ಲ. ಕೆಲಸದ ಹೊರೆ ಎರಡನ್ನೂ ಬಳಸಿದರೆ ಎರಡನ್ನೂ ಪರಿಶೀಲಿಸಿ.

ಮೋಡ್, ಇಂಟರ್ಫೇಸ್, ಮಾರ್ಗ ಹುಡುಕಾಟದ ಔಟ್‌ಪುಟ್ ಮತ್ತು ಬದಲಾವಣೆಯ ಕಾರಣವನ್ನು ಒಂದೇ ಸ್ಥಳದಲ್ಲಿ ದಾಖಲಿಸಿ. ಮುಂದಿನ ವ್ಯಕ್ತಿ ಸೆಟ್ಟಿಂಗ್ ಸಿಗುತ್ತದೆ ಮತ್ತು ಯಾವುದೇ ವಿವರಣೆ ಸಿಗುವುದಿಲ್ಲ, ಮತ್ತು ಅದನ್ನು ತೆಗೆದುಹಾಕುತ್ತಾರೆ ಅಥವಾ ಅದು ಇರಬಾರದ ಸ್ಥಳಕ್ಕೆ ನಕಲಿಸುತ್ತಾರೆ.