ಅನುಮೋದಿತ Tailscale ಸಬ್ನೆಟ್ ರೂಟ್ ಇನ್ನೂ ಸಮಯ ಮೀರುವುದೇಕೆ

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

ನಾಲ್ಕು ಹಂತಗಳು, ಒಂದು ವೈಫಲ್ಯ

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

ನಾಲ್ಕನೇ ಹಂತವನ್ನು ಹೆಚ್ಚಾಗಿ ಬಿಟ್ಟುಬಿಡುತ್ತಾರೆ, ಏಕೆಂದರೆ ಮೊದಲ ಮೂರು ಗೋಚರ ಸ್ಥಿತಿಯನ್ನು ಉಂಟುಮಾಡುತ್ತವೆ. ರೂಟರ್‌ನ ಸ್ವಂತ tailnet ವಿಳಾಸವನ್ನು ಆವರಿಸುವ ಅನುಮತಿ ಅದರ ಹಿಂದಿನ ಖಾಸಗಿ ಸಬ್ನೆಟ್ ಅನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಆವರಿಸುವುದಿಲ್ಲ. ಇವು ವಿಭಿನ್ನ ಗಮ್ಯಸ್ಥಾನಗಳು, ಮತ್ತು ನೀತಿಯನ್ನು ಪ್ರತಿ ಗಮ್ಯಸ್ಥಾನಕ್ಕೂ ಪ್ರತ್ಯೇಕವಾಗಿ ಮೌಲ್ಯಮಾಪನ ಮಾಡಲಾಗುತ್ತದೆ.

Linux ನಲ್ಲಿ ಮೂರನೇ ಹಂತಕ್ಕೆ ಜನರನ್ನು ಬೆಚ್ಚಿಬೀಳಿಸುವ ಡೀಫಾಲ್ಟ್ ಕೂಡ ಇದೆ: ಸಬ್ನೆಟ್ ರೂಟ್‌ಗಳನ್ನು ಸ್ವೀಕರಿಸುವುದು ಐಚ್ಛಿಕ. ಹಲವು GUI ಕ್ಲೈಂಟ್‌ಗಳು ಘೋಷಿತ ರೂಟ್‌ಗಳನ್ನು ಡೀಫಾಲ್ಟ್‌ನಲ್ಲಿ ಸ್ವೀಕರಿಸುತ್ತವೆ, ಆದ್ದರಿಂದ ಮಿಶ್ರ ಫ್ಲೀಟ್‌ನಲ್ಲಿ ಒಂದು ಯಂತ್ರ ವಿಫಲವಾಗಿ ಕಾಣಬಹುದು, ಉಳಿದವು ಕೆಲಸ ಮಾಡುತ್ತಿರುವಾಗ.

ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಊಹಿಸುವ ಬದಲು ವಿಫಲವಾಗುತ್ತಿರುವ ಯಂತ್ರದಲ್ಲಿ ಸೆಟ್ಟಿಂಗ್ ದೃಢೀಕರಿಸಿ. ಕೆಲಸ ಮಾಡುವ ಯಂತ್ರಗಳಲ್ಲಿ ರೂಟ್ ಎಂದೂ ಕಾಣೆಯಾದ ತುಣುಕಾಗಿರಲಿಲ್ಲ, ಆದ್ದರಿಂದ tailnet ಬದಿ ಆರೋಗ್ಯಕರವಾಗಿದೆ ಎಂದು ಅವು ಸಾಬೀತುಪಡಿಸಲಿ. Tailscale ನ ಸಬ್ನೆಟ್ ರೂಟರ್ ದಸ್ತಾವೇಜು ಅನುಮೋದನೆ, ಕ್ಲೈಂಟ್‌ನ ರೂಟ್ ಸ್ವೀಕಾರ ಮತ್ತು ನೀತಿ ಹಂತವನ್ನು ಒಳಗೊಳ್ಳುತ್ತದೆ.

ಕ್ಲೈಂಟ್ ಚಲಿಸುವಲ್ಲಿಯೇ ರೂಟ್ ಪರಿಶೀಲಿಸಿ

ರೂಟರ್‌ನಲ್ಲಿ ಅಲ್ಲ, ವಿಫಲವಾಗುತ್ತಿರುವ ಕ್ಲೈಂಟ್‌ನಿಂದ ಪ್ರಾರಂಭಿಸಿ. ರೂಟ್ ಇದೆ ಎಂದು ಮತ್ತು ಕ್ಲೈಂಟ್ ಸೆಟ್ಟಿಂಗ್ ರೂಟ್‌ಗಳನ್ನು ಸ್ವೀಕರಿಸಲು ಅನುಮತಿಸುತ್ತದೆ ಎಂದು ದೃಢೀಕರಿಸಿ.

tailscale status
tailscale debug prefs | grep -i route
ip route get 10.20.0.42

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

Linux ನಲ್ಲಿ ರೂಟ್‌ಗಳನ್ನು ಸ್ವೀಕರಿಸಲು, ಫ್ಲ್ಯಾಗ್ ಸೆಟ್ ಆಗಿದೆ ಎಂದು ಊಹಿಸುವ ಬದಲು ಅದರೊಂದಿಗೆ ಮತ್ತೆ ಸಂಪರ್ಕಿಸಿ: tailscale up --accept-routes. ಬೇರೆ ಫ್ಲ್ಯಾಗ್‌ಗಳೊಂದಿಗೆ ಸೇರಿದ ಕ್ಲೈಂಟ್ ಅವನ್ನು ಬದಲಾಯಿಸುವವರೆಗೆ ಉಳಿಸಿಕೊಳ್ಳುತ್ತದೆ, ಆದ್ದರಿಂದ ಇನ್ನೊಂದನ್ನು ಸೇರಿಸುವ ಮೊದಲು ಪ್ರಸ್ತುತ ಸೆಟ್ಟಿಂಗ್ ಪರಿಶೀಲಿಸಿ. ಬದಲಾವಣೆಯ ನಂತರ ಮೊದಲ ಆದೇಶವನ್ನು ಮತ್ತೆ ಚಲಾಯಿಸಿದರೆ ರೂಟ್ ಕೋಷ್ಟಕದಲ್ಲಿ ಕಾಣಬೇಕು.

ಫಾರ್ವರ್ಡಿಂಗ್ ಮತ್ತು ಮರಳು ಮಾರ್ಗ ಸಾಬೀತುಪಡಿಸಿ

ಅನುಮೋದನೆ ರೂಟರ್ ಅನ್ನು ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ಫಾರ್ವರ್ಡ್ ಮಾಡಲು ಸೆಟ್ ಮಾಡುವುದಿಲ್ಲ, ಮತ್ತು ಉತ್ತರವನ್ನು ಏರ್ಪಡಿಸುವುದಿಲ್ಲ. ಎರಡೂ ರೂಟರ್‌ನ LAN ಬದಿಯಲ್ಲಿ ಹೋಸ್ಟ್ ಮಟ್ಟದ ವಿಷಯಗಳು. ಅವನ್ನು ಕ್ಲೈಂಟ್‌ನಲ್ಲಿ ಅಲ್ಲ, ರೂಟರ್‌ನಲ್ಲಿ ಪರೀಕ್ಷಿಸಿ.

sysctl net.ipv4.ip_forward
iptables -t nat -L POSTROUTING -n -v
tcpdump -ni any host 10.20.0.42 and port 443

ಮೊದಲ ಆದೇಶ 1 ಎಂದು ವರದಿ ಮಾಡಬೇಕು, ಇಲ್ಲದಿದ್ದರೆ ಕರ್ನೆಲ್ ಫಾರ್ವರ್ಡ್ ಮಾಡಿದ ಪ್ಯಾಕೆಟ್ ಅನ್ನು ಬಿಸಾಡುತ್ತದೆ. ಎರಡನೆಯದು ಸಬ್ನೆಟ್-ರೂಟ್ ಮಾಸ್ಕರೇಡಿಂಗ್ ಮೂಲವನ್ನು ಮತ್ತೆ ಬರೆಯುತ್ತಿದೆಯೇ ಎಂದು ತೋರಿಸುತ್ತದೆ, ಇದು ಡೀಫಾಲ್ಟ್ ವರ್ತನೆ ಮತ್ತು ಸಾಮಾನ್ಯವಾಗಿ ನೀವು ಬಯಸುವುದು. ಮೂರನೆಯದು ವಿನಂತಿ ಗಮ್ಯಸ್ಥಾನ ತಲುಪುತ್ತದೆಯೇ ಮತ್ತು ಏನಾದರೂ ಹಿಂತಿರುಗುತ್ತದೆಯೇ ಎಂದು ತೋರಿಸುತ್ತದೆ; ಉತ್ತರವಿಲ್ಲದ ವಿನಂತಿ ಮರಳು ಮಾರ್ಗದ ಸಮಸ್ಯೆ, ಅನುಮೋದನೆಯದಲ್ಲ. ಅವುಗಳಲ್ಲಿ ಯಾವುದನ್ನೂ ಬದಲಾಯಿಸುವ ಮೊದಲು ಮೂರು ಫಲಿತಾಂಶಗಳನ್ನು ಒಟ್ಟಿಗೆ ಓದಿ.

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

ಸಂಪನ್ಮೂಲಕ್ಕಾಗಿ ಪ್ರವೇಶ ನಿಯಮ ಓದಿ

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

tailscale status --json | head -40
tailscale ping <router-name-or-tailnet-ip>
ping -c 3 10.20.0.42

ಸ್ಥಿತಿ ಔಟ್‌ಪುಟ್ ಕ್ಲೈಂಟ್‌ನ ಸ್ವಂತ ವಿಳಾಸಗಳು ಮತ್ತು ಅದು ನೋಡಬಲ್ಲ ಪೀರ್‌ಗಳನ್ನು ಗುರುತಿಸುತ್ತದೆ, ಮತ್ತು ನೀತಿಯ ಮೂಲ-ಆಯ್ಕೆಗಾರರು ಅವಕ್ಕೆ ಹೊಂದಿಕೆಯಾಗಬೇಕು. tailscale ping ಸಬ್ನೆಟ್ ರೂಟರ್‌ನವರೆಗಿನ tailnet ಮಾರ್ಗವನ್ನು ಸಾಬೀತುಪಡಿಸುತ್ತದೆ; ಅದು ಪೀರ್ ಹೆಸರುಗಳು ಮತ್ತು tailnet ವಿಳಾಸಗಳನ್ನು ಪರಿಹರಿಸುತ್ತದೆ, ಘೋಷಿತ ಸಬ್ನೆಟ್‌ನೊಳಗಿನ ಹೋಸ್ಟ್‌ಗಳನ್ನಲ್ಲ. ಮೂರನೇ ಆದೇಶ ಸಬ್ನೆಟ್ ರೂಟ್ ಮೂಲಕ ಸಾಮಾನ್ಯ ICMP ಪ್ರತಿಧ್ವನಿ ಕಳುಹಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಅದರ ಫಲಿತಾಂಶ ರೂಟರ್ ಬದಲು ಗಮ್ಯಸ್ಥಾನವನ್ನು ವಿವರಿಸುತ್ತದೆ. tailnet ಮಟ್ಟದ ನಿರಾಕರಣೆ ಸಾಮಾನ್ಯವಾಗಿ ನಿರಾಕರಣೆಯಾಗಿ ಹಿಂತಿರುಗುತ್ತದೆ, ಹೊರಟು ಎಂದೂ ಮರಳದ ಪ್ಯಾಕೆಟ್ ಸಮಯ ಮೀರುತ್ತದೆ.

ವಿಫಲವಾದ ಹೆಸರು ವಿಫಲವಾದ ವಿಳಾಸಕ್ಕಿಂತ ಬೇರೆ ಪ್ರಶ್ನೆ; ರೂಟ್ ಅನ್ನು ದೂಷಿಸುವ ಮೊದಲು ಹೋಸ್ಟ್ ಅನ್ನು ನೇರವಾಗಿ ಪರಿಹರಿಸಿ. ಅನುಮತಿಯನ್ನು ಇಡೀ ಸಬ್ನೆಟ್‌ಗೆ ಬದಲು ಸಂಪನ್ಮೂಲದ ನಿಜವಾದ ಅಗತ್ಯಕ್ಕೆ ಅನುಗುಣವಾಗಿ ಬರೆಯಿರಿ. ಒಂದು ಅಪ್ಲಿಕೇಶನ್ ಕೆಲಸ ಮಾಡಲು ಇಡೀ /24 ತೆರೆಯುವುದು ಸಂಕುಚಿತ ವಿನಂತಿ ನಂತರ ಯಾರೂ ತೆಗೆಯಲು ಧೈರ್ಯ ಮಾಡದ ವಿಶಾಲ ಅನುಮತಿಯಾಗುವ ದಾರಿ.

ಗುರಿ ಖಾಸಗಿ ಸಬ್ನೆಟ್ ಅಲ್ಲದೆ ಇಂಟರ್ನೆಟ್ ನಿರ್ಗಮನವಾಗಿದ್ದರೆ, ಸರಿಯಾದ ಘಟಕ ನಿರ್ಗಮನ ನೋಡ್, ಸಬ್ನೆಟ್ ರೂಟರ್ ಅಲ್ಲ, ಮತ್ತು ನೀತಿ ಹಾಗೂ ರೂಟಿಂಗ್ ಅದಕ್ಕನುಗುಣವಾಗಿ ಭಿನ್ನವಾಗಿರುತ್ತವೆ. ಅನುಮತಿ ವಿಸ್ತರಿಸುವ ಮೊದಲು ಆ ನಿರ್ಣಯವನ್ನು ಪರಿಶೀಲಿಸಿ. ನಿರ್ಗಮನ ನೋಡ್ ಡೀಫಾಲ್ಟ್ ರೂಟ್ ಬದಲಾಯಿಸುತ್ತದೆ; ಸಬ್ನೆಟ್ ರೂಟರ್ ಕೇವಲ ಪ್ರಿಫಿಕ್ಸ್ ಘೋಷಿಸುತ್ತದೆ.