Wi-Fi ಬದಲಾದಾಗ ಅಥವಾ Ethernet ಸೇರಿಸಿದಾಗ ನಿಮ್ಮ VPN ಏಕೆ ಕಡಿತಗೊಳ್ಳುತ್ತದೆ
'ಹೊಸ SSID, ಆಕ್ಸೆಸ್ ಪಾಯಿಂಟ್ಗಳ ನಡುವಿನ ರೋಮಿಂಗ್ ಮತ್ತು ಸೇರಿಸಿದ ಕೇಬಲ್ ಟನೆಲ್ ಅನ್ನು ಮೂರು ಬೇರೆ ಬೇರೆ ಸ್ಥಳಗಳಲ್ಲಿ ಮುರಿಯುತ್ತವೆ. ಮೂಲ ವಿಳಾಸ, ನಂತರ ಮಾರ್ಗ, ನಂತರ ಪ್ರೋಟೋಕಾಲ್ ಪರಿಶೀಲಿಸಿ.'
ಎರಡು ವಿಷಯಗಳನ್ನು ಒಂದೇ ವೈಫಲ್ಯ ಎಂದು ವರದಿ ಮಾಡಲಾಗುತ್ತದೆ: ಲ್ಯಾಪ್ಟಾಪ್ ಬೇರೆ Wi-Fi ನೆಟ್ವರ್ಕ್ಗೆ ಹೋಯಿತು, ಅಥವಾ Wi-Fi ಚಾಲ್ತಿಯಲ್ಲಿರುವಾಗ ಕೇಬಲ್ ಸೇರಿಸಲಾಯಿತು. ಕ್ಲೈಂಟ್ ಇನ್ನೂ ಸಂಪರ್ಕಿತ ಎನ್ನುತ್ತದೆ, ಐಕಾನ್ ಆರೋಗ್ಯಕರವಾಗಿ ಕಾಣುತ್ತದೆ, ಮತ್ತು ಟನೆಲ್ ಏನನ್ನೂ ಸಾಗಿಸುವುದಿಲ್ಲ. ಒಳಗೆ ಮೂರು ಸ್ಥಿತಿ ತುಣುಕುಗಳು ಮಾತ್ರ ಚಲಿಸಬಹುದು - ಲಿಂಕ್, ಸ್ಥಳೀಯ ವಿಳಾಸ, ಡೀಫಾಲ್ಟ್ ಮಾರ್ಗ - ಮತ್ತು ಯಾವುದು ಚಲಿಸಿತು ಎಂಬುದು ಟನೆಲ್ ತಾನೇ ಚೇತರಿಸಿಕೊಳ್ಳುತ್ತದೆಯೇ ಅಥವಾ ಮತ್ತೆ ಸಂಪರ್ಕ ಬೇಕೇ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ. ನಾನು ಅವನ್ನು ಅದೇ ಕ್ರಮದಲ್ಲಿ ಪರಿಶೀಲಿಸುತ್ತೇನೆ, ಏಕೆಂದರೆ ಖಾತೆ ಸೆಟ್ಟಿಂಗ್ಗಳನ್ನು ಬದಲಿಸುವುದು ಅವುಗಳಲ್ಲಿ ಒಂದನ್ನೂ ಎಂದೂ ಸರಿಪಡಿಸಿಲ್ಲ.
ಲಿಂಕ್, ವಿಳಾಸ ಮತ್ತು ಮಾರ್ಗ ಸ್ವತಂತ್ರವಾಗಿ ಚಲಿಸುತ್ತವೆ
ಒಂದೇ ನೆಟ್ವರ್ಕ್ನ ಆಕ್ಸೆಸ್ ಪಾಯಿಂಟ್ಗಳ ನಡುವಿನ ರೋಮಿಂಗ್ ಸಾಮಾನ್ಯವಾಗಿ L2 ಘಟನೆ. ರೇಡಿಯೋ ಮತ್ತೆ ಸಂಯೋಜನೆಗೊಳ್ಳುತ್ತದೆ, ಇಂಟರ್ಫೇಸ್ ತನ್ನ ವಿಳಾಸ ಮತ್ತು ಗೇಟ್ವೇ ಉಳಿಸಿಕೊಳ್ಳುತ್ತದೆ, ಮತ್ತು ಟನೆಲ್ ಅವಲಂಬಿಸಿರುವ ಯಾವುದೂ ಬದಲಾಗುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ದೊಡ್ಡ ಕಚೇರಿಯಲ್ಲಿ ನಡೆಯುವುದು ಕೆಲವೊಮ್ಮೆ ಗಮನಕ್ಕೆ ಬರುವುದಿಲ್ಲ. ಬೇರೆ SSID ಗೆ ಸೇರುವುದು ಹಾಗಲ್ಲ: ಹಳೆಯ ಇಂಟರ್ಫೇಸ್ ಕೆಳಗೆ ಹೋಗಬಹುದು, DHCP ಹೊಸ ವಿಳಾಸ, ಹೊಸ ಗೇಟ್ವೇ ಮತ್ತು ಹೊಸ ರಿಜಾಲ್ವರ್ಗಳನ್ನು ಕೊಡುತ್ತದೆ, ಮತ್ತು ಟನೆಲ್ ಬಳಸುತ್ತಿದ್ದ ಹೊರ ಹರಿವು ಅಸ್ತಿತ್ವದಲ್ಲಿರುವುದಿಲ್ಲ.
Ethernet ಮೂರನೇ ರೂಪ ಸೇರಿಸುತ್ತದೆ. Wi-Fi ಎಂದೂ ಬೀಳುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಯಾವುದೇ ಲಿಂಕ್ ಘಟನೆ ಸಂಭವಿಸುವುದಿಲ್ಲ, ಆದರೂ ತಂತಿಯ ಇಂಟರ್ಫೇಸ್ ತನ್ನ ವಿಳಾಸದೊಂದಿಗೆ ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತದೆ ಮತ್ತು ಹೆಚ್ಚಾಗಿ ಮೆಟ್ರಿಕ್ನಲ್ಲಿ ಡೀಫಾಲ್ಟ್ ಮಾರ್ಗವನ್ನು ಗೆಲ್ಲುತ್ತದೆ. ಟನೆಲ್ ಇನ್ನು ಮುಂದೆ ಆದ್ಯತೆ ಇಲ್ಲದ ಮಾರ್ಗದಲ್ಲಿ ಚಾಲನೆಯಲ್ಲಿರುತ್ತದೆ, ಅಥವಾ ಕ್ಲೈಂಟ್ ತನ್ನ ಸಾಕೆಟ್ ಅನ್ನು ಪ್ರಾರಂಭಿಸಿದ ವೈರ್ಲೆಸ್ ನೆಟ್ವರ್ಕ್ಗೆ ಜೋಡಿಸಿಡುತ್ತದೆ. ಬ್ರೌಸರ್ನಿಂದ ಎರಡೂ ಒಂದೇ ರೀತಿ ಕಾಣುತ್ತವೆ: ಕೇಬಲ್ ಕ್ಲಿಕ್ ಆದ ಕ್ಷಣದಲ್ಲಿ ಪುಟಗಳು ನಿಲ್ಲುತ್ತವೆ.
ಹಾಗಾದರೆ ಮೊದಲ ಪ್ರಶ್ನೆ Wi-Fi ಬದಲಾಯಿತೇ ಎಂಬುದಲ್ಲ. ನೀವು ಬದ್ಧರಾಗಿರುವ ವಿಳಾಸ, ಅಥವಾ ಅಂತ್ಯ ಬಿಂದುವಿಗಿನ ಮಾರ್ಗ, ಟನೆಲ್ ಚಾಲ್ತಿಯಲ್ಲಿರುವಾಗ ಬದಲಾಯಿತೇ ಎಂಬುದು.
ಹೊರ ಸಾಕೆಟ್ ಈಗಷ್ಟೇ ಮಾಯವಾದ ವಿಳಾಸಕ್ಕೆ ಜೋಡಿಸಲ್ಪಟ್ಟಿದೆ
ಪ್ರತಿ ಟನೆಲ್ ಒಂದು ಹೊರ ಹರಿವು: ಸ್ಥಳೀಯ ವಿಳಾಸ ಮತ್ತು ಪೋರ್ಟ್ ಸರ್ವರ್ನ ವಿಳಾಸ ಮತ್ತು ಪೋರ್ಟ್ನೊಂದಿಗೆ ಮಾತನಾಡುತ್ತವೆ. Linux ನಲ್ಲಿ ಅದು ಹಳೆಯ ಮೂಲಕ್ಕೆ ಬದ್ಧವಾದ UDP ಸಾಕೆಟ್; ವಿಳಾಸವನ್ನು ಹಿಡಿದಿರುವ ಇಂಟರ್ಫೇಸ್ ತೆಗೆದಾಗ, ಕಳುಹಿಸುವಿಕೆಗಳು EADDRNOTAVAIL ನೊಂದಿಗೆ ವಿಫಲವಾಗುತ್ತವೆ ಅಥವಾ ಸರ್ವರ್ ಎಂದೂ ನೋಡದ ಮೂಲದೊಂದಿಗೆ ಹೊಸ ಇಂಟರ್ಫೇಸ್ ಮೂಲಕ ಹೊರಡುತ್ತವೆ.
ದೂರದ ಬದಿ ತನ್ನದೇ ಜೋಡಣೆ ಇಟ್ಟುಕೊಳ್ಳುತ್ತದೆ. MOBIKE ಇಲ್ಲದ IKEv2 SA ವಿಳಾಸಗಳ ಜೋಡಿಯಿಂದ ಗುರುತಿಸಲ್ಪಡುತ್ತದೆ, ಮತ್ತು ಒಂದು OpenVPN ಸೆಷನ್ ಅದು ಕಲಿತ ಪೀರ್ ವಿಳಾಸಕ್ಕೆ ಬದ್ಧವಾಗಿರುತ್ತದೆ, ಮತ್ತು NAT ಮ್ಯಾಪಿಂಗ್ ಅದನ್ನು ರಚಿಸಿದ ಖಾಸಗಿ ವಿಳಾಸ, ಪೋರ್ಟ್ ಮತ್ತು ಸಾರ್ವಜನಿಕ ವಿಳಾಸಕ್ಕೆ ಸೇರಿದೆ. ಬೇರೆ NAT ಹಿಂದೆ ಹೋಗಿ ಮತ್ತು ಪ್ರತಿ ಉತ್ತರವೂ ಇನ್ನಿಲ್ಲದ ಮ್ಯಾಪಿಂಗ್ಗೆ ಕಳುಹಿಸಲ್ಪಡುತ್ತದೆ. ನಿಮ್ಮ ಯಂತ್ರದಲ್ಲಿ ಏನೂ ತಪ್ಪಾಗಿ ಸಂರಚಿಸಲ್ಪಟ್ಟಿಲ್ಲ; ಐದು-ಜೋಡಿ ನೀವು ಬಿಟ್ಟ ನೆಟ್ವರ್ಕ್ಗೆ ತೋರಿಸುತ್ತದೆ.
ಸಿದ್ಧಾಂತ ಮಾಡುವ ಮೊದಲು ಸ್ಥಿತಿ ಓದಿ:
ss -unpಪ್ರತಿ ಟನೆಲ್ ಸಾಕೆಟ್ ನಿಜವಾಗಿ ಹಿಡಿದಿರುವ ಸ್ಥಳೀಯ ವಿಳಾಸ ಮತ್ತು ಪೋರ್ಟ್ ತೋರಿಸುತ್ತದೆ.ip route get 203.0.113.10ಕರ್ಣೆಲ್ ಈಗ ಅಂತ್ಯ ಬಿಂದುವಿಗೆ ಬಳಸುವ ಮೂಲ ವಿಳಾಸ ಮತ್ತು ಸಾಧನವನ್ನು ಮುದ್ರಿಸುತ್ತದೆ.wg show wg0 endpoints,swanctl --list-sasಅಥವಾ ಕ್ಲೈಂಟ್ ಲಾಗ್ ದೂರದ ಬದಿ ಮಾತನಾಡುತ್ತಿದೆ ಎಂದು ಭಾವಿಸುವ ಪೀರ್ ವಿಳಾಸ ತೋರಿಸುತ್ತದೆ.
ಸಾಕೆಟ್ ವಿಳಾಸ ಮತ್ತು ಮಾರ್ಗ ಹುಡುಕಾಟ ಹೊಂದಿಕೆಯಾಗದಿದ್ದರೆ ನೀವು ಒಡಕನ್ನು ಕಂಡುಕೊಂಡಿದ್ದೀರಿ, ಮತ್ತು ಯಾವುದೇ ರುಜುವಾತು ಬದಲಾವಣೆ ಅದನ್ನು ಮುಟ್ಟುವುದಿಲ್ಲ.
ಹೊಸ ಮೂಲ ವಿಳಾಸದೊಂದಿಗೆ ಪ್ರತಿ ಪ್ರೋಟೋಕಾಲ್ ಏನು ಮಾಡುತ್ತದೆ
ಕ್ಲೈಂಟ್ಗಳು ಬದಲಾವಣೆಯನ್ನು ಬೇರೆ ಬೇರೆ ಮಟ್ಟದಲ್ಲಿ ಹೀರಿಕೊಳ್ಳುತ್ತವೆ, ಮತ್ತು ಮತ್ತೆ ಸಂಪರ್ಕದ ನಡವಳಿಕೆಯಿಂದ ಊಹಿಸುವ ಬದಲು ನಾನು ಕ್ಲೈಂಟ್ ಸಂರಚನೆಯೊಂದಿಗೆ ಹೋಲಿಸುವುದು ಈ ಕೋಷ್ಟಕವನ್ನು.
| Tunnel | Recovery behaviour | Failure signature |
|---|---|---|
| WireGuard | Updates the peer endpoint when an authenticated packet arrives from a new address; no handshake needed if traffic continues. | Handshake current, no return traffic; wg show still lists the old endpoint. |
| IKEv2/IPsec | MOBIKE (RFC 4555) moves the SA to the new address; without it the responder discards packets from an unknown source. | DPD or keepalive timeouts, then a full rekey or a dead SA. |
| OpenVPN over UDP | --float accepts a packet from a new source mid-session; otherwise the session stays tied to the original peer address. | Idle until ping-restart fires, then a visible reconnect. |
| OpenVPN over TCP | The tunnel is a byte stream, so a changed source address breaks it outright. | Immediate reset and a new connection attempt. |
WireGuard ನ ರೋಮಿಂಗ್ ನಿಯಮ ಒಂದೇ ದಿಕ್ಕಿನಲ್ಲಿ ಮಾತ್ರ ಕೆಲಸ ಮಾಡುತ್ತದೆ: ಕ್ಲೈಂಟ್ ಮೊದಲು ಹೊಸ ವಿಳಾಸದಿಂದ ಕಳುಹಿಸಬೇಕು. ಹಳೆಯ ಇಂಟರ್ಫೇಸ್ಗೆ ಬದ್ಧವಾದ ಸಾಕೆಟ್ ಅದನ್ನು ಎಂದೂ ಮಾಡುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಟನೆಲ್ ಜೀವಂತವಾಗಿ ಕಾಣಬಹುದು ಆದರೆ ಅದರ ಹ್ಯಾಂಡ್ಶೇಕ್ ಟೈಮರ್ ವಯಸ್ಸಾಗುತ್ತಿರುತ್ತದೆ. ಪ್ರೋಟೋಕಾಲ್ ವಿವರಣೆ ಅಂತ್ಯ ಬಿಂದು ನವೀಕರಣದ ಷರತ್ತನ್ನು ನಿಖರವಾಗಿ ಹೇಳುತ್ತದೆ, ಮತ್ತು ಸಂರಚನೆ ಬದಲಿಸುವ ಮೊದಲು ಅದನ್ನು ಓದುವುದು ಯೋಗ್ಯ.
MOBIKE ಮಾತುಕತೆಯಿಂದ ನಿರ್ಧಾರವಾಗುತ್ತದೆ, ಊಹಿಸಲ್ಪಡುವುದಿಲ್ಲ. ಸರ್ವರ್ ಅದನ್ನು ನೀಡದಿದ್ದರೆ ಕ್ಲೈಂಟ್ ಮತ್ತೆ ಸ್ಥಾಪಿಸಬೇಕು, ಮತ್ತು ಇದು SA ಪಟ್ಟಿ ಅಥವಾ ಲಾಗ್ನಿಂದ ದೃಢೀಕರಿಸುವ ಸತ್ಯ, ತಿರುಗುವ ಚಕ್ರದಿಂದ ಊಹಿಸುವಂಥದ್ದಲ್ಲ.
ಮಾರ್ಗವನ್ನು ನಿರ್ಧರಿಸುವುದು ರೂಟ್ ಆದ್ಯತೆ, Wi-Fi ಐಕಾನ್ ಅಲ್ಲ
ಎರಡೂ ಇಂಟರ್ಫೇಸ್ಗಳು ಮೇಲಿದ್ದಾಗ ಕರ್ಣೆಲ್ ಮೆಟ್ರಿಕ್ ಮತ್ತು ಪ್ರಿಫಿಕ್ಸ್ ಉದ್ದದಿಂದ ಆಯ್ಕೆ ಮಾಡುತ್ತದೆ. ip route show default ಅಭ್ಯರ್ಥಿಗಳನ್ನು ಪಟ್ಟಿ ಮಾಡುತ್ತದೆ ಮತ್ತು ip route get 203.0.113.10 ಮೂಲ ವಿಳಾಸ ಸೇರಿದಂತೆ ನಿಜವಾದ ನಿರ್ಧಾರವನ್ನು ಬಗೆಹರಿಸುತ್ತದೆ. ಮೆಟ್ರಿಕ್ 100 ರಲ್ಲಿ ತಂತಿಯ ಡೀಫಾಲ್ಟ್ ಮತ್ತು 600 ರಲ್ಲಿ ವೈರ್ಲೆಸ್ ಎಂದರೆ ಕೇಬಲ್ ಕುಳಿತ ಕ್ಷಣದಲ್ಲೇ ಅಂತ್ಯ ಬಿಂದು ಚಲಿಸುತ್ತದೆ, ಆದರೆ ಮೊದಲು ಸಾಕೆಟ್ ತೆರೆದ ಪ್ರತಿ ಅಪ್ಲಿಕೇಶನ್ ತನ್ನ ಹಳೆಯ ಮೂಲವನ್ನು ಉಳಿಸಿಕೊಳ್ಳುತ್ತದೆ.
Windows ಸಹ ಸ್ವಯಂಚಾಲಿತ ಇಂಟರ್ಫೇಸ್ ಮೆಟ್ರಿಕ್ಗಳೊಂದಿಗೆ ಅದನ್ನೇ ಮಾಡುತ್ತದೆ, ಲಿಂಕ್ ವೇಗದಿಂದ ಪಕ್ಷಪಾತಗೊಂಡು. Get-NetRoute -DestinationPrefix 0.0.0.0/0 ಅಭ್ಯರ್ಥಿಗಳನ್ನು ವಿಂಗಡಿಸುತ್ತದೆ ಮತ್ತು Find-NetRoute -RemoteIPAddress 203.0.113.10 ಸ್ಟಾಕ್ ಆಯ್ಕೆ ಮಾಡುವ ಇಂಟರ್ಫೇಸ್ ಮತ್ತು ಮೂಲವನ್ನು ಹಿಂತಿರುಗಿಸುತ್ತದೆ. ತನ್ನ ಹೊರ ಸಾಕೆಟ್ ಅನ್ನು ಒಂದು ಇಂಟರ್ಫೇಸ್ಗೆ ಬಂಧಿಸುವ ಕ್ಲೈಂಟ್ ಮೆಟ್ರಿಕ್ ತಿರುಗಿದ ನಂತರವೂ ಅದನ್ನೇ ಬಳಸುತ್ತದೆ; ಅದು ಬಂಧನದ ನಿರ್ಧಾರ, ಮಾರ್ಗದ ದೋಷ ಅಲ್ಲ.
Android ವಿಭಜನೆಯನ್ನು ದೃಶ್ಯಗೊಳಿಸುತ್ತದೆ: ConnectivityManager ಲಭ್ಯವಿರುವ ನೆಟ್ವರ್ಕ್ಗಳು ಮತ್ತು ಪ್ರತ್ಯೇಕ ಡೀಫಾಲ್ಟ್ ವರದಿ ಮಾಡುತ್ತದೆ, ಮತ್ತು ಸಾಕೆಟ್ ಅನ್ನು Network ಆಬ್ಜೆಕ್ಟ್ಗೆ ಬಂಧಿಸುವ VPN ಅಪ್ಲಿಕೇಶನ್ ಮತ್ತೆ ಬಂಧಿಸುವವರೆಗೆ ಆ ಬಂಧನ ಇಡುತ್ತದೆ. macOS ನಲ್ಲಿ, scutil --nwi ಪ್ರಾಥಮಿಕ ಇಂಟರ್ಫೇಸ್ ಮತ್ತು ಸಿಸ್ಟಂ ಬಳಸುವ ಕ್ರಮವನ್ನು ಮುದ್ರಿಸುತ್ತದೆ.
DNS, MTU ಮತ್ತು IPv6 ಸಂಪರ್ಕದೊಂದಿಗೆ ಚಲಿಸುತ್ತವೆ
ಹೊಸ ಸಂಪರ್ಕ ಹೊಸ ರಿಜಾಲ್ವರ್ಗಳನ್ನು ತರುತ್ತದೆ. systemd-resolved ನಲ್ಲಿ DNS ಪ್ರತಿ ಲಿಂಕ್ಗೆ, resolvectl status ಯಾವ ಲಿಂಕ್ ಹೆಸರಿಗೆ ಉತ್ತರಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ತೋರಿಸುತ್ತದೆ, ಮತ್ತು ತನ್ನದೇ ರಿಜಾಲ್ವರ್ ಹಂಚುವ ಗೆಸ್ಟ್ ನೆಟ್ವರ್ಕ್ ಲಿಂಕ್ ಮತ್ತೆ ಆದ್ಯತೆ ಪಡೆಯುವವರೆಗೆ ಟನೆಲ್ ತಳ್ಳಿದ DNS ಅನ್ನು ಬಳಸದೇ ಬಿಡಬಹುದು. ಕ್ಯಾಪ್ಟಿವ್ ಪೋರ್ಟಲ್ ಅನ್ನು ಇನ್ನಷ್ಟು ಕೆಡಿಸುತ್ತದೆ: ಮೊದಲ HTTPS ವಿನಂತಿಗೆ ಅಂತ್ಯ ಬಿಂದುವಿನ ಬದಲು ಪೋರ್ಟಲ್ ಉತ್ತರಿಸುತ್ತದೆ, ಮತ್ತು ಕ್ಲೈಂಟ್ ಸತ್ತ ಸರ್ವರ್ ದಾಖಲಿಸುತ್ತದೆ.
ಮಾರ್ಗದ MTU ಕೂಡ ಬದಲಾಗುತ್ತದೆ. Ethernet ಮತ್ತು Wi-Fi ಸಾಮಾನ್ಯವಾಗಿ 1500 ಬೈಟ್ ಒಯ್ಯುತ್ತವೆ, PPPoE 1492, ಮತ್ತು ಮೊಬೈಲ್ ಲಿಂಕ್ಗಳು ಹೆಚ್ಚಾಗಿ ಕಡಿಮೆ. ಚಿಕ್ಕ MTU ಆನುವಂಶಿಕವಾಗಿ ಪಡೆದ ಟನೆಲ್ ದೊಡ್ಡ ಪ್ಯಾಕೆಟ್ಗಳಲ್ಲಿ ನಿಲ್ಲುತ್ತದೆ ಆದರೆ ಚಿಕ್ಕ ವಿನಂತಿಗಳು ಯಶಸ್ವಿಯಾಗುತ್ತವೆ, ಇದು ಅರ್ಧ ಮುರಿದ ಸಂಪರ್ಕ ಎಂದು ಓದಲ್ಪಡುತ್ತದೆ. ping -M do -s 1472 203.0.113.10 DF ಸೆಟ್ ಮಾಡಿದ 1500 ಬೈಟ್ ಪ್ಯಾಕೆಟ್ ಕಳುಹಿಸುತ್ತದೆ; ಮೌನ ಎಂದರೆ ಮಾರ್ಗ ನೀವು ಊಹಿಸಿದ್ದಕ್ಕಿಂತ ಚಿಕ್ಕದು.
IPv6 ಇನ್ನೊಂದು ಅರ್ಧ. ಹೊಸ ಪ್ರಿಫಿಕ್ಸ್ ನೀಡುವ ನೆಟ್ವರ್ಕ್ ದ್ವಿ-ಸ್ಟಾಕ್ ಕ್ಲೈಂಟ್ ಬಳಸುವ ಮೂಲವನ್ನು ಬದಲಿಸುತ್ತದೆ, ಮತ್ತು v4 ಮಾತ್ರದ ಟನೆಲ್ ನೀತಿ ಬರುವವರೆಗೆ v6 ಸಂಚಾರವನ್ನು ಹೊರಗಿಡುತ್ತದೆ. ip -6 route show default ಮತ್ತು ip -6 addr show ಹೊಸ ಲಿಂಕ್ಗೆ v6 ಮಾರ್ಗ ಇದೆಯೇ ಎಂಬುದಕ್ಕೆ ಉತ್ತರಿಸುತ್ತವೆ.
ವಿವರಿಸುವ ಬದಲು ಪರಿವರ್ತನೆಯನ್ನು ಮರುಸೃಷ್ಟಿಸಿ
ಒಂದು ನಿರುಪದ್ರವ ವಿನಂತಿ ಆಯ್ಕೆ ಮಾಡಿ ಮತ್ತು ಬದಲಾವಣೆಯ ಎರಡೂ ಬದಿಗಳಲ್ಲಿ ಅದೇ ಮೂರು ಆಜ್ಞೆಗಳನ್ನು ಚಲಾಯಿಸಿ: ip -br addr, ip route show default, ip route get 203.0.113.10. ನಂತರ ಟನೆಲ್ ಇನ್ನೂ ಪ್ಯಾಕೆಟ್ಗಳನ್ನು ಹೊರಡಿಸುತ್ತದೆಯೇ ಎಂದು ನೋಡಿ - tcpdump -ni any udp port 51820 WireGuard ಗಾಗಿ, ಉಳಿದ ಎಲ್ಲದಕ್ಕೂ ಸರಿಹೊಂದುವ ಪೋರ್ಟ್. ಹಳೆಯ ಮೂಲದಿಂದ ಹೊರಡುವ ಪ್ಯಾಕೆಟ್ಗಳು ಬಂಧನದ ಸಮಸ್ಯೆ ಎಂದರ್ಥ. ಹೊಸ ಮೂಲದಿಂದ ಉತ್ತರವಿಲ್ಲದೆ ಹೊರಡುವ ಪ್ಯಾಕೆಟ್ಗಳು ದೂರದ ಬದಿ ಅಥವಾ ನಡುವಿನ NAT ಎಂದರ್ಥ.
ಮೊದಲ ವೈಫಲ್ಯದೊಂದಿಗೆ ಯಾವ ಘಟನೆ ಹೊಂದಿಕೆಯಾಯಿತು ಎಂಬುದನ್ನು ಗಮನಿಸಿ: ಲಿಂಕ್ ಕೆಳಗೆ, ವಿಳಾಸ ಬದಲಾವಣೆ, ಅಥವಾ ಡೀಫಾಲ್ಟ್ ಮಾರ್ಗ ಬದಲಾವಣೆ. ಇವು ಬೇರೆ ಬೇರೆ ಒಡೆಯರನ್ನು ಸೂಚಿಸುತ್ತವೆ - ಮತ್ತೆ ಬಂಧಿಸಬೇಕಾದ ಕ್ಲೈಂಟ್, ಮತ್ತೆ ಪಡೆಯಬೇಕಾದ ವಿಳಾಸ, ಅಥವಾ ಸಂರಚನಾ ಫೈಲ್ಗೆ ಸೇರಿದ ಮಾರ್ಗ, ಶಾಶ್ವತ ಬೈಪಾಸ್ ನಿಯಮಕ್ಕಲ್ಲ.
ಸರಿಪಡಿಸಲಾಗಿದೆ ಎಂದು ಹೇಳುವ ಮೊದಲು, ನೇರ ಸಂಚಾರದ ಬ್ಲಾಕ್ ಅಂತರದ ಉದ್ದಕ್ಕೂ ಇನ್ನೂ ಇದೆ ಎಂದು ಮತ್ತು ಹೆಸರುಗಳು ಹೊಸ ಸಂಪರ್ಕದ ಮೂಲಕ ಪರಿಹರಿಸಲ್ಪಡುತ್ತವೆ ಎಂದು ಖಚಿತಪಡಿಸಿ. ಸ್ವಿಚ್ ನಂತರವೂ ಕ್ಲೈಂಟ್ ಹಳೆಯ ಅಂತ್ಯ ಬಿಂದುವನ್ನು ಹಿಡಿದಿಟ್ಟುಕೊಂಡರೆ, ಮೊದಲು ರೋಮಿಂಗ್ ಅಥವಾ float ಸೆಟ್ಟಿಂಗ್ ಸರಿಪಡಿಸಿ. ಸರಿಯಾಗಿ ರೋಮಿಂಗ್ ಮಾಡಿಯೂ ಉತ್ತರ ಸಿಗದಿದ್ದರೆ, ಸರ್ವರ್ನ ಪೀರ್ ಗುರುತು ಮತ್ತು ಮಾರ್ಗದ NAT ನೋಡಿ, ಮತ್ತು ಮುಂದಿನ ವ್ಯಕ್ತಿ ಹೋಲಿಸಲು ಅನುವು ಮಾಡಲು ಎರಡೂ ನೆಟ್ವರ್ಕ್ ಸಂದರ್ಭಗಳನ್ನು ವರದಿಯಲ್ಲಿ ಇರಿಸಿ.