Linux ನಲ್ಲಿ VPN ಒತ್ತಿದ ಮಾರ್ಗಗಳನ್ನು ಸ್ಥಿರ ಮಾರ್ಗಗಳಿಂದ ಹೇಗೆ ಪ್ರತ್ಯೇಕಿಸುವುದು
ಟನೆಲ್ ಜೊತೆಗೆ ಕಾಣುವ ಪ್ರಿಫಿಕ್ಸ್ ಮೂರು ಮಾಲೀಕರಿಂದ ಬರಬಹುದು. ಕೋಷ್ಟಕವನ್ನು ಹೋಲಿಸಿ, ಮೆಟ್ರಿಕ್ ಪರಿಶೀಲಿಸಿ, ನಂತರ ಅದನ್ನು ಮತ್ತೆ ಮತ್ತೆ ಸ್ಥಾಪಿಸುವ ಮಾಲೀಕರನ್ನು ಸರಿಪಡಿಸಿ.
ಟನೆಲ್ ಮೇಲೆ ಬಂದಾಗ ಲ್ಯಾಪ್ಟಾಪ್‌ನಲ್ಲಿ ಪ್ರಿಫಿಕ್ಸ್ ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತದೆ, ಹಾಗಾಗಿ VPN ಅದನ್ನು ಸ್ಥಾಪಿಸಿದಂತೆ ಅನಿಸುತ್ತದೆ. ಹಾಗಿರಬಹುದು, ಆದರೆ ಅದೇ ಫಲಿತಾಂಶ ಸಂಪರ್ಕದ ಸಮಯದಲ್ಲಿ ಚಲಿಸುವ ಕ್ಲೈಂಟ್ ಸ್ಕ್ರಿಪ್ಟ್‌ನಿಂದ, ಸಬ್‌ನೆಟ್ ಪಟ್ಟಿ ಮಾಡುವ ಸಂಪರ್ಕ ಪ್ರೊಫೈಲ್‌ನಿಂದ, ಅಥವಾ ಮೊದಲಿನಿಂದಲೂ ಇದ್ದು ಇಂಟರ್‌ಫೇಸ್ ಇದ್ದಾಗ ಮಾತ್ರ ಕೆಲಸ ಮಾಡಲು ಪ್ರಾರಂಭಿಸಿದ ಸ್ಥಿರ ಮಾರ್ಗದಿಂದಲೂ ಬರಬಹುದು. ತಪ್ಪು ಮಾಲೀಕರನ್ನು ಆರಿಸುವುದು ಎಂದರೆ ಪ್ರತಿ ಸ್ವಚ್ಛಗೊಳಿಸುವಿಕೆಯ ನಂತರ ಮಾರ್ಗ ಮತ್ತೆ ಬರುತ್ತದೆ, ಮತ್ತು ಮುಂದಿನ ವ್ಯಕ್ತಿ ಅದೇ ಸರಿಪಡಿಸುವಿಕೆಯನ್ನು ಪುನರಾವರ್ತಿಸುತ್ತಾನೆ. ಕೆಳಗಿನ ಕ್ರಮವು ಏನನ್ನೂ ಬದಲಿಸುವ ಮೊದಲು ಈ ಮೂರನ್ನು ಬೇರ್ಪಡಿಸುತ್ತದೆ.
ಹಂತ 1: ಪ್ರಿಫಿಕ್ಸ್‌ಗಳನ್ನು ಸ್ಥಾಪಿಸುವ ಕಾರ್ಯವಿಧಾನಕ್ಕೆ ಹೆಸರಿಸಿ
ವಿವಿಧ ಪ್ರೋಟೋಕಾಲ್‌ಗಳು ತಲುಪುವಿಕೆಯನ್ನು ವಿವಿಧ ರೀತಿಯಲ್ಲಿ ಒದಗಿಸುತ್ತವೆ, ಮತ್ತು ಇದೆಲ್ಲವನ್ನೂ ಜಾಹೀರಾತು ಎಂದು ಕರೆಯುವುದು ವ್ಯತ್ಯಾಸವನ್ನು ಮುಚ್ಚುತ್ತದೆ. OpenVPN ಸರ್ವರ್ ನಿಯಂತ್ರಣ ಚಾನಲ್ ಮೂಲಕ ಮಾರ್ಗ ಸೂಚನೆಯನ್ನು ಒತ್ತುತ್ತದೆ ಮತ್ತು pull ಫಿಲ್ಟರ್ ತಡೆಯದಿದ್ದರೆ ಕ್ಲೈಂಟ್ ಅದನ್ನು ಸ್ಥಾಪಿಸುತ್ತದೆ. WireGuard ಸಂರಚನೆ ಅನುಮತಿಸಿದ ಪ್ರಿಫಿಕ್ಸ್‌ಗಳನ್ನು ಸ್ಥಳೀಯವಾಗಿ ಪಟ್ಟಿ ಮಾಡುತ್ತದೆ, ಅವನ್ನು ಕ್ಲೈಂಟ್ ಕ್ರಿಪ್ಟೋ-ಕೀ ರೂಟಿಂಗ್ ಮತ್ತು ತಾನು ಸೇರಿಸುವ ಮಾರ್ಗಗಳಿಗೂ ಬಳಸುತ್ತದೆ. IPsec ಟನೆಲ್ ಸಹವರ್ತಿಯೊಂದಿಗೆ ಸಂಚಾರ ಆಯ್ಕೆದಾರರನ್ನು ಒಪ್ಪುತ್ತದೆ, ಮತ್ತು ಕರ್ನಲ್ ಆ ಆಯ್ಕೆದಾರರಿಂದ ಮಾರ್ಗಗಳನ್ನು ಸ್ಥಾಪಿಸುತ್ತದೆ.
ಯಾವುದೇ ಕೋಷ್ಟಕ ಓದುವ ಮೊದಲು ನಿಮ್ಮ ಟನೆಲ್ ಇವುಗಳಲ್ಲಿ ಯಾವುದನ್ನು ಬಳಸುತ್ತದೆ ಎಂದು ಗುರುತಿಸಿ. ಸಂಪರ್ಕದ ಸಮಯದಲ್ಲಿ ಒತ್ತಿದ ಮಾರ್ಗವು ರೂಟಿಂಗ್ ಪ್ರೋಟೋಕಾಲ್‌ನ ಘೋಷಣೆ ಅಲ್ಲ, ಮತ್ತು ಪ್ರಿಫಿಕ್ಸ್ ದೂರದ ತುದಿಯ ಹಿಂದೆ ತಲುಪಬಹುದು ಎಂದು ಭರವಸೆ ನೀಡುವುದಿಲ್ಲ. ಸರಿಪಡಿಸುವಿಕೆ ಎಲ್ಲಿ ಸೇರುತ್ತದೆ ಎಂಬುದನ್ನು ಅದು ನಿರ್ಧರಿಸುವುದರಿಂದ, ಪ್ರಿಫಿಕ್ಸ್‌ನ ಪಕ್ಕದಲ್ಲಿ ಕಾರ್ಯವಿಧಾನವನ್ನು ಬರೆಯಿರಿ.
ಹಂತ 2: ಒಂದು ಸಂಪರ್ಕದ ಉದ್ದಕ್ಕೂ ಕೋಷ್ಟಕವನ್ನು ಹೋಲಿಸಿ
ಟನೆಲ್ ಕೆಳಗಿರುವಾಗ ಮುಖ್ಯ ಕೋಷ್ಟಕವನ್ನು ಉಳಿಸಿ, ಅದನ್ನು ಮೇಲೆ ತನ್ನಿ, ಮತ್ತೆ ಉಳಿಸಿ ಮತ್ತು ಎರಡು ಸೆರೆಹಿಡಿಯುವಿಕೆಗಳನ್ನು ಹೋಲಿಸಿ. ಕಾಣಿಸಿಕೊಂಡ ಎಲ್ಲವೂ ಸಂಪರ್ಕದ ಜೀವನಚಕ್ರಕ್ಕೆ ಸೇರಿದೆ, ಮತ್ತು ಉಳಿದ ಎಲ್ಲವೂ ಸ್ಥಳೀಯ ಸಂರಚನೆಗೆ ಸೇರಿದೆ.
ip route show table main > /tmp/route-down.txt ನಿಂದ ಅದನ್ನು ಸೆರೆಹಿಡಿಯಿರಿ, ಸಂಪರ್ಕಿಸಿ ಮತ್ತು ಮತ್ತೆ ಸೆರೆಹಿಡಿಯಿರಿ. ಸೈಟ್ IPv6 ಬಳಸಿದರೆ ip -6 route ಗೂ ಅದೇ ಮಾಡಿ, ಏಕೆಂದರೆ ಅಲ್ಲಿ ಕಾಣೆಯಾದ ಪ್ರಿಫಿಕ್ಸ್ ರೂಟಿಂಗ್‌ಗೆ ಸಂಬಂಧವಿಲ್ಲದಂತೆ ಕಾಣುವ ವೈಫಲ್ಯಗಳನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ.
ಹಂತ 3: ಕೇವಲ ಇರುವಿಕೆಯಲ್ಲ, ಮೆಟ್ರಿಕ್ ಓದಿ
ಒಂದೇ ಪ್ರಿಫಿಕ್ಸ್‌ಗೆ ಎರಡು ನಮೂದುಗಳು ಜೊತೆಯಾಗಿ ಇರಬಹುದು, ಮತ್ತು ಕರ್ನಲ್ ಕಡಿಮೆ ಮೆಟ್ರಿಕ್ ಆಯ್ಕೆ ಮಾಡುತ್ತದೆ. ಮೆಟ್ರಿಕ್ 50 ಇರುವ ಸ್ಥಿರ ಮಾರ್ಗ ಎರಡೂ ಕಾಣುತ್ತಿದ್ದರೂ 100 ರಲ್ಲಿ ಒತ್ತಿದ ಮಾರ್ಗವನ್ನು ಸೋಲಿಸುತ್ತಲೇ ಇರುತ್ತದೆ, ಆದ್ದರಿಂದ ‘ಮಾರ್ಗ ಅಲ್ಲಿದೆ’ ಮತ್ತು ‘ಸಂಚಾರ ಅದನ್ನು ಬಳಸುತ್ತದೆ’ ಬೇರೆ ಬೇರೆ ಹೇಳಿಕೆಗಳು.
ip route get 10.20.5.7 ನಿಂದ ನೇರವಾಗಿ ಕರ್ನಲ್‌ಗೆ ಕೇಳಿ ಮತ್ತು ಅದು ವರದಿ ಮಾಡುವ ಇಂಟರ್‌ಫೇಸ್ ಓದಿ. ಕೋಷ್ಟಕದಲ್ಲಿ ಟನೆಲ್ ಮಾರ್ಗ ಇದ್ದರೂ ಸಂಚಾರ ಭೌತಿಕ ಅಡಾಪ್ಟರ್ ಮೂಲಕ ಹೊರಟರೆ, ಅದನ್ನು ಮೆಟ್ರಿಕ್ ಅಥವಾ ಪ್ರಿಫಿಕ್ಸ್ ಉದ್ದ ವಿವರಿಸುತ್ತದೆ, VPN ಕ್ಲೈಂಟ್ ಅಲ್ಲ. ಟನೆಲ್ ಹಿಂದೆ ಇದೆ ಎಂದು ನಿಮಗೆ ತಿಳಿದಿರುವ ಹೋಸ್ಟ್ ಮತ್ತು ಇಲ್ಲ ಎಂದು ತಿಳಿದಿರುವ ಹೋಸ್ಟ್‌ಗೆ ಹುಡುಕಾಟವನ್ನು ಪುನರಾವರ್ತಿಸಿ, ಮತ್ತು ವ್ಯತ್ಯಾಸವು ವಿಭಜನೆ ಉದ್ದೇಶದಂತೆ ವರ್ತಿಸುತ್ತದೆಯೇ ಎಂದು ತೋರಿಸುತ್ತದೆ.
ಹಂತ 4: ಟನೆಲ್‌ಗಿಂತ ಹೆಚ್ಚು ಬದುಕುವ ನಮೂದುಗಳನ್ನು ಹುಡುಕಿ
ಸ್ಥಿರ ಮಾರ್ಗಗಳು ವಿನ್ಯಾಸದ ಪ್ರಕಾರ ಸಂಪರ್ಕ ಕಡಿತವನ್ನು ಬದುಕುತ್ತವೆ, ಮತ್ತು ಹಳೆಯ ನಮೂದುಗಳು ಅಲ್ಲಿಂದಲೇ ಬರುತ್ತವೆ. ಇನ್ನು ಇಲ್ಲದ ಇಂಟರ್‌ಫೇಸ್‌ಗೆ ತೋರಿಸುವ ನಿರಂತರ ಮಾರ್ಗವು ಸಬ್‌ನೆಟ್ ಅನ್ನು ಸದ್ದಿಲ್ಲದೆ ನುಂಗಬಹುದು, ಮತ್ತು ಮರುಬಳಕೆಯಾದ ಇಂಟರ್‌ಫೇಸ್ ಹೆಸರಿಗೆ ತೋರಿಸುವ ಮಾರ್ಗವು ಮರುಪ್ರಾರಂಭದ ನಂತರ ಖಾಸಗಿ ಸಂಚಾರವನ್ನು ತಪ್ಪು ಬಾಗಿಲಿನಿಂದ ಕಳುಹಿಸಬಹುದು.
ನಿಮ್ಮ ವಿತರಣೆ ಬಳಸುವ ಸ್ಥಳದಲ್ಲಿ ನಿರಂತರ ಭಾಗವನ್ನು ಪರಿಶೀಲಿಸಿ, ಅದು systemd-networkd ಘಟಕ, NetworkManager ಪ್ರೊಫೈಲ್ ಅಥವಾ ಕ್ಲೈಂಟ್‌ನ up ಕೋಶದಲ್ಲಿನ ಸ್ಕ್ರಿಪ್ಟ್ ಆಗಿರಬಹುದು. ip route del ನಿಂದ ಜೀವಂತ ಕೋಷ್ಟಕವನ್ನು ಸರಿಪಡಿಸುವುದು ಮುಂದಿನ ಸಂಪರ್ಕದವರೆಗೆ ಮಾತ್ರ ನಿಲ್ಲುತ್ತದೆ. ಆ ಅಳಿಸುವಿಕೆಯನ್ನು ದುರಸ್ತಿ ಎಂದಲ್ಲ, ಕಲ್ಪನೆಯ ಪರೀಕ್ಷೆ ಎಂದು ಪರಿಗಣಿಸಿ.
ದೂರದ ತುದಿ ತಪ್ಪು ಕವರೇಜ್ ನೀಡುವಲ್ಲಿ, ಎಲ್ಲವನ್ನೂ ಫಿಲ್ಟರ್ ಮಾಡುವ ಬದಲು ನಿರ್ವಾಹಕರಿಗೆ ತಿಳಿಸಿ. ಎಲ್ಲಾ ಒತ್ತಿದ ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ಬಿಟ್ಟುಬಿಡುವುದು ಪ್ರೊಫೈಲ್ ಅವಲಂಬಿಸಿರುವ DNS ಮತ್ತು ವಿಭಜಿತ ಟನೆಲ್ ನೀತಿಯನ್ನೂ ಬಿಟ್ಟುಬಿಡುತ್ತದೆ.
ಹಂತ 5: ಕ್ಲೈಂಟ್ ಅನ್ನು ದೂಷಿಸುವ ಮೊದಲು ಹಿಂತಿರುಗುವ ಮಾರ್ಗವನ್ನು ದೃಢೀಕರಿಸಿ
ಸೈಟ್-ಟು-ಸೈಟ್ ಅಥವಾ ಟನೆಲ್ ಹಿಂದಿನ ಸಬ್‌ನೆಟ್‌ಗೆ ದೂರದ ಬದಿಗೆ ನಿಮ್ಮ ಕ್ಲೈಂಟ್ ವಿಳಾಸಕ್ಕೆ ಹಿಂತಿರುಗುವ ಮಾರ್ಗ ಮತ್ತು ಗೇಟ್‌ವೇಯಲ್ಲಿ ಫಾರ್ವರ್ಡಿಂಗ್ ಆನ್ ಇರಬೇಕು. ಏಕಮುಖ ಮಾರ್ಗವು ಕ್ಲೈಂಟ್ ರೂಟಿಂಗ್ ದೋಷದಂತೆಯೇ ಕಾಣುತ್ತದೆ, ಆದರೆ ಹ್ಯಾಂಡ್‌ಶೇಕ್ ಮತ್ತು ಹೊರಹೋಗುವ ಪ್ಯಾಕೆಟ್ ಎರಡೂ ಯಶಸ್ವಿಯಾಗುತ್ತವೆ.
ರಿವರ್ಸ್-ಪಾತ್ ಫಿಲ್ಟರಿಂಗ್ Linux ಗೇಟ್‌ವೇಗಳಿಗೆ ಎರಡನೇ ಬಲೆ ಸೇರಿಸುತ್ತದೆ. ಮಾರ್ಗ ನಿರೀಕ್ಷಿಸುವುದಕ್ಕಿಂತ ಬೇರೆ ಇಂಟರ್‌ಫೇಸ್‌ನಲ್ಲಿ ಬರುವ ಉತ್ತರವನ್ನು ಕಟ್ಟುನಿಟ್ಟಿನ ಮೋಡ್‌ನಲ್ಲಿ ಬಿಟ್ಟುಬಿಡಲಾಗುತ್ತದೆ, ಮತ್ತು ಎರಡು ಪೂರೈಕೆದಾರರ ಮೂಲಕ ಅಸಮಮಿತ ಮಾರ್ಗಗಳು ಅದನ್ನು ನಂಬಲರ್ಹವಾಗಿ ಪ್ರಚೋದಿಸುತ್ತವೆ. ಫಿಲ್ಟರಿಂಗ್ ಕಾರಣವೇ ಎಂದು ಗೇಟ್‌ವೇಯಲ್ಲಿನ, ಕ್ಲೈಂಟ್‌ನಲ್ಲಿನ ಅಲ್ಲದ, ಡ್ರಾಪ್ ಕೌಂಟರ್‌ಗಳು ಹೇಳುತ್ತವೆ.
ಹಂತ 6: ping ಅಲ್ಲ, ಸಂಪನ್ಮೂಲವನ್ನು ಪರೀಕ್ಷಿಸಿ
ಆಯ್ಕೆ ಮಾಡಿದ ಮಾರ್ಗ ಸರಿಯಾದ ನಂತರ ನಿಜವಾದ ಸಂಪನ್ಮೂಲವನ್ನು ತೆರೆದು ಹಿಂತಿರುಗುವ ಸಂಚಾರವನ್ನು ದೃಢೀಕರಿಸಿ. ping ಉತ್ತರವು ಒಂದು ದಿಕ್ಕಿನಲ್ಲಿ ಮಾರ್ಗವನ್ನು ಸಾಬೀತುಪಡಿಸುತ್ತದೆ ಮತ್ತು ಸೇವೆಯ ಬಗ್ಗೆ ಏನನ್ನೂ ಅಲ್ಲ, ಮತ್ತು ಸಂಗ್ರಹಿಸಿದ ಸಂಪರ್ಕದಲ್ಲಿ ಉತ್ತರಿಸುವ ಸೇವೆ ಇನ್ನೂ ಕಡಿಮೆ ಸಾಬೀತುಪಡಿಸುತ್ತದೆ.
ನಂತರ ಮತ್ತೆ ಸಂಪರ್ಕಿಸಿದ ನಂತರ ಇಡೀ ಪರಿಶೀಲನೆಯನ್ನು ಪುನರಾವರ್ತಿಸಿ. ಕ್ರಮದ ಮೌಲ್ಯವೆಂದರೆ ಅದು ಮುಂದಿನ ಸಂಪರ್ಕ ಏನು ಮಾಡುತ್ತದೆ ಎಂದು ಊಹಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಹೋಲಿಕೆ ಮತ್ತು ಮೆಟ್ರಿಕ್ ಎರಡೂ ಟಿಕೆಟ್‌ನಲ್ಲಿ ಸೇರುತ್ತವೆ.