Tailscale ಸಬ್ನೆಟ್ SNAT ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಿದ ನಂತರ ಏಕಮುಖ ಸಂಚಾರ

Tailscale ಸಬ್ನೆಟ್ ರೌಟರ್ನಲ್ಲಿ ಮೂಲ NAT ಆಫ್ ಮಾಡಿ, ಸುರಂಗ ಕೆಲಸ ಮಾಡುತ್ತಲೇ ಇರುತ್ತದೆ ಆದರೆ ಅದರ ಮೂಲಕ ಹೋಗುವ ಸಂಪರ್ಕಗಳು ನಿಲ್ಲುತ್ತವೆ. ವಿನಂತಿಗಳು ಗಮ್ಯಸ್ಥಾನಕ್ಕೆ ದೂರದ ಕ್ಲೈಂಟ್ನ ಸ್ವಂತ ಓವರ್ಲೇ ವಿಳಾಸದೊಂದಿಗೆ ತಲುಪುತ್ತವೆ, ಇದು ಬದಲಾವಣೆಯ ಉದ್ದೇಶವೇ, ಮತ್ತು ಉತ್ತರಗಳಿಗೆ ಈಗ LAN ಎಂದೂ ತಿಳಿಯಬಾರದಿದ್ದ ಮಾರ್ಗ ಬೇಕು. ಆ ಮಾರ್ಗವಿಲ್ಲದೆ ಪ್ಯಾಕೆಟ್ಗಳು ಇಳಿಯುತ್ತವೆ, ಉತ್ತರಗಳು ಸಾಮಾನ್ಯ ಗೇಟ್ವೇ ಮೂಲಕ ಹೊರಡುತ್ತವೆ, ಮತ್ತು ವೈಫಲ್ಯವು ಯಾವುದೇ ಫೈರ்ವಾಲ್ ನಿಯಮ ವಿವರಿಸದ ಫೈರ್ವಾಲ್ ಸಮಸ್ಯೆಯಂತೆ ಕಾಣುತ್ತದೆ. ಸುರಂಗ ಆರೋಗ್ಯಕರವಾಗಿದೆ; ಹಿಂತಿರುಗುವ ಭಾಗ ಕಾಣೆಯಾಗಿದೆ.

SNAT ಏನನ್ನು ಮರೆಮಾಡಿತ್ತು

SNAT ಸಕ್ರಿಯವಾಗಿದ್ದಾಗ ರೌಟರ್ ಸಬ್ನೆಟ್ಗೆ ರವಾನಿಸುವ ಮೊದಲು ಮೂಲ ವಿಳಾಸವನ್ನು ತನ್ನದೇ LAN ವಿಳಾಸಕ್ಕೆ ಪುನರ್ಬರಹ ಮಾಡುತ್ತದೆ, ಆದ್ದರಿಂದ ಗಮ್ಯಸ್ಥಾನವು ತಲುಪುವ ದಾರಿ ಈಗಾಗಲೇ ತಿಳಿದಿರುವ ಹೋಸ್ಟ್ಗೆ ಉತ್ತರಿಸುತ್ತದೆ ಮತ್ತು ಬೇರೆ ಏನನ್ನೂ ಕಾನ್ಫಿಗರ್ ಮಾಡಬೇಕಿಲ್ಲ. ಅದನ್ನು ಆಫ್ ಮಾಡಿದರೆ ಮೂಲ ಮೂಲ ಉಳಿಯುತ್ತದೆ, ಮತ್ತು ಗಮ್ಯಸ್ಥಾನವು ತನ್ನ ತಂತಿಯ ಮೇಲಿನ ನೆರೆಹೊರೆಯವರ ಬದಲು ಓವರ್ಲೇ ಶ್ರೇಣಿಯೊಳಗಿನ ವಿಳಾಸವನ್ನು ನೋಡುತ್ತದೆ. ಆ ವಿಳಾಸವು ನಿಜವಾದದ್ದು ಮತ್ತು tailnet ಉದ್ದಕ್ಕೂ ರೂಟ್ ಮಾಡಬಹುದಾದದ್ದು, ಆದರೆ ಡಿಫಾಲ್ಟ್ ಗೇಟ್ವೇ ಮೂಲಕ LAN ನಿಂದ ಅದನ್ನು ತಲುಪಲು ಸಾಧ್ಯವಿಲ್ಲ. ದಾಖಲಿತ ಸ್ವಿಚ್ --snat-subnet-routes=false, ಇದು Linux ಸಬ್ನೆಟ್ ರೌಟರ್ಗೇ ಅನ್ವಯಿಸುತ್ತದೆ.

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

ಹಿಂತಿರುಗುವ ಮಾರ್ಗ ಎಲ್ಲಿರಬಹುದು

ಮೂರು ಸ್ಥಾನಗಳು ಸಾಮಾನ್ಯ, ಮತ್ತು ಅವು ಸರಿಯಾಗಿರುವಿಕೆಯಲ್ಲಿ ಅಲ್ಲ, ತಲುಪುವಿಕೆಯಲ್ಲಿ ಭಿನ್ನ. ಗಮ್ಯಸ್ಥಾನ ಹೋಸ್ಟ್ನಲ್ಲಿನ ಸ್ಥಿರ ಮಾರ್ಗ ಅತ್ಯಂತ ನೇರ ಮತ್ತು ಅತ್ಯಂತ ಕಡಿಮೆ ವಿಸ್ತರಣೀಯ, ಏಕೆಂದರೆ ಪ್ರತಿ ಸಾಧನಕ್ಕೂ ತನ್ನದೇ ಪ್ರತಿ ಬೇಕು. VPC ಅಥವಾ ಸೈಟ್ ರೌಟರ್ನಲ್ಲಿನ ಮಾರ್ಗ ಕೋಷ್ಟಕವು ಇಡೀ ಜಾಲವನ್ನು ಒಟ್ಟಿಗೇ ಆವರಿಸುತ್ತದೆ, ಮತ್ತು ವರ್ಗರಹಿತ ಸ್ಥಿರ ಮಾರ್ಗಗಳನ್ನು ಹೊತ್ತ DHCP ಆಯ್ಕೆ ಕ್ಲೈಂಟ್ಗಳನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ತಲುಪುತ್ತದೆ ಆದರೆ ಅದನ್ನು ನಿರ್ಲಕ್ಷಿಸುವ ಸಾಧನಗಳಲ್ಲಿ ಸದ್ದಿಲ್ಲದೆ ವಿಫಲವಾಗುತ್ತದೆ.

ip route add 100.64.0.0/10 via 192.168.1.10
ip route get 100.64.0.5

ಯಾವ ಸ್ಥಾನವನ್ನು ಆರಿಸಿದರೂ, ಮುಂದಿನ ಹಾಪ್ ರೌಟರ್ನ LAN ವಿಳಾಸ ಮತ್ತು ಎಂದೂ ಅದರ tailnet ವಿಳಾಸವಲ್ಲ. LAN ಹೋಸ್ಟ್ ಈ ಮಾರ್ಗ ಇಲ್ಲದೆ ಓವರ್ಲೇ ತಲುಪಲು ಸಾಧ್ಯವಿಲ್ಲ, ಆದ್ದರಿಂದ ಓವರ್ಲೇ ಒಳಗಿನ ಮುಂದಿನ ಹಾಪ್ ವೃತ್ತಾಕಾರ ಮತ್ತು ಪ್ಯಾಕೆಟ್ ಅನ್ನು ಎಲ್ಲಿಗೂ ಕಳುಹಿಸುವುದಿಲ್ಲ. ಆ ಒಂದೇ ತಪ್ಪು ಸರಿಯಾಗಿ ಕಾಣುವ ಮತ್ತು ಆದರೂ ವಿಫಲವಾಗುವ ಹೆಚ್ಚಿನ ಸಂರಚನೆಗಳನ್ನು ವಿವರಿಸುತ್ತದೆ, ಮತ್ತು ರೌಟರ್ನ ಸ್ವಂತ ಕೋಷ್ಟಕವನ್ನು ಮಾತ್ರ ಓದುವ ಪ್ರತಿ ಪರಿಶೀಲನೆಯನ್ನೂ ದಾಟುತ್ತದೆ. ನೀವು ಯಾವ ಸ್ಥಾನ ಬಳಸಿದಿರಿ ಎಂದು ಬರೆದಿಡಿ, ಇಲ್ಲದಿದ್ದರೆ ಮುಂದಿನ ವ್ಯಕ್ತಿ ತಪ್ಪಾದದ್ದನ್ನು ಪರೀಕ್ಷಿಸುತ್ತಾರೆ.

ವೈಫಲ್ಯವನ್ನು ಏಕಮುಖ ಸಂಚಾರವಾಗಿ ಓದುವುದು

ಲಕ್ಷಣವನ್ನು ಕಾರಣಕ್ಕಿಂತ ಸುಲಭವಾಗಿ ಗುರುತಿಸಬಹುದು: ಸೇವೆ ರೌಟರ್ನಲ್ಲೇ ಉತ್ತರಿಸುತ್ತದೆ ಮತ್ತು ದೂರದ ಕ್ಲೈಂಟ್ನಿಂದ ಮೌನವಾಗಿರುತ್ತದೆ. ಗಮ್ಯಸ್ಥಾನದಲ್ಲಿ ಸೆರೆಹಿಡಿಯುವಿಕೆ ವಿನಂತಿಗಳು ಬರುತ್ತಿರುವುದನ್ನು ಮತ್ತು ಉತ್ತರಗಳು ಹೋಗುತ್ತಿರುವುದನ್ನು ತೋರಿಸುತ್ತದೆ, ಅದು ಆ ಉತ್ತರಗಳು ಎಲ್ಲಿಗೆ ಹೋಗುತ್ತಿವೆ ಎಂದು ಗಮನಿಸುವವರೆಗೆ ಯಶಸ್ಸಿನಂತೆ ಕಾಣುತ್ತದೆ. ಅವು ಡಿಫಾಲ್ಟ್ ಗೇಟ್ವೇ ಕಡೆಗೆ ಹೋಗುತ್ತಿವೆ, ಅಂದರೆ ಒಳಬರುವ ಭಾಗ ಕೆಲಸ ಮಾಡಿತು ಮತ್ತು ಹಿಂತಿರುಗುವ ಭಾಗ ಮಾಡಲಿಲ್ಲ.

ಬದಲಾಗಿ ರೌಟರ್ನಲ್ಲಿ ಸೆರೆಹಿಡಿಯಿರಿ, ಏಕೆಂದರೆ ಅದು ಒಂದು ವಿನಿಮಯದ ಎರಡೂ ದಿಕ್ಕುಗಳನ್ನು ನೋಡುತ್ತದೆ ಮತ್ತು ಉತ್ತರ ಎಂದಾದರೂ ಬಂದಿತೇ ಎಂದು ತೋರಿಸುತ್ತದೆ. ಉತ್ತರ ಗಮ್ಯಸ್ಥಾನದಲ್ಲಿ ಕಾಣಿಸಿ ರೌಟರ್ನಲ್ಲಿ ಎಂದೂ ಕಾಣಿಸದಿದ್ದರೆ, ಮಾರ್ಗವು ಗಮ್ಯಸ್ಥಾನದ ಕಡೆ ಕಾಣೆಯಾಗಿದೆ ಅಥವಾ ತಪ್ಪಾಗಿದೆ. ಅದು ರೌಟರ್ನಲ್ಲಿ ಕಾಣಿಸಿ ಅಲ್ಲೇ ನಿಂತರೆ, ಸಮಸ್ಯೆ ಮುಂದಿದೆ ಮತ್ತು ಬೇರೆ ತನಿಖೆಗೆ ಸೇರುತ್ತದೆ.

sudo tcpdump -ni any host 100.64.0.5
ip route get 100.64.0.5

ನಿಜವಾದ ವಿಳಾಸ ಮಾರ್ಗಕ್ಕೆ ಅರ್ಹವೇ

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

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

ಫೈರ್ವಾಲ್, ಲಾಗಿಂಗ್ ಮತ್ತು ದ್ವಿಗುಣ ಪಾತ್ರ

ರೌಟರ್ನ LAN ವಿಳಾಸಕ್ಕೆ ಹೊಂದಿಕೆಯಾಗುತ್ತಿದ್ದ ಪ್ರತಿ ನಿಯಮವೂ ಈಗ ಬೇರೆ ಮೂಲಕ್ಕೆ ಹೊಂದಿಕೆಯಾಗುತ್ತದೆ, ಮತ್ತು ಇದರಲ್ಲಿ ಅನುಮತಿ ನಿಯಮಗಳು ಮತ್ತು ರೌಟರ್ ಅನ್ನು ಕ್ಲೈಂಟ್ ಎಂದು ದಾಖಲಿಸಿದ ಯಾವುದೇ ಲಾಗ್ ಕ್ಷೇತ್ರ ಸೇರಿವೆ. ಆ ನಿಯಮಗಳನ್ನು ಮೊದಲ ಪರೀಕ್ಷೆಗೆ ಮೊದಲೇ ಓದಿ, ಮೊದಲ ವೈಫಲ್ಯದ ನಂತರವಲ್ಲ, ಏಕೆಂದರೆ ರೌಟರ್ನ ವಿಳಾಸಕ್ಕೆ ಮಾತ್ರ ಅನುಮತಿ ನೀಡುವ ನಿಯಮವು ಹೊಸ ಮೂಲವನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ತಡೆಯುತ್ತದೆ. ಬದಲಿಯನ್ನು ಅಗತ್ಯವಿರುವ ಕ್ಲೈಂಟ್ ಮತ್ತು ಪೋರ್ಟ್ಗಳಿಗೆ ಸೀಮಿತಗೊಳಿಸಿ, ನಂತರ ಅದು ಇಡೀ tailnet ಅನ್ನು ಸದ್ದಿಲ್ಲದೆ ಒಪ್ಪಿಕೊಳ್ಳುತ್ತಿಲ್ಲ ಎಂದು ಖಚಿತಪಡಿಸಿ.

sudo nft list ruleset | grep -n '100\.64'
sudo iptables-save | grep -n '100\.64'

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