ಡೌನ್ಸ್ಟ್ರೀಮ್ ಸಬ್ನೆಟ್ vs ಡೆಸ್ಕ್ಟಾಪ್ VPN: ಟ್ರಾನ್ಸಿಟ್ ಹೊರಗಿಡಿ, ಅಪ್ಲಿಕೇಶನ್ಗಳಲ್ಲ
ಪ್ರತಿ-ಅಪ್ಲಿಕೇಶನ್ ಬೈಪಾಸ್ ಸ್ಥಳೀಯ ಔಟ್ಪುಟ್ ಅನ್ನು ಮಾತ್ರ ವರ್ಗೀಕರಿಸುತ್ತದೆ. ವರ್ಕ್ಸ್ಟೇಷನ್ ಹಿಂದಿನ ಸಾಧನಗಳಿಗೆ ತಮ್ಮದೇ ಇನ್ಗ್ರೆಸ್, ಫಾರ್ವರ್ಡಿಂಗ್ ಮತ್ತು ರಿಟರ್ನ್-ಪಾತ್ ನೀತಿ ಬೇಕು.
ಒಂದು ಯಂತ್ರ, ಎರಡು ಕೆಲಸ, ಒಂದು ಫೈರ್ವಾಲ್: ಒಂದು Wi-Fi ಅಪ್ಲಿಂಕ್, ಅದರ ಹಿಂದೆ ಸಣ್ಣ Ethernet ಸಬ್ನೆಟ್, ಮತ್ತು ಯಂತ್ರದಿಂದ ಹೊರಹೋಗುವ ಎಲ್ಲವೂ ಸ್ಥಳೀಯ ಎಂದು ಭಾವಿಸುವ ಡೆಸ್ಕ್ಟಾಪ್ VPN ಕ್ಲೈಂಟ್. ಸ್ಥಳೀಯವಾಗಿ ಪ್ರಾರಂಭಿಸಿದ ಅಪ್ಲಿಕೇಶನ್ಗಳು ಸ್ಥಳೀಯ ಔಟ್ಪುಟ್ ಮಾರ್ಗದ ಮೂಲಕ ಹೊರಹೋಗುತ್ತವೆ. ವರ್ಕ್ಸ್ಟೇಷನ್ ಹಿಂದಿನ ಸಾಧನಗಳು Ethernet ಪೋರ್ಟ್ಗೆ ಬರುತ್ತವೆ ಮತ್ತು ಫಾರ್ವರ್ಡಿಂಗ್ ನಿರ್ಣಯ ಬೇಕಾಗುತ್ತದೆ. ಮೊದಲ ಮಾರ್ಗಕ್ಕಾಗಿ ಬರೆದ ಹೊರತುಪಡಿಸುವಿಕೆ ಎರಡನೆಯದನ್ನು ಎಂದಿಗೂ ನೋಡುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಬ್ರೌಸರ್ ಟನೆಲ್ ಅನ್ನು ತಪ್ಪಿಸುತ್ತದೆ, ಸಾಧನಗಳು ತಪ್ಪಿಸುವುದಿಲ್ಲ.
ಎರಡು ಪ್ಯಾಕೆಟ್ ಮಾರ್ಗ, ಒಂದು ನೀತಿ
| Origin | Path | Decision owner |
|---|---|---|
| Application on the workstation | OUTPUT then egress | The VPN app's routing policy |
| Device behind the workstation | PREROUTING then FORWARD | The workstation's own forwarding policy |
ಮೊದಲ ಸಾಲು ಹೆಚ್ಚಿನ split-tunneling ಮಾರ್ಗದರ್ಶಿಗಳು ವಿವರಿಸುವುದು. ಎರಡನೆಯದು ಅದೇ ಯಂತ್ರದಲ್ಲಿ ಆಕಸ್ಮಿಕವಾಗಿ ಇರುವ ರೌಟರ್ ಸಂರಚನೆ. ಎರಡನ್ನೂ ಒಂದೇ ಮಾನಸಿಕ ಮಾದರಿಯಲ್ಲಿ ಕರಗಿಸುವುದೇ ತಪ್ಪು; ಅವು ಕರ್ನಲ್ ಅನ್ನು ಹಂಚಿಕೊಳ್ಳುತ್ತವೆ, ನೀತಿಯನ್ನಲ್ಲ. ಯಾವುದೇ ನಿಯಮ ಸಂಪಾದಿಸುವ ಮೊದಲು ಎರಡೂ ಮಾರ್ಗಗಳನ್ನು ಬರೆಯಿರಿ, ಉಳಿದ ವಿನ್ಯಾಸ ಯಾವ ಮಾರ್ಗ ಕಾಣೆಯಾಗಿದೆ ಎಂಬುದರಿಂದ ಬರುತ್ತದೆ.
ಒಂದು ಯಂತ್ರ ಒಂದು ಪರೀಕ್ಷೆಯಲ್ಲಿ ಉತ್ತೀರ್ಣವಾಗಿ ಇನ್ನೊಂದರಲ್ಲಿ ವಿಫಲವಾಗುವುದು ಏಕೆ ಎಂದು ಕೋಷ್ಟಕ ವಿವರಿಸುತ್ತದೆ. ವರ್ಕ್ಸ್ಟೇಷನ್ನಲ್ಲಿನ ಬ್ರೌಸರ್ ಸ್ಥಳೀಯ ಮಾರ್ಗವನ್ನು ಸಾಬೀತುಪಡಿಸುತ್ತದೆ; Ethernet ಪೋರ್ಟ್ಗೆ ಸೇರಿಸಿದ ಲ್ಯಾಪ್ಟಾಪ್ ಫಾರ್ವರ್ಡಿಂಗ್ ಮಾರ್ಗವನ್ನು ಸಾಬೀತುಪಡಿಸುತ್ತದೆ. ಪ್ರತಿ ಬದಲಾವಣೆಯನ್ನು ಎರಡರಿಂದಲೂ ಪರಿಶೀಲಿಸಿ, ಇಲ್ಲದಿದ್ದರೆ ಬ್ರೌಸರ್ ಎಷ್ಟೇ ಬಾರಿ ರಿಫ್ರೆಶ್ ಆದರೂ ಎರಡನೆಯದು ಪರೀಕ್ಷಿಸದೆ ಉಳಿಯುತ್ತದೆ.
ಅಪ್ಲಿಕೇಶನ್ ಹೊರತುಪಡಿಸುವಿಕೆ ನಿಜವಾಗಿ ಏನನ್ನು ವರ್ಗೀಕರಿಸುತ್ತದೆ
ಪ್ರತಿ-ಅಪ್ಲಿಕೇಶನ್ ಹೊರತುಪಡಿಸುವಿಕೆ ಸಾಮಾನ್ಯವಾಗಿ ಹೀಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ: ಪ್ರಕ್ರಿಯೆ ಅಥವಾ ಬಳಕೆದಾರರ ಪ್ಯಾಕೆಟ್ಗಳನ್ನು ಗುರುತಿಸಿ, ನಂತರ ಗುರುತಿಸಿದ ಟ್ರಾಫಿಕ್ ಅನ್ನು ಟನೆಲ್ನ ಹೊರಗೆ ರೂಟ್ ಮಾಡುತ್ತದೆ. ಇದು ಸ್ಥಳೀಯ-ಔಟ್ಪುಟ್ ರಚನೆ. ಡೌನ್ಸ್ಟ್ರೀಮ್ ಸಾಧನದ ಪ್ಯಾಕೆಟ್ಗೆ ಸ್ಥಳೀಯ ಪ್ರಕ್ರಿಯೆ ಇಲ್ಲ, ಆದ್ದರಿಂದ ಅದು ಸೆಲೆಕ್ಟರ್ ಜೊತೆ ಎಂದಿಗೂ ಹೊಂದಿಕೆಯಾಗುವುದಿಲ್ಲ, ಸೆಲೆಕ್ಟರ್ ಏನೇ ಇರಲಿ.
ಸೆಲೆಕ್ಟರ್ ಏನೇ ಇರಲಿ, ಎರಡು ಪಟ್ಟಿಗಳು ಒಂದೇ ಪಟ್ಟಿಯಲ್ಲ, ಮತ್ತು ಅದೇ ಮುಖ್ಯ ಅಂಶ. Mullvadನ Linux ಮಾರ್ಗದರ್ಶಿ ಅದರ ಫೈರ್ವಾಲ್ ಮತ್ತು ರೂಟಿಂಗ್ ನೀತಿ ಬಳಸುವ ಗುರುತುಗಳನ್ನು ವಿವರಿಸುತ್ತದೆ, ಮತ್ತು ಅದರ ಉದಾಹರಣೆಗಳು ಸ್ಥಳೀಯ ಔಟ್ಪುಟ್ ಗುರಿಯಾಗಿವೆ; ಅವು ಡೌನ್ಸ್ಟ್ರೀಮ್ ರೌಟರ್ನ ಬೆಂಬಲಿತ ವಿವರಣೆಯಲ್ಲ. ಅವನ್ನು ನಕಲಿಸಿದರೆ ಎಲ್ಲವನ್ನೂ ಟನೆಲ್ಗೆ ಫಾರ್ವರ್ಡ್ ಮಾಡುತ್ತಲೇ ಹೊರತುಪಡಿಸುವಿಕೆ ಇದೆ ಎಂದು ನಂಬುವ ಯಂತ್ರ ಸಿಗುತ್ತದೆ.
ಟ್ರಾನ್ಸಿಟ್ ಒಪ್ಪಂದ ಬರೆಯಿರಿ
ಡೌನ್ಸ್ಟ್ರೀಮ್ ಮೂಲ ಪ್ರಿಫಿಕ್ಸ್ ಮತ್ತು ಇನ್ಗ್ರೆಸ್ ಇಂಟರ್ಫೇಸ್ ಅನ್ನು ಜೊತೆಯಾಗಿ ಹೆಸರಿಸಿ, ನಂತರ ಆ ಪ್ರಿಫಿಕ್ಸ್ ಅನ್ನು ಇನ್ಗ್ರೆಸ್ನಲ್ಲಿ ಸೀಮಿತಗೊಳಿಸಿ. ಸೀಮೆಯಿಲ್ಲದೆ, ಪೋರ್ಟ್ ತಲುಪುವ ಯಾವುದೇ ಸಾಧನ ಹೊರತುಪಡಿಸಿದ ವಿಳಾಸವನ್ನು ಕ್ಲೇಮ್ ಮಾಡಿ ಬೈಪಾಸ್ ಮೂಲಕ ಹೊರಹೋಗಬಹುದು. ಇದನ್ನು ಎರಡು ಪ್ರಶ್ನೆಗಳಾಗಿ ನೋಡಿ: ಈ ಹೋಸ್ಟ್ಗಳು ಈ ಅಪ್ಲಿಂಕ್ ಬಳಸಬಹುದೇ, ಮತ್ತು ಅವು ವರ್ಕ್ಸ್ಟೇಷನ್ ಅಥವಾ ಟನೆಲ್ನ ಖಾಸಗಿ ಶ್ರೇಣಿಗಳನ್ನು ತಲುಪಬಹುದೇ? ಇವು ಹೆಚ್ಚುವರಿ ಅನುಮತಿಗಳು, ಅಪ್ಲಿಂಕ್ ಆಯ್ಕೆಯ ಅಡ್ಡಪರಿಣಾಮಗಳಲ್ಲ.
ಫಾರ್ವರ್ಡಿಂಗ್ ಅನುಮತಿಸಿ, ನಂತರ ಫಿಲ್ಟರ್ ಮಾಡಿ. Linux ಗೇಟ್ವೇಗೆ ಫಾರ್ವರ್ಡಿಂಗ್ ಸಕ್ರಿಯ, ಎರಡೂ ದಿಕ್ಕಿನಲ್ಲಿ ಉದ್ದೇಶಿತ ಟ್ರಾಫಿಕ್ ಅನುಮತಿಸುವ ನಿಯಮಗಳು, ಮತ್ತು ಅಪ್ಸ್ಟ್ರೀಮ್ ರಿಟರ್ನ್ ರೂಟ್ ಅಥವಾ ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಸೀಮಿತಗೊಳಿಸಿದ ಮೂಲ ಅನುವಾದ ಬೇಕು. NAT ಒಂದೇ ಅಪ್ಲಿಂಕ್ ಆಯ್ಕೆ ಮಾಡುವುದಿಲ್ಲ ಮತ್ತು ಫಿಲ್ಟರ್ ಮೂಲಕ ಹಾದುಹೋಗಲು ಅನುಮತಿಸುವುದಿಲ್ಲ; ಅದು ಆ ನಿರ್ಣಯಗಳ ನಂತರ ವಿಳಾಸವನ್ನು ಮರುಬರೆಯುತ್ತದೆ.
ಟ್ರಾನ್ಸಿಟ್ಗಾಗಿ ವರ್ಗೀಕರಣ ಫಾರ್ವರ್ಡಿಂಗ್ ರೂಟ್ ನಿರ್ಣಯದ ಮೊದಲು ನಡೆಯಬೇಕು, ಅಂದರೆ output ಅಲ್ಲ, prerouting ಹಂತದಲ್ಲಿ. ನಿರ್ಣಯದ ನಂತರ ಇಡುವ ನಿಯಮ ಪ್ಯಾಕೆಟ್ ಬದಲಿಸಬಹುದು, ಆದರೆ ಪ್ಯಾಕೆಟ್ ಈಗಾಗಲೇ ಎಲ್ಲಿಗೆ ಕಳುಹಿಸಲಾಗಿದೆ ಎಂಬುದನ್ನು ಬದಲಿಸಲಾಗದು.
ಗುರುತುಗಳು ಅವನ್ನು ಹೊಂದಿರುವ ಅಪ್ಲಿಕೇಶನ್ಗೆ ಸೇರಿವೆ
ಗುರುತು ಮೌಲ್ಯಗಳು, ಕೋಷ್ಟಕ ಸಂಖ್ಯೆಗಳು ಮತ್ತು ಸರಪಳಿ ಆದ್ಯತೆಗಳು VPN ಅಪ್ಲಿಕೇಶನ್ನ ನೀತಿಯ ಭಾಗ, ಶಾಶ್ವತ ಸ್ಥಿರಾಂಕಗಳಲ್ಲ. ಇನ್ನೊಂದು ಪ್ರೋಗ್ರಾಂ ಮರುಸೃಷ್ಟಿಸುವ ಕೋಷ್ಟಕಕ್ಕೆ ನಿಯಮ ಸೇರಿಸುವುದನ್ನು ಅವಲಂಬಿಸಿರುವ ಜಾಲ ಮುಂದಿನ ನವೀಕರಣದಲ್ಲಿ ಮುರಿಯುತ್ತದೆ, ಸಾಮಾನ್ಯವಾಗಿ ಮರುಸಂಪರ್ಕದ ವೇಳೆ, ಅನುಕೂಲಕರ ಸಮಯದಲ್ಲಿ ಅಲ್ಲ.
accept ತೀರ್ಪಿನೊಂದಿಗೆ ಎರಡನೇ ಮೂಲ ಸರಪಳಿ ಸೇರಿಸುವುದು ನಂತರದ ಸರಪಳಿಯ drop ಅನ್ನು ಕಡ್ಡಾಯವಾಗಿ ಮೀರಿಸುವುದಿಲ್ಲ. ಮೂಲ ಸರಪಳಿಗಳಿಗೆ ಕೊಕ್ಕೆಗಳು ಮತ್ತು ಆದ್ಯತೆಗಳಿವೆ, ಮತ್ತು ಕ್ರಮದಲ್ಲಿ ಮೊದಲ ತೀರ್ಪು ಗೆಲ್ಲುತ್ತದೆ; ಒಂದು ಸರಪಳಿಯ accept ಇನ್ನೊಂದು ಸರಪಳಿ ಮೊದಲು ತಲುಪುವ drop ಅನ್ನು ರದ್ದುಗೊಳಿಸುವುದಿಲ್ಲ. ಹೆಚ್ಚಿದ ಒಂದು ಕೌಂಟರ್ ಅಲ್ಲ, ಪೂರ್ಣ ನಿಯಮ ಸಮೂಹ ಮತ್ತು ರೂಟಿಂಗ್ ನೀತಿಯ ಕ್ರಮ ನೋಡಿ. ಕೌಂಟರ್ ನಿಯಮ ಓಡಿತು ಎಂದು ಸಾಬೀತುಪಡಿಸುತ್ತದೆ, ಅದರ ತೀರ್ಪೇ ಅನ್ವಯವಾಯಿತು ಎಂದು ಎಂದಿಗೂ ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ.
ಸಂಯೋಜಿಸಿ, ಅಥವಾ ಸಬ್ನೆಟ್ ಸರಿಸಿ
ಎರಡು ವಿನ್ಯಾಸಗಳು ಬೈಪಾಸ್ ಯಾರ ಒಡೆತನದಲ್ಲಿ ಇದೆ ಎಂಬುದರಲ್ಲಿ ಭಿನ್ನ. ಸಂಯೋಜಿತ ವಿನ್ಯಾಸ ಒಂದು ಯಂತ್ರ ಮತ್ತು ಒಂದು ನೀತಿಯನ್ನು ಉಳಿಸಿಕೊಳ್ಳುತ್ತದೆ, ಆದರೆ VPN ಅಪ್ಲಿಕೇಶನ್ನ ಕೋಷ್ಟಕ ಜೀವನಚಕ್ರ ಮತ್ತು ಅದರ ದಾಖಲೆಗಳು ಬದಲಿಸಬಹುದಾದ ಗುರುತುಗಳ ಗುಂಪಿನ ಮೇಲಿನ ಅವಲಂಬನೆಯ ಬೆಲೆಗೆ. ಡೌನ್ಸ್ಟ್ರೀಮ್ ಜಾಲಕ್ಕೆ ಮೀಸಲಾದ ರೌಟರ್ ಆ ಅವಲಂಬನೆಯನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ತೆಗೆದುಹಾಕುತ್ತದೆ: ಸಬ್ನೆಟ್ಗೆ ತನ್ನದೇ ಅಪ್ಲಿಂಕ್ ಇರುತ್ತದೆ, ಮತ್ತು ವರ್ಕ್ಸ್ಟೇಷನ್ ಫಾರ್ವರ್ಡಿಂಗ್ ಪಾತ್ರವಿಲ್ಲದ ಕ್ಲೈಂಟ್ ಆಗಿ ಉಳಿಯುತ್ತದೆ.
ಡೌನ್ಸ್ಟ್ರೀಮ್ ಜಾಲವು VPN ನವೀಕರಣಗಳ ನಡುವೆಯೂ ಕೆಲಸ ಮಾಡಬೇಕಿದ್ದರೆ, ಅಥವಾ ಪ್ರತಿ ಬಿಡುಗಡೆಯ ನಂತರ ಸಂಯೋಜಿತ ನೀತಿಯನ್ನು ಯಾರೂ ಪರೀಕ್ಷಿಸಲಾಗದಿದ್ದರೆ ಎರಡನೆಯದನ್ನು ಆರಿಸಿ. ಸಂಯೋಜನೆ ದಾಖಲಾಗಿದ್ದು ಯಾರಾದರೂ ಅದರ ಜವಾಬ್ದಾರಿ ಹೊತ್ತಿದ್ದರೆ ಮಾತ್ರ ಮೊದಲನೆಯದನ್ನು ಆರಿಸಿ.
ನಾಲ್ಕು ಸ್ಥಿತಿಗಳಲ್ಲಿ ಗಡಿಯನ್ನು ಪರಿಶೀಲಿಸಿ: ಸಂಪರ್ಕಿತ, ಮರುಸಂಪರ್ಕವಾಗುತ್ತಿರುವ, ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ನಿರ್ಬಂಧಿತ ಮತ್ತು ನಿಲ್ಲಿಸಲಾದ. ಪ್ರತಿಯೊಂದರಲ್ಲಿ ಹೆಸರು ವಿಭಜನೆ ಮತ್ತು ಎರಡೂ ವಿಳಾಸ ಕುಟುಂಬಗಳನ್ನು ಪರಿಶೀಲಿಸಿ, ಏಕೆಂದರೆ DNS ಸೋರಿಸುವ ಬೈಪಾಸ್ ನೀವು ವಿನ್ಯಾಸ ಮಾಡಿದ ಹೊರತುಪಡಿಸುವಿಕೆ ಅಲ್ಲ. ಪರೀಕ್ಷೆ ನಿಖರವಾದ ಗಡಿಯನ್ನು ಸಾಬೀತುಪಡಿಸಬೇಕು, ಕೇವಲ ಒಂದು ಪುಟ ಲೋಡ್ ಆಯಿತು ಎಂದಲ್ಲ.