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

ಪ್ಯಾಕೆಟ್ ಸೆರೆಹಿಡಿಯುವಿಕೆ ನಿಜವಾಗಿ ಯಾವ ಹರಿವಿಗೆ ಸೇರಿದೆ

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

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

ಪ್ರಾಯೋಗಿಕ ಪರಿಶೀಲನೆ ಎರಡೂ ಬದಿಗಳನ್ನು ಒಟ್ಟಿಗೆ ಗಮನಿಸುವುದು. ರೌಟರ್ನಲ್ಲಿ ರಿಸಾಲ್ವರ್ನ ಸಾಕೆಟ್ ಪಟ್ಟಿ ಮಾಡಿ, ಅದನ್ನು ಸ್ಥಳೀಯವಾಗಿ ಕೇಳಿ ಮತ್ತು WAN ಇಂಟರ್ಫೇಸ್ ಸೆರೆಹಿಡಿಯಿರಿ:

sockstat -4 -l | grep :53
dig +short @127.0.0.1 example.com
tcpdump -ni igb0 udp port 53

ಸಾಕೆಟ್ ಪಟ್ಟಿಯು loopback ಅಥವಾ LAN ವಿಳಾಸಕ್ಕೆ ಬದ್ಧವಾದ ಆಲಿಸುವವರನ್ನು ತೋರಿಸಿದರೆ, ರೌಟರ್ ಇನ್ನೊಂದು ಹೋಸ್ಟ್ಗೆ ಫಾರ್ವರ್ಡ್ ಮಾಡುವ ಬದಲು ಸ್ಥಳೀಯವಾಗಿ ಉತ್ತರಿಸುತ್ತದೆ. ಆಗ ಸೆರೆಹಿಡಿಯುವಿಕೆ ಉಂಟಾದ ಅಪ್ಸ್ಟ್ರೀಮ್ ಪ್ರಶ್ನೆ ಸುರಂಗ ಇಂಟರ್ಫೇಸ್ ಮೂಲಕ ಅಥವಾ WAN ಮೂಲಕ ಹೊರಡುತ್ತದೆಯೇ ಎಂದು ತೋರಿಸುತ್ತದೆ, ಮತ್ತು ಅದೇ ನೀತಿ-ಮಾರ್ಗ ನಿಯಮ ಎಂದಿಗೂ ನೀಡದ ಉತ್ತರ.

ನೀತಿ-ಮಾರ್ಗವು ಎರಡನೇ ಪ್ರಶ್ನೆಯನ್ನು ಏಕೆ ಎಂದಿಗೂ ನೋಡುವುದಿಲ್ಲ

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

ಈ ವ್ಯತ್ಯಾಸವು ಪ್ರತಿ ಫರ್ಮ್ವೇರ್ ಮರುಬರವಿಕೆಯ ನಂತರವೂ ಉಳಿಯುತ್ತದೆ, ಏಕೆಂದರೆ ಅದು ವೈಶಿಷ್ಟ್ಯದಿಂದ ಅಲ್ಲ, ಪ್ಯಾಕೆಟ್ನ ಮಾರ್ಗದಿಂದ ಬರುತ್ತದೆ. ಸಾಧನವು ತನಗಾಗಿ ರಚಿಸುವ ಎಲ್ಲವೂ — ರಿಸಾಲ್ವರ್ ಪ್ರಶ್ನೆಗಳು, ಸಮಯ ಸಿಂಕ್ರೊನೈಸೇಶನ್, ನವೀಕರಣ ಪರಿಶೀಲನೆಗಳು ಅಥವಾ ಪ್ಯಾಕೆಟ್ ಕನ್ನಡಿಗಳ ಪ್ರವೇಶ — ಸ್ಥಳೀಯ ಮೂಲದ್ದಾಗಿದ್ದು ಅದೇ ಕುರುಡು ಚುಕ್ಕೆಗೆ ಬೀಳುತ್ತದೆ. ಅದಕ್ಕಾಗಿಯೇ ಲ್ಯಾಪ್ಟಾಪ್ನಿಂದ ಮಾಡಿದ ಪರೀಕ್ಷೆ ರೌಟರ್ ಬಗ್ಗೆ ಏನನ್ನೂ ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ.

pfSense ರಿಸಾಲ್ವರ್ ತನ್ನ ಅಪ್ಸ್ಟ್ರೀಮ್ ಮಾರ್ಗವನ್ನು ಎಲ್ಲಿ ನಿರ್ಧರಿಸುತ್ತದೆ

pfSense ಈ ವಿಭಜನೆಯನ್ನು ಗೋಚರವಾಗಿಸುತ್ತದೆ. ಕ್ಲೈಂಟ್ ಸಂಚಾರವನ್ನು ನೀತಿ-ಮಾರ್ಗದ ಮೂಲಕ VPN ಗೇಟ್ವೇ ಮೂಲಕ ಕಳುಹಿಸಬಹುದು, ಆದರೆ ಫೈರ್ವಾಲ್ನ ಸ್ವಂತ ಸಂಚಾರವು LAN ನಿಯಮಗಳ ಬದಲು ರಿಸಾಲ್ವರ್ನ ಹೊರಹೋಗುವ ಸೆಟ್ಟಿಂಗ್ ಅನ್ನು ಅನುಸರಿಸುತ್ತದೆ. ವೆಬ್ ಇಂಟರ್ಫೇಸ್ನಲ್ಲಿ ಆ ಸೆಟ್ಟಿಂಗ್ Services > DNS Resolver > Outgoing Network Interfaces ಅಡಿಯಲ್ಲಿದೆ, ಮತ್ತು ಅದರ ಮೌಲ್ಯ ರಿಸಾಲ್ವರ್ ಅಪ್ಸ್ಟ್ರೀಮ್ ಪ್ರಶ್ನೆಗಳಿಗೆ ಬಳಸಬಹುದಾದ ಇಂಟರ್ಫೇಸ್ಗಳ ಪಟ್ಟಿ.

ಅಲ್ಲಿ ಸುರಂಗ ಇಂಟರ್ಫೇಸ್ ಅನ್ನು ಹೆಸರಿಸುವುದು, ಮತ್ತು ಅದೇ ಇಂಟರ್ಫೇಸ್ ಮಾತ್ರ, ರೌಟರ್ನ ಸ್ವಂತ ಲುಕಪ್ಗಳು ಸುರಂಗವನ್ನು ಅನುಸರಿಸುವಂತೆ ಮಾಡುತ್ತದೆ. ಡೀಫಾಲ್ಟ್ನಲ್ಲೇ ಬಿಟ್ಟರೆ, ರಿಸಾಲ್ವರ್ ರೂಟಿಂಗ್ ಕೋಷ್ಟಕದಿಂದ ನಿರ್ಗಮನವನ್ನು ಆರಿಸುತ್ತದೆ, ಮತ್ತು ಎರಡು WAN ಅಥವಾ VPN ಇರುವ ಹೋಸ್ಟ್ನಲ್ಲಿ ಅದು ಹೆಚ್ಚಾಗಿ WAN ಆಗಿರುತ್ತದೆ.

ಇತರ ಫರ್ಮ್ವೇರ್ಗಳು ಅದೇ ನಿರ್ಧಾರವನ್ನು ಬೇರೆ ಲೇಬಲ್ ಅಡಿಯಲ್ಲಿ ತೋರಿಸುತ್ತವೆ: ಮೂಲ ವಿಳಾಸಕ್ಕೆ ಬದ್ಧವಾದ ಅಪ್ಸ್ಟ್ರೀಮ್ ಸರ್ವರ್ ಪಟ್ಟಿ, ಕೇವಲ-ಫಾರ್ವರ್ಡಿಂಗ್ ಮೋಡ್, ಅಥವಾ ದಾಖಲಿತ ಮಾರ್ಗ ನೀತಿ. ಹುಡುಕಬೇಕಾದ ಸೆಟ್ಟಿಂಗ್ ಯಾವಾಗಲೂ ಸ್ಥಳೀಯವಾಗಿ ರಚಿಸಿದ ಪ್ರಶ್ನೆಗಳಿಗೆ ನಿರ್ಗಮನ ಅಥವಾ ಮೂಲವನ್ನು ಆರಿಸುವುದೇ ಆಗಿದೆ. ರಿಸಾಲ್ವರ್ ಸಂರಚನೆಯ ಉಲ್ಲೇಖ pfSense ಗಾಗಿ ಆ ಆಯ್ಕೆಯನ್ನು ದಾಖಲಿಸುತ್ತದೆ ಮತ್ತು ಬದಲಾವಣೆಗೆ ಮೊದಲು ಓದಲು ಯೋಗ್ಯವಾಗಿದೆ.

ಸೆಟ್ಟಿಂಗ್ಗಿಂತ ಮೊದಲು ವೈಫಲ್ಯದ ವರ್ತನೆಯನ್ನು ಆರಿಸಿ

ಸುರಂಗ ಬಿದ್ದಾಗ ಎರಡು ವರ್ತನೆಗಳು ಸಮರ್ಥನೀಯ: ಏನೂ ಸೋರಿಕೆಯಾಗದಂತೆ ಅಪ್ಸ್ಟ್ರೀಮ್ ಪ್ರಶ್ನೆಗಳನ್ನು ನಿಲ್ಲಿಸುವುದು, ಅಥವಾ ತಿಳಿದ ಮಾರ್ಗದಲ್ಲಿ ಅನುಮೋದಿತ ರಿಸಾಲ್ವರ್ಗೆ ಮರಳುವುದು. ಎರಡೂ ನೀತಿಗಳು, ಮತ್ತು ಡೀಫಾಲ್ಟ್ನಲ್ಲಿ ಯಾವುದೂ ಸಿಗುವುದಿಲ್ಲ. ಇಂಟರ್ಫೇಸ್ ಪಟ್ಟಿಯನ್ನು ಮುಟ್ಟುವ ಮೊದಲು ನೆಟ್ವರ್ಕ್ಗೆ ಯಾವುದು ಬೇಕು ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸಿ.

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

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

ಎರಡೂ ಮಾರ್ಗಗಳನ್ನು ಪರೀಕ್ಷಿಸಿ ಮತ್ತು ಫಲಿತಾಂಶಗಳನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಇಡಿ

ಬ್ರೌಸರ್-ಆಧಾರಿತ DNS ಪರೀಕ್ಷೆ ಸಣ್ಣ ಪ್ರಶ್ನೆಗೆ ಉತ್ತರಿಸುತ್ತದೆ: ಆ ಪರೀಕ್ಷೆಯ ಪರಿಸ್ಥಿತಿಗಳಲ್ಲಿ ಆ ಬ್ರೌಸರ್ ಯಾವ ರಿಸಾಲ್ವರ್ಗಳನ್ನು ಬಳಸಿತು. ಅದು ನೆಟ್ವರ್ಕ್ನ ಸಾಧನಗಳನ್ನು ಪಟ್ಟಿ ಮಾಡುವುದಿಲ್ಲ ಮತ್ತು ರೌಟರ್ ತನಗಾಗಿ ರಚಿಸಿದ ಪ್ರಶ್ನೆಯನ್ನು ನೋಡಲಾರದು. ಅದರ ಔಟ್ಪುಟ್ ಅನ್ನು ಆಡಿಟ್ ಅಲ್ಲ, ಒಂದು ಡೇಟಾ ಬಿಂದುವಾಗಿ ಪರಿಗಣಿಸಿ.

LAN ಕ್ಲೈಂಟ್ನಿಂದ ರೌಟರ್ನಲ್ಲಿ ಮೊದಲು ಸಾರ್ವಜನಿಕ ಹೆಸರು, ನಂತರ ನಿಮ್ಮ ಆಂತರಿಕ ವಲಯ ಮಾತ್ರ ಉತ್ತರಿಸಬೇಕಾದ ಖಾಸಗಿ ಹೆಸರು ಕೇಳಿ. ಕೇವಲ ಎರಡನೇ ಪ್ರಶ್ನೆಯಲ್ಲಿ ವೈಫಲ್ಯವು ಸುರಂಗವಲ್ಲ, ಹೆಸರು ಫಾರ್ವರ್ಡಿಂಗ್ ಅನ್ನು ಸೂಚಿಸುತ್ತದೆ:

dig @192.168.1.1 example.com
dig @192.168.1.1 intranet.example.lan

ನಂತರ ಸುರಂಗವನ್ನು ಇಳಿಸಿ ಎರಡೂ ಪ್ರಶ್ನೆಗಳನ್ನು ಪುನರಾವರ್ತಿಸಿ. ನಿರಾಕರಿಸಿದ ಉತ್ತರಗಳೆಂದರೆ ರಿಸಾಲ್ವರ್ ವೈಫಲ್ಯದಲ್ಲಿ ಮುಚ್ಚುತ್ತದೆ; ಯಶಸ್ವಿ ಉತ್ತರವು ಮರುಸ್ಥಾಪನೆ ರಿಸಾಲ್ವರ್ ಮತ್ತು ಅದು ಬಳಸಿದ ಮಾರ್ಗವನ್ನು ಸೂಚಿಸುತ್ತದೆ. ಅದನ್ನು ನೀವು ಬರೆದ ಟಿಪ್ಪಣಿ ಮತ್ತು ಅದೇ ನಿಮಿಷದಲ್ಲಿ WAN ಇಂಟರ್ಫೇಸ್ನಲ್ಲಿ ತೆಗೆದ ಸೆರೆಹಿಡಿಯುವಿಕೆಯೊಂದಿಗೆ ಹೋಲಿಸಿ.

ದಾಖಲೆಯಲ್ಲಿ ವೀಕ್ಷಣೆಗಳನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಇಡಿ: ಕ್ಲೈಂಟ್-ರೌಟರ್ ವಿನಿಮಯ, ರೌಟರ್-ಅಪ್ಸ್ಟ್ರೀಮ್ ವಿನಿಮಯ, ಮತ್ತು ಎರಡನೆಯದನ್ನು ನಿರ್ಧರಿಸಿದ ಸಂರಚನೆ. ನಂತರದ ರೂಟಿಂಗ್ ಬದಲಾವಣೆ ಆ ಎರಡನೇ ವಿನಿಮಯವನ್ನು ಎಚ್ಚರಿಕೆ ಇಲ್ಲದೆ ಚಾಲನೆ ಮಾಡುತ್ತದೆ. VPN ಎಂಡ್ಪಾಯಿಂಟ್ ಹೊರತುಪಡಿಸಿ ಬೇರೆಡೆಯಿಂದ ಬರುವ ಉತ್ತರ ಸ್ವತಃ ಸೋರಿಕೆ ಅಲ್ಲ; ಸಂರಚನೆ ಆ ಮಾರ್ಗವನ್ನು ಆಕಸ್ಮಿಕವಾಗಿ ಆರಿಸಿದಾಗ ಮಾತ್ರ ಅದು ಸೋರಿಕೆಯಾಗುತ್ತದೆ.

ಸಂಬಂಧಿತ ಲೇಖನಗಳು