WSL2 ನಲ್ಲಿ Git VPN ಮೇಲೆ ನಿಲ್ಲುತ್ತದೆ: ಇಂಟರ್ಫೇಸ್ MTU ಅಥವಾ ಮಾರ್ಗ?

ಕ್ಲೋನ್ ದೃಢೀಕರಿಸುತ್ತದೆ, ಆಬ್ಜೆಕ್ಟ್‌ಗಳ ಎಣಿಕೆ ಕಾಣಿಸುತ್ತದೆ, ನಂತರ ನಿಮಿಷಗಳ ಕಾಲ ಏನೂ ಚಲಿಸುವುದಿಲ್ಲ. Windows VPN ಸಂಪರ್ಕಗೊಂಡಿದೆ ಎಂದು ವರದಿ ಮಾಡುತ್ತದೆ, ಹೋಸ್ಟ್‌ಹೆಸರು ಪರಿಹರಿಸಲ್ಪಡುತ್ತದೆ, ಮತ್ತು ಅದೇ ಯಂತ್ರದ ಬ್ರೌಸರ್ ಅದೇ ರೆಪೊಸಿಟರಿ ಪುಟವನ್ನು ಕಷ್ಟವಿಲ್ಲದೆ ಪಡೆಯುತ್ತದೆ. ಈ ಸಂಯೋಜನೆ ರುಜುವಾತುಗಳಿಗಲ್ಲ, ಪ್ಯಾಕೆಟ್ ಗಾತ್ರಕ್ಕೆ ಸೂಚಿಸುತ್ತದೆ, ಮತ್ತು ಗಾತ್ರದ ಪ್ರಶ್ನೆಯನ್ನು ಎರಡು ಸ್ಥಳಗಳಲ್ಲಿ ಕೇಳಬೇಕು ಏಕೆಂದರೆ WSL2 ತನ್ನದೇ MTU ಹೊಂದಿರುವ ತನ್ನದೇ Linux ಇಂಟರ್ಫೇಸ್ ಹೊಂದಿದೆ. ಒಂದು ಸಂಖ್ಯೆ ಮಾರ್ಗದ Windows ಭಾಗಕ್ಕೆ ಸೇರಿದೆ, ಇನ್ನೊಂದು ಡಿಸ್ಟ್ರಿಬ್ಯೂಷನ್‌ಗೆ, ಮತ್ತು VPN ಅಡಾಪ್ಟರ್ ಮಾತ್ರ ಓದಿದರೆ ಮಾರ್ಗದ ಅರ್ಧ ಭಾಗ ಪರಿಶೀಲಿಸದೆ ಉಳಿಯುತ್ತದೆ.

ಮೂರು ಸೂಚನೆಗಳು ಗಾತ್ರದ ಸಮಸ್ಯೆಯನ್ನು ಬೇರೆಯದರಿಂದ ಬೇರ್ಪಡಿಸುತ್ತವೆ

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

ಈ ಮೂರು ಒಟ್ಟಾಗಿ ಪ್ಯಾಕೆಟ್-ಗಾತ್ರದ ಕಲ್ಪನೆಯನ್ನು ಸಮರ್ಥಿಸುತ್ತವೆ. DNS ವೈಫಲ್ಯ, ಅವಧಿ ಮುಗಿದ ಟೋಕನ್, ನಿರಾಕರಿಸಲಾದ SSH ಕೀ ಮತ್ತು CONNECT ಅನ್ನು ನಿರಾಕರಿಸುವ ಪ್ರಾಕ್ಸಿ ಪ್ರತಿಯೊಂದೂ ತಮ್ಮದೇ ದೋಷವನ್ನು ಉಂಟುಮಾಡುತ್ತವೆ, ಮತ್ತು ಅವುಗಳಲ್ಲಿ ಯಾವುದೂ ಯಶಸ್ಸಿನ ನಂತರದ ನಿಲುಗಡೆಯಂತೆ ಕಾಣುವುದಿಲ್ಲ. ಪರೀಕ್ಷಿಸುವಾಗ ಅದೇ ರೆಪೊಸಿಟರಿ, ಸಾಗಣೆ ಮತ್ತು ಸಮಯ ವಿಂಡೋವನ್ನು ಉಳಿಸಿಕೊಳ್ಳುವುದೇ ಹೋಲಿಕೆಯನ್ನು ಪ್ರಾಮಾಣಿಕಗೊಳಿಸುತ್ತದೆ.

ನಿರ್ಧರಿಸುವ ಮೊದಲು ಎರಡೂ ಇಂಟರ್ಫೇಸ್‌ಗಳನ್ನು ಹೋಲಿಸಿ

ಒಂದೇ ಅಧಿವೇಶನದಲ್ಲಿ Windows ನೋಟ ಮತ್ತು Linux ನೋಟವನ್ನು ಸಂಗ್ರಹಿಸಿ, ಮತ್ತು ಯಾವ ಇಂಟರ್ಫೇಸ್ ಅದನ್ನು ಸಾಗಿಸುತ್ತದೆ ಎಂಬ ಊಹೆಯ ಬದಲು ರೆಪೊಸಿಟರಿಯ ವಿಳಾಸವನ್ನು ಹಿಡಿದಿಡಿ. ಕೆಳಗಿನ ಆದೇಶವು ಮೊದಲು ಗಮ್ಯಸ್ಥಾನವನ್ನು ಪರಿಹರಿಸುತ್ತದೆ, ಇದರಿಂದ ಮಾರ್ಗದ ಹುಡುಕಾಟವು ಕ್ಲೋನ್ ಸಂಪರ್ಕಿಸುವ ನಿಜವಾದ ಸರ್ವರ್ ಅನ್ನು ವಿವರಿಸುತ್ತದೆ, ಅದು ಬ್ರೌಸರ್ ತೋರಿಸಿದ ಹೆಸರಿಗಿಂತ ಭಿನ್ನವಾಗಿರಬಹುದು. ಎರಡೂ ಅರ್ಧಗಳನ್ನು ಹತ್ತಿರದ ಸಮಯದಲ್ಲಿ ಚಲಾಯಿಸಿ, ಏಕೆಂದರೆ VPN ಪ್ರಯತ್ನಗಳ ನಡುವೆ ಇಂಟರ್ಫೇಸ್ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಬದಲಿಸಬಹುದು.

netsh interface ipv4 show subinterfaces
wsl -d Ubuntu -- bash -lc 'dest=$(getent ahostsv4 github.com | awk \'NR==1{print $1}\'); ip -br link show; ip route get "$dest"'

Linux ಅರ್ಧವನ್ನು Windows ಶೆಲ್‌ಗೆ ಔಟ್‌ಪುಟ್ ಅಂಟಿಸುವ ಬದಲು ಡಿಸ್ಟ್ರಿಬ್ಯೂಷನ್ ಒಳಗೆ ಚಲಾಯಿಸಿ, ಏಕೆಂದರೆ ಇಂಟರ್ಫೇಸ್ ಹೆಸರುಗಳು ಮತ್ತು ಮಾರ್ಗದ ಆಯ್ಕೆ ಅಲ್ಲಿ ಮಾತ್ರ ಅರ್ಥಪೂರ್ಣ. Windows ಶೆಲ್‌ನಿಂದ ಅಂಟಿಸಿದ ಫಲಿತಾಂಶವು ತಪ್ಪು ಸಂಖ್ಯೆಗಳನ್ನು ಬಹಳ ಆತ್ಮವಿಶ್ವಾಸದಿಂದ ವರದಿ ಮಾಡುತ್ತದೆ. ಏನನ್ನಾದರೂ ಬದಲಿಸುವ ಮೊದಲು ಪ್ರತಿ ಬದಿಯಿಂದ ಸಾಧನ, ಆಯ್ಕೆಯಾದ ಮಾರ್ಗ ಮತ್ತು MTU ಅನ್ನು ದಾಖಲಿಸಿ.

ಸಂಖ್ಯೆ ಚಿಕ್ಕದಾಗಿರಬೇಕೇ ಎಂದು ನಿರ್ಧರಿಸಿ

ಮಾರ್ಗವು ಸಾಗಿಸಬಲ್ಲದಕ್ಕಿಂತ ದೊಡ್ಡ ಇಂಟರ್ಫೇಸ್ MTU ಸ್ವಯಂಚಾಲಿತವಾಗಿ ದೋಷವಲ್ಲ, ಏಕೆಂದರೆ ಮಾರ್ಗ MTU ಅನ್ವೇಷಣೆ ಇದಕ್ಕಾಗಿಯೇ ಇದೆ. ಅನ್ವೇಷಣೆಯನ್ನು ಹತ್ತಿಕ್ಕಿದಾಗ ವೈಫಲ್ಯ ರೂಪ ಕಾಣಿಸುತ್ತದೆ: ICMP ಸಂದೇಶಗಳು ಮಾರ್ಗದ ಎಲ್ಲೋ ಫಿಲ್ಟರ್ ಆಗುತ್ತವೆ, ಕಳುಹಿಸುವವನಿಗೆ ಮಿತಿ ಎಂದಿಗೂ ತಿಳಿಯುವುದಿಲ್ಲ, ಮತ್ತು ದೊಡ್ಡ ಪ್ಯಾಕೆಟ್‌ಗಳು ಕಣ್ಮರೆಯಾಗುತ್ತವೆ ಆದರೆ ಚಿಕ್ಕವು ದಾಟುತ್ತವೆ. ಇದು ಮಾರ್ಗದ ಗುಣಲಕ್ಷಣ, Git ನದಲ್ಲ. ಚಿಕ್ಕ ಫೈಲ್ ಯಶಸ್ವಿಯಾಗಿ ದೊಡ್ಡದು ಎಂದಿಗೂ ಮುಗಿಯದ ಸಂಪರ್ಕದಲ್ಲಿ ಇದಕ್ಕೂ ಕಾರಣ ಇದೇ.

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

ip -br link show dev eth0
sudo ip link set dev eth0 mtu 1380
ip -br link show dev eth0

ಸೆಟ್ಟಿಂಗ್ ಎಲ್ಲಿ ವಾಸಿಸಬೇಕು ಎಂದು ನಿರ್ಧರಿಸಿ

ಪರೀಕ್ಷೆಯಿಂದ ಮೂರು ಆಯ್ಕೆಗಳು ಬರುತ್ತವೆ, ಮತ್ತು ಸಾಮಾನ್ಯವಾಗಿ ಅವುಗಳಲ್ಲಿ ಒಂದೇ ಸೂಕ್ತ. ಚಿಕ್ಕ ಮೌಲ್ಯವು ವರ್ಗಾವಣೆಯನ್ನು ಸರಿಪಡಿಸಿದರೆ ಮತ್ತು ಮೌಲ್ಯವು ಈ ನೆಟ್‌ವರ್ಕ್‌ಗೆ ನಿಜವಾಗಿ ಅಗತ್ಯವಿದ್ದರೆ, ಸೆಟ್ಟಿಂಗ್‌ಗೆ ಜೀವನಚಕ್ರದ ಮಾಲೀಕ ಬೇಕು: ಡಿಸ್ಟ್ರಿಬ್ಯೂಷನ್‌ನಲ್ಲಿ ಸ್ಟಾರ್ಟ್ ಹುಕ್, ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ನಿರ್ವಹಿಸುವ ನೆಟ್‌ವರ್ಕ್ ಕಾನ್ಫಿಗರೇಶನ್, ಅಥವಾ ದಾಖಲಿತ ಕಾರ್ಯವಿಧಾನ. ಮೌಲ್ಯವು ಏನನ್ನೂ ಸರಿಪಡಿಸದಿದ್ದರೆ, ಅದನ್ನು ಹಿಂತಿರುಗಿಸಿ ಮತ್ತು ಸಾಗಣೆ, ಪ್ರಾಕ್ಸಿ ಮತ್ತು ದೃಢೀಕರಣದ ಪ್ರಶ್ನೆಗಳಿಗೆ ಮರಳಿ.

ಸ್ಟಾರ್ಟ್ ಹುಕ್ ಇದೆಯೇ ಎಂಬುದು ಬಳಸುತ್ತಿರುವ Windows ಮತ್ತು WSL ಆವೃತ್ತಿಗಳು ಮತ್ತು ಕಾನ್ಫಿಗರ್ ಮಾಡಿದ ನೆಟ್‌ವರ್ಕಿಂಗ್ ಮೋಡ್ ಅನ್ನು ಅವಲಂಬಿಸಿದೆ. Windows ನೆಟ್‌ವರ್ಕ್ ಅನ್ನು ಪ್ರತಿಬಿಂಬಿಸುವುದು VPN ಡಿಸ್ಟ್ರಿಬ್ಯೂಷನ್‌ನೊಂದಿಗೆ ಹೇಗೆ ಸಂವಹನ ನಡೆಸುತ್ತದೆ ಎಂಬುದನ್ನು MTU ಹೊಂದಾಣಿಕೆಗಿಂತ ಹೆಚ್ಚು ಮುಖ್ಯವಾದ ರೀತಿಯಲ್ಲಿ ಬದಲಿಸಬಹುದು, ಆದ್ದರಿಂದ ಅದಕ್ಕೆ ಪರಿಹಾರವನ್ನು ವಿನ್ಯಾಸಗೊಳಿಸುವ ಮೊದಲು ಮೋಡ್ ಅನ್ನು ಗುರುತಿಸಿ. ಒಂದು ಆಪರೇಟರ್ ಅಥವಾ ಒಂದು VPN ಪ್ರೊಫೈಲ್‌ಗೆ ಸರಿಹೊಂದುವ ಮೌಲ್ಯ ಮುಂದಿನದಕ್ಕೆ ಡೀಫಾಲ್ಟ್ ಅಲ್ಲ.

ತಪ್ಪಿಸಬೇಕಾದದ್ದು ಆಮಿಷದ ಸ್ಥಾನ: ಪ್ರತಿ ಸಂವಾದಾತ್ಮಕ ಶೆಲ್‌ನ ಸ್ಟಾರ್ಟಪ್ ಫೈಲ್‌ನಲ್ಲಿ ವಿಶೇಷಾಧಿಕಾರದ ನೆಟ್‌ವರ್ಕ್ ಆದೇಶ, ಅಥವಾ ಸ್ಕ್ರಿಪ್ಟ್ ಒಂದು ಸಾಲನ್ನು ಚಲಾಯಿಸಲು ಸಾಧ್ಯವಾಗುವಂತೆ ಇಡೀ ip ಬೈನರಿಗೆ ಪಾಸ್‌ವರ್ಡ್ ಇಲ್ಲದ sudo. ಎರಡೂ ರೋಗನಿರ್ಣಯವನ್ನು ಶಾಶ್ವತ ಒಡ್ಡುವಿಕೆಯಾಗಿ ಪರಿವರ್ತಿಸುತ್ತವೆ ಮತ್ತು ಮೂಲ ಸಮಸ್ಯೆಯನ್ನು ನಂತರ ನೋಡುವುದನ್ನು ಕಷ್ಟಕರಗೊಳಿಸುತ್ತವೆ.

ತಾಜಾ ಆರಂಭದ ನಂತರ ಪರಿಶೀಲಿಸಿ, ನಂತರ ಹಿಂತಿರುಗಿಸಿ

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

ip -br link show dev eth0
ip route get "$(getent ahostsv4 github.com | awk 'NR==1{print $1}')"

ದಾಖಲಾದ ಮೂಲ ಮೌಲ್ಯವನ್ನು ಬದಲಾವಣೆಯ ಪಕ್ಕದಲ್ಲಿ ಇರಿಸಿ ಪ್ರಯೋಗವನ್ನು ಸ್ವಚ್ಛವಾಗಿ ಹಿಂತೆಗೆದುಕೊಳ್ಳಬಹುದು, ಮತ್ತು ಯಾವ ವಿಳಾಸ ಕುಟುಂಬವನ್ನು ಪರೀಕ್ಷಿಸಲಾಗಿದೆ ಎಂದು ಗಮನಿಸಿ, ಏಕೆಂದರೆ IPv4 ಫಲಿತಾಂಶವು ಅದೇ ಹೋಸ್ಟ್‌ನ IPv6 ಸಂಪರ್ಕದ ಬಗ್ಗೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ. WSL ನೆಟ್‌ವರ್ಕಿಂಗ್ ದಾಖಲೆಗಳು ಪರಿಹಾರವು ಹೇಗಿರಬೇಕು ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುವ ಮೋಡ್‌ಗಳನ್ನು ವಿವರಿಸುತ್ತವೆ; MTU ಸಂಖ್ಯೆ ಸ್ವತಃ ಸ್ಥಳೀಯ ಮಾಪನ, ಶಿಫಾರಸು ಅಲ್ಲ.