WSL2 ಕಾರ್ಪೊರೇಟ್ VPN ಅನ್ನು ಆನುವಂಶಿಕವಾಗಿ ಪಡೆಯುವುದಿಲ್ಲ, ಮತ್ತು ಅದೇ ದೋಷ
WSL2 ತನ್ನದೇ ವರ್ಚುವಲ್ ನೆಟ್ವರ್ಕ್ನಲ್ಲಿ ಚಲಿಸುತ್ತದೆ ಮತ್ತು ಹೋಸ್ಟ್ನ VPN ಸ್ಟ್ಯಾಕ್ ಅನ್ನು ಎಂದಿಗೂ ಆನುವಂಶಿಕವಾಗಿ ಪಡೆಯುವುದಿಲ್ಲ. resolv.conf ಸಂಪಾದಿಸುವ ಮೊದಲೇ ಹೆಸರಿನ ವೈಫಲ್ಯಗಳನ್ನು ಪಥದ ವೈಫಲ್ಯಗಳಿಂದ ಬೇರ್ಪಡಿಸಿ.
ಆಂತರಿಕ ವಿಕಿ Edge ನಲ್ಲಿ ಲೋಡ್ ಆಗುತ್ತದೆ, ಆದರೆ ಡಿಸ್ಟ್ರಿಬ್ಯೂಷನ್ ಒಳಗೆ git clone ಸಮಯ ಮೀರಿ ನಿಲ್ಲುತ್ತದೆ. ಈ ಒಂದೇ ಅವಲೋಕನವನ್ನು ಸಾಮಾನ್ಯವಾಗಿ «VPN WSL2 ಅನ್ನು ತಡೆಯುತ್ತಿದೆ» ಎಂದು ಓದಲಾಗುತ್ತದೆ, ಮತ್ತು ಮುಂದಿನ ಗಂಟೆ /etc/resolv.conf ಸಂಪಾದಿಸುವಲ್ಲೇ ಕಳೆಯುತ್ತದೆ. ಹೆಚ್ಚು ಉಪಯುಕ್ತ ಓದುವಿಕೆ ಎಂದರೆ WSL2 ಗೆ ಹೋಸ್ಟ್ನ ನೆಟ್ವರ್ಕ್ ಪಥ ಆರಂಭದಲ್ಲೇ ಇರಲಿಲ್ಲ: ಅದು ತನ್ನದೇ ಅಡಾಪ್ಟರ್, ತನ್ನದೇ ಮಾರ್ಗಗಳು ಮತ್ತು Windows ಅದಕ್ಕಾಗಿ ಸೃಷ್ಟಿಸುವ resolver ಫೈಲ್ನೊಂದಿಗೆ ಯುಟಿಲಿಟಿ VM ನಲ್ಲಿ ಚಲಿಸುತ್ತದೆ. ಮುಂದಿನ ಎಲ್ಲವೂ ಆ ಮೂರರಲ್ಲಿ ನಿಜವಾಗಿ ಯಾವುದು ನಿಮಗೆ ಇಲ್ಲ ಎಂಬುದನ್ನು ಅವಲಂಬಿಸಿದೆ.
VM ಗೆ ತನ್ನದೇ ಸ್ಟ್ಯಾಕ್, ಮೆಟ್ರಿಕ್ಗಳು ಮತ್ತು resolver ಇವೆ
ಡಿಫಾಲ್ಟ್ NAT ಮೋಡ್ನಲ್ಲಿ, ಡಿಸ್ಟ್ರಿಬ್ಯೂಷನ್ ವರ್ಚುವಲ್ ಸ್ವಿಚ್ನ ಹಿಂದೆ ಕುಳಿತು ಹೋಸ್ಟ್ ಮೂಲಕ ಇಂಟರ್ನೆಟ್ ತಲುಪುತ್ತದೆ, ಆದರೆ ಹೋಸ್ಟ್ನ ಅಡಾಪ್ಟರ್ಗಳನ್ನು ನೋಡುವುದಿಲ್ಲ. ip addr ಖಾಸಗಿ ವಿಳಾಸದ ಒಂದು ಇಂಟರ್ಫೇಸ್ ತೋರಿಸುತ್ತದೆ, ip route ಆ ಸ್ವಿಚ್ ಮೂಲಕ ಡಿಫಾಲ್ಟ್ ಮಾರ್ಗ ತೋರಿಸುತ್ತದೆ, ಮತ್ತು /etc/resolv.conf Windows ಆಯ್ಕೆ ಮಾಡಿದ stub resolver ಕಡೆ ತೋರಿಸುವ ಸೃಷ್ಟಿತ ಫೈಲ್. Windows ಬದಿಯಲ್ಲಿ VPN ಕ್ಲೈಂಟ್ ಆರಂಭವಾದ ಕಾರಣ ಇವುಗಳಲ್ಲಿ ಯಾವುದೂ ಬದಲಾಗುವುದಿಲ್ಲ.
ಅದಕ್ಕೇ «ಬ್ರೌಸರ್ ಕೆಲಸ ಮಾಡುತ್ತದೆ» ಎಷ್ಟು ಕಡಿಮೆ ಸಾಬೀತು ಮಾಡುತ್ತದೆ. ಬ್ರೌಸರ್ ಹೋಸ್ಟ್ನ ಸ್ಟ್ಯಾಕ್, ಟನೆಲ್ ಮತ್ತು ಹೋಸ್ಟ್ನ resolver ನೀತಿಯನ್ನು ಬಳಸುತ್ತದೆ. ನಿಮ್ಮ ಶೆಲ್ ಬೇರೆ ಸ್ಟ್ಯಾಕ್ ಬಳಸುತ್ತದೆ, ಅದು ಆಕಸ್ಮಿಕವಾಗಿ ಒಂದು ಭೌತಿಕ ನೆಟ್ವರ್ಕ್ ಕಾರ್ಡ್ ಹಂಚಿಕೊಳ್ಳುತ್ತದೆ. ಅವು ಒಳ್ಳೆಯ ಸಂದರ್ಭದಲ್ಲಿ ಒಪ್ಪುತ್ತವೆ ಮತ್ತು VPN ಫಿಲ್ಟರ್ ಸ್ಥಾಪಿಸಿದಾಗ, DNS ಪಟ್ಟಿ ಮರುಬರೆದಾಗ ಅಥವಾ ವರ್ಚುವಲ್ ಸ್ವಿಚ್ನ ಸಬ್ನೆಟ್ಗೆ ಮಾರ್ಗ ಸೇರಿಸಿದಾಗ ನಿಖರವಾಗಿ ಭಿನ್ನವಾಗುತ್ತವೆ.
ನೀವು ಯಾವ ಜಗತ್ತಿನಲ್ಲಿದ್ದೀರಿ ಎಂಬುದನ್ನು ಎರಡು ಪರೀಕ್ಷೆಗಳು ನಿರ್ಧರಿಸುತ್ತವೆ, ಮತ್ತು ಅವು ಡಿಸ್ಟ್ರಿಬ್ಯೂಷನ್ ಒಳಗೆ ಚಲಿಸಬೇಕು:
getent hosts example.com
curl -sS -m 8 -o /dev/null -w "%{http_code}\n" 1.1.1.1
ip route
cat /etc/resolv.confಅಕ್ಷರಶಃ ವಿಳಾಸ ಉತ್ತರಿಸುತ್ತಿರುವಾಗ ಹೆಸರುಗಳು ವಿಫಲವಾಗುವುದು resolver ಸಮಸ್ಯೆ. ಹೆಸರುಗಳು ಮತ್ತು ವಿಳಾಸಗಳು ಒಟ್ಟಿಗೆ ವಿಫಲವಾಗುವುದು ಪಥದ ಸಮಸ್ಯೆ, ಮತ್ತು resolver ಸಂಪಾದನೆ ಅದನ್ನು ಸ್ಪರ್ಶಿಸುವುದೂ ಇಲ್ಲ. ಮುಂದೆ Windows ಬದಿಯ ಸಾಕ್ಷ್ಯ ಬರುತ್ತದೆ: Get-NetAdapter | Get-DnsClientServerAddress ಮತ್ತು route print -4 ನಿಮ್ಮ VM ವಾಸಿಸುವ ಸಬ್ನೆಟ್ ಅನ್ನು ಟನೆಲ್ ಆಕ್ರಮಿಸಿದೆಯೇ ಎಂದು ತೋರಿಸುತ್ತವೆ.
ಮೊದಲ ಪುರಾಣ: ಕಾರ್ಪೊರೇಟ್ DNS ಸರ್ವರ್ಗಳು ಅದನ್ನು ಸರಿಪಡಿಸುತ್ತವೆ
resolver ಫೈಲ್ ಸಂಪಾದಿಸುವುದು ಸಾಂಪ್ರದಾಯಿಕ ಸಲಹೆ, ಮತ್ತು ಅದು ಸುಮಾರು ಅರ್ಧ ಸಮಯ ಸರಿಯಾಗಿರುತ್ತದೆ. ಸರಿಯಾದಾಗ ನಿರ್ದಿಷ್ಟ ಕಾರಣಕ್ಕೆ ಸರಿ: ಸೃಷ್ಟಿತ ಫೈಲ್ ಸಾರ್ವಜನಿಕ ಹೆಸರುಗಳನ್ನು ಮಾತ್ರ ತಿಳಿದ resolver ಕಡೆ ತೋರಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ intranet.example.internal ಗಾಗಿ ಪ್ರಶ್ನೆ ಪಥ ಸರಿಯಾಗಿದ್ದರೂ ಅಸ್ತಿತ್ವದಲ್ಲಿಲ್ಲ ಎಂದು ಮರಳುತ್ತದೆ.
VPN ನ ಸರ್ವರ್ಗಳನ್ನು ಪಿನ್ ಮಾಡುವುದು ಎಂದರೆ Windows ಫೈಲ್ ಅನ್ನು ಮತ್ತೆ ಸೃಷ್ಟಿಸದಂತೆ ತಡೆಯುವುದು, ಏಕೆಂದರೆ ನೀವು ಕೈಯಿಂದ ಬರೆಯುವ ಯಾವುದೇ ಫೈಲ್ ಮುಂದಿನ ಆರಂಭದಲ್ಲಿ ಬದಲಾಗುತ್ತದೆ:
[network]
generateResolvConf = falseಅದನ್ನು /etc/wsl.conf ಆಗಿ ಉಳಿಸಿ, Windows ನಿಂದ wsl --shutdown ಚಲಾಯಿಸಿ, ನಂತರ ಡಿಸ್ಟ್ರಿಬ್ಯೂಷನ್ ಆರಂಭಿಸಿ ಮತ್ತು /etc/resolv.conf ಬರೆಯಿರಿ, ಟನೆಲ್ನ ಸರ್ವರ್ಗಳು ಮೊದಲು ಮತ್ತು ಸಾರ್ವಜನಿಕ resolver ಕೇವಲ ಬ್ಯಾಕಪ್ ಆಗಿ. ಇದು ನಿರ್ವಹಣಾ ವೆಚ್ಚದ ಶಾಶ್ವತ ಬದಲಾವಣೆ: ಫೈಲ್ ಇನ್ನು ಹೋಸ್ಟ್ ಅನ್ನು ಅನುಸರಿಸುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಕಾರ್ಪೊರೇಟ್ DNS ವಿಳಾಸಗಳು ಬದಲಾದಾಗ ಡಿಸ್ಟ್ರಿಬ್ಯೂಷನ್ ಹಳೆಯವನ್ನೇ ಕೇಳುತ್ತಲೇ ಇರುತ್ತದೆ. ಯಾರಾದರೂ ಆ ಫೈಲ್ನ ಮಾಲೀಕರಾಗಿರಬೇಕು.
ವೈಫಲ್ಯ ವಿಶಾಲವಾದಾಗಲೂ ಏನೂ ಮಾಡುವುದಿಲ್ಲ. curl 1.1.1.1 ಗೆ ಸಮಯ ಮೀರಿದರೆ, ಟನೆಲ್ ಕ್ಲೈಂಟ್ ವರ್ಚುವಲ್ ಸ್ವಿಚ್ ಫಿಲ್ಟರ್ ಮಾಡುತ್ತಿದೆ ಅಥವಾ VM ನ ಸಬ್ನೆಟ್ ಅನ್ನು ಟನೆಲ್ಗೆ ರೂಟ್ ಮಾಡುತ್ತಿದೆ, ಮತ್ತು ಸರಿಯಾದ resolver ನಿಮಗೆ ಇನ್ನೂ ತಲುಪಲಾಗದ ಹೆಸರುಗಳನ್ನು ಮಾತ್ರ ಕೊಡುತ್ತದೆ.
ಎರಡನೇ ಪುರಾಣ: ಮೆಟ್ರಿಕ್ ಬದಲಾವಣೆ ಉಳಿಯುತ್ತದೆ
ಹೆಸರುಗಳು ಪರಿಹಾರವಾಗಿ ಆದರೆ ಸಂಚಾರ ಭೌತಿಕ ಅಡಾಪ್ಟರ್ ಮೂಲಕ ಹೊರಟರೆ, ಇಂಟರ್ಫೇಸ್ ಮೆಟ್ರಿಕ್ಗಳೇ ಲಿವರ್. VPN ಅಡಾಪ್ಟರ್ಗೆ ಹೆಚ್ಚಿನ ವೆಚ್ಚ ಮತ್ತು WSL ಸ್ವಿಚ್ಗೆ ಕಡಿಮೆ ವೆಚ್ಚ ಕೊಡಿ:
Get-NetAdapter | Where-Object InterfaceDescription -Match "AnyConnect" | Set-NetIPInterface -InterfaceMetric 4000
Get-NetIPInterface -InterfaceAlias "vEthernet (WSL)" | Set-NetIPInterface -InterfaceMetric 1ನಂತರ ನೆನಪಿಡಿ, ಅನೇಕ ಕ್ಲೈಂಟ್ ಬಿಲ್ಡ್ಗಳಲ್ಲಿ ಟನೆಲ್ ಅಡಾಪ್ಟರ್ ಪ್ರತಿ ಸಂಪರ್ಕದಲ್ಲೂ ಮತ್ತೆ ಸೃಷ್ಟಿಯಾಗುತ್ತದೆ ಮತ್ತು ಮೆಟ್ರಿಕ್ ತನ್ನ ಡಿಫಾಲ್ಟ್ಗೆ ಮರಳುತ್ತದೆ. ಒಂದು ಬಾರಿಯ ಆದೇಶವು ಮೌನವಾಗಿ ಅವಧಿ ಮುಗಿಯುವ ಸರಿಪಡಿಸುವಿಕೆ, ಸಾಮಾನ್ಯವಾಗಿ ವಾರಾಂತ್ಯದಲ್ಲಿ, ಮತ್ತು ಟಿಕೆಟ್ «ಕಳೆದ ವಾರ ಕೆಲಸ ಮಾಡುತ್ತಿತ್ತು» ಎಂದು ಮರಳುತ್ತದೆ. VPN ಘಟನೆಯಿಂದ ಪ್ರಾರಂಭವಾಗುವ ನಿಗದಿತ ಕಾರ್ಯ, ಅಥವಾ ಬಳಕೆದಾರರು ಸಂಪರ್ಕದ ನಂತರ ಚಲಾಯಿಸುವ ಸ್ಕ್ರಿಪ್ಟ್, ಈ ಸರಿಪಡಿಸುವಿಕೆಯ ಪ್ರಾಮಾಣಿಕ ಆವೃತ್ತಿ.
ಅದೇ ಅವಧಿ ಒಂದು ಹಠಮಾರಿ ಪ್ರಿಫಿಕ್ಸ್ಗಾಗಿ ಸೇರಿಸಿದ ಹೋಸ್ಟ್ ಮಾರ್ಗಗಳಿಗೂ ಅನ್ವಯಿಸುತ್ತದೆ. ರೋಗನಿರ್ಣಯವಾಗಿ ಅವು ಮೌಲ್ಯಯುತ, ಏಕೆಂದರೆ ಸಮಸ್ಯೆ ಒಂದು ಗಮ್ಯಸ್ಥಾನವೇ ಅಥವಾ ಇಡೀ ಪಥವೇ ಎಂದು ಹೇಳುತ್ತವೆ, ಆದರೆ ಅವು ವಾಸ್ತುಶಿಲ್ಪವಲ್ಲ.
ಮೂರನೇ ಪುರಾಣ: ಒಂದು ಸರಿಪಡಿಸುವಿಕೆ ಪ್ರತಿ Windows ಬಿಲ್ಡ್ ಅನ್ನು ಆವರಿಸುತ್ತದೆ
| Approach | What it actually does |
|---|---|
| Resolver pin | Fixes private names only; no effect on path failures |
| Sidecar distribution | Forwards traffic over a socket to a helper VM, so the switch's filter no longer matters |
| Mirrored networking | Gives the distribution the host's interface set; also enables DNS tunnelling |
wsl-vpnkit ಎಂಬುದು sidecar ಮಾದರಿ: ಒಂದು ಸಣ್ಣ ಡಿಸ್ಟ್ರಿಬ್ಯೂಷನ್ ಹೋಸ್ಟ್ ಬದಿಯ ಪಥವನ್ನು ಹೊಂದಿದ್ದು ವರ್ಚುವಲ್ ಸಾಕೆಟ್ ಮೂಲಕ ಇತರ ಡಿಸ್ಟ್ರಿಬ್ಯೂಷನ್ಗಳಿಗೆ ಫಾರ್ವರ್ಡ್ ಮಾಡುತ್ತದೆ, ಆದ್ದರಿಂದ ಅಪ್ಲಿಕೇಶನ್ ಸಂಚಾರ ಫಿಲ್ಟರ್ ಆದ ಸ್ವಿಚ್ ಮೇಲೆ ಅವಲಂಬಿತವಾಗುವುದನ್ನು ನಿಲ್ಲಿಸುತ್ತದೆ. ಸ್ಟಾಕ್ ಪಥ ಕೆಲಸ ಮಾಡಬೇಕು, ಅಂದರೆ networkingMode ಮತ್ತು dnsTunneling ಓವರ್ರೈಡ್ಗಳನ್ನು %UserProfile%\.wslconfig ನಿಂದ ತೆಗೆದು, ಪ್ರತಿ ಕಾರ್ಯನಿರ್ವಹಣಾ ಡಿಸ್ಟ್ರಿಬ್ಯೂಷನ್ನಲ್ಲಿ generateResolvConf = true ಮರುಸ್ಥಾಪಿಸಿ ಮತ್ತು ಲಾಗಿನ್ನಲ್ಲಿ ಸೇವೆಯನ್ನು ಆರಂಭಿಸುವುದು.
ಮಿರರ್ಡ್ ಮೋಡ್ Windows 11 22H2 ಮತ್ತು ನಂತರದವುಗಳಲ್ಲಿ ಅಂತರ್ಗತ ಪರ್ಯಾಯ, ಮತ್ತು ಅದು ಒಂದು ಸೆಟ್ಟಿಂಗ್ ಜೊತೆಗೆ ಒಂದು ಶಟ್ಡೌನ್:
[wsl2]
networkingMode=mirroredಡಿಸ್ಟ್ರಿಬ್ಯೂಷನ್ ಒಳಗೆ ip addr ನಂತರ ಹೋಸ್ಟ್ನ ಅಡಾಪ್ಟರ್ಗಳನ್ನು ಪಟ್ಟಿ ಮಾಡುತ್ತದೆ, ಟನೆಲ್ ಅವುಗಳ ನಡುವೆ ಕಾಣಿಸಬಹುದು, ಮತ್ತು DNS ಟನೆಲಿಂಗ್ Windows resolver ಮೂಲಕ ಲುಕಪ್ಗಳನ್ನು ಫಾರ್ವರ್ಡ್ ಮಾಡುತ್ತದೆ ಕ್ಲೈಂಟ್ DNS ಪಟ್ಟಿ ಮರುಬರೆದರೂ. ಇದು ಸಾರ್ವತ್ರಿಕವಲ್ಲ: ಕೆಲವು ಫಿಲ್ಟರ್ ಡ್ರೈವರ್ಗಳು ಇನ್ನೂ ಮಿರರ್ಡ್ ಪಥವನ್ನು ಬಿಡುತ್ತವೆ, ಮತ್ತು Hyper-V ಫೈರ್ವಾಲ್ ನಿಯಮಗಳಿಗೆ ಸ್ಪಷ್ಟ ಅನುಮತಿ ಬೇಕಾಗಬಹುದು. Microsoft ನ WSL ನೆಟ್ವರ್ಕಿಂಗ್ ಮಾರ್ಗದರ್ಶಿ ಹೊಸದಕ್ಕೆ ಬರೆದ ಪಾಕವಿಧಾನವನ್ನು ಅನ್ವಯಿಸುವ ಮೊದಲು ನಿಮ್ಮ ಬಿಲ್ಡ್ನೊಂದಿಗೆ ಹೋಲಿಸಬೇಕಾದ ಪುಟ.
ಪ್ರತಿ ಬದಲಾವಣೆಯ ನಂತರ ಮೂರು ವಿಷಯಗಳನ್ನು ಪರೀಕ್ಷಿಸಿ
ಪ್ರತಿ ಯಂತ್ರಕ್ಕೆ ಒಂದು ಕಾರ್ಯವಿಧಾನ ಆರಿಸಿ ಬರೆದಿಡಿ, ಏಕೆಂದರೆ ಎರಡೂ ಕೆಟ್ಟದಾಗಿ ಸೇರುತ್ತವೆ. ಮಿರರ್ಡ್ ಮೋಡ್ ಮೇಲೆ sidecar ಫಾರ್ವರ್ಡಿಂಗ್ ಎರಡು ಪಟ್ಟು ಮಾಡುತ್ತದೆ, ಮತ್ತು .wslconfig ನಲ್ಲಿ ಹಳೆಯ sidecar ನಮೂದನ್ನು ಹೊಂದಿರುವ ಮಿರರ್ಡ್ ಹೋಸ್ಟ್ ಅಪ್ಗ್ರೇಡ್ ನಂತರ ವಿಫಲವಾಗುತ್ತದೆ, ಮೊದಲು ಅಲ್ಲ.
ನೀವು ಏನೇ ಆರಿಸಿದರೂ, ಸ್ವೀಕಾರ ಪರೀಕ್ಷೆ ಡಿಸ್ಟ್ರಿಬ್ಯೂಷನ್ ಒಳಗಿನ ಅದೇ ಮೂರು ವಿನಂತಿಗಳು: ಆಂತರಿಕ ಹೆಸರು, ಸಾರ್ವಜನಿಕ ಹೆಸರು ಮತ್ತು ಕಚ್ಚಾ ವಿಳಾಸ. ನಂತರ ಟನೆಲ್ ಸಂಪರ್ಕ ಕಡಿತಗೊಳಿಸಿ ಮತ್ತೆ ಸಂಪರ್ಕಿಸಿದ ನಂತರ, ಮತ್ತು wsl --shutdown ನಂತರ ಅವನ್ನು ಪುನರಾವರ್ತಿಸಿ. ಕೇವಲ ಆಂತರಿಕ ಹೆಸರು ವಿಫಲವಾದರೆ resolver ನೀತಿ; ಆಂತರಿಕ ಮತ್ತು ಸಾರ್ವಜನಿಕ ಹೆಸರುಗಳು ಒಟ್ಟಿಗೆ ವಿಫಲವಾದರೆ ವಿಳಾಸ ಕೆಲಸ ಮಾಡುತ್ತಿದ್ದರೂ resolver ನೀತಿ; ಎಲ್ಲವೂ ವಿಫಲವಾದರೆ ಪಥ.
ಒಂದು ಆಂತರಿಕ ಹೋಸ್ಟ್ ವಿಫಲವಾಗಿ ಉಳಿದವು ಕೆಲಸ ಮಾಡುತ್ತಿದ್ದರೆ, resolver ನೋಡುವುದನ್ನು ನಿಲ್ಲಿಸಿ ಆ ಪ್ರಿಫಿಕ್ಸ್ಗೆ ಕಾಣೆಯಾದ ಮಾರ್ಗವನ್ನು ಹುಡುಕಿ. ಮುಂದಿನ ಮರುಸಂಪರ್ಕದವರೆಗೆ ಎಲ್ಲವೂ ಕೆಲಸ ಮಾಡಿದರೆ, ನೀವು ರನ್ಟೈಮ್ ಸ್ಥಿತಿಯನ್ನು ಅವಲಂಬಿಸಿರುವ ಸರಿಪಡಿಸುವಿಕೆಯನ್ನು ಕಂಡುಕೊಂಡಿದ್ದೀರಿ, ಮತ್ತು ಅದನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಮತ್ತೆ ಅನ್ವಯಿಸಬೇಕು ಅಥವಾ ಮೇಲಿನ ಎರಡು ಕಾರ್ಯವಿಧಾನಗಳಲ್ಲಿ ಒಂದರಿಂದ ಬದಲಾಯಿಸಬೇಕು.