ಎರಡು ಕ್ಲೈಂಟ್ ಗುಂಪುಗಳು, ಒಂದು ಸರ್ವರ್: ನೀತಿಯನ್ನು ಎಲ್ಲಿ ಜಾರಿಗೊಳಿಸಬೇಕು
ಸಬ್ನೆಟ್ಗಳು ಗುಂಪುಗಳಿಗೆ ಲೇಬಲ್ ಹಾಕುತ್ತವೆ; ಅವನ್ನು ಪ್ರತ್ಯೇಕಿಸುವುದಿಲ್ಲ. ಯಾವ ಫಾರ್ವರ್ಡಿಂಗ್ ಮಾರ್ಗವು ನಿಯಮದ ಮಾಲೀಕತ್ವ ಹೊಂದಿದೆ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸಿ, ನಂತರ ಅನುಷ್ಠಾನವು ಜಾರಿಗೊಳಿಸಬೇಕಾದ ಮ್ಯಾಟ್ರಿಕ್ಸ್ ಬರೆಯಿರಿ.
ಎರಡು ಕ್ಲೈಂಟ್ ಗುಂಪುಗಳನ್ನು ಬೇರೆ ಬೇರೆ ಸಬ್ನೆಟ್ಗಳಲ್ಲಿ ಇರಿಸುವುದು ಪ್ರತ್ಯೇಕತೆಯಂತೆ ಕಾಣುತ್ತದೆ, ಆದರೆ ಅದು ಹೌದಲ್ಲ. ವಿಳಾಸಗಳು ಪ್ಯಾಕೆಟ್ ಎಲ್ಲಿಂದ ಬಂದಂತೆ ಕಾಣುತ್ತದೆ ಎಂಬುದನ್ನು ವಿವರಿಸುತ್ತವೆ, ಆದರೆ ಅನುಮತಿ ಎಂಬುದು ಅದನ್ನು ಫಾರ್ವರ್ಡ್ ಮಾಡುವವನು ತೆಗೆದುಕೊಳ್ಳುವ ನಿರ್ಧಾರ. ಈ ಪ್ರಶ್ನೆಗೆ ಮಾಸ್ಕ್ ಅಲ್ಲ, ಸಂರಚನೆಯೇ ಉತ್ತರ ನೀಡುತ್ತದೆ, ಆದ್ದರಿಂದ ಯಾವುದೇ ನಿಯಮ ಬರೆಯುವ ಮೊದಲು ಯಾವ ಘಟಕವು ಪೀರ್ ಸಂಚಾರವನ್ನು ಫಾರ್ವರ್ಡ್ ಮಾಡುತ್ತದೆ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸಿ.
ಸಬ್ನೆಟ್ ಒಂದು ಲೇಬಲ್, ನಿಯಮವಲ್ಲ
ಪ್ರತಿ ಗುಂಪಿಗೆ ಒಂದು ಪೂಲ್ ನೀಡುವುದು ನಿಮಗೆ ಓದಲು ಸಾಧ್ಯವಾದ ವಿಳಾಸಗಳನ್ನು ನೀಡುತ್ತದೆ, ಬೇರೆ ಏನೂ ಇಲ್ಲ. ಹೆಚ್ಚುವರಿ ಮಾರ್ಗವನ್ನು ಸ್ವೀಕರಿಸುವ ಕ್ಲೈಂಟ್ ತಲುಪುವಿಕೆಯನ್ನು ಪಡೆದಿದೆ, ಮತ್ತು ತಲುಪುವಿಕೆ ಎಂಬುದು ಅನುಮತಿ ಅಲ್ಲ. ಮಾತನಾಡುವ ಅನುಮತಿ ಫಾರ್ವರ್ಡಿಂಗ್ ನಿರ್ಧಾರದಲ್ಲಿದೆ, ಅದು ಸರ್ವರ್ ಹೇಗೆ ಸಂರಚಿಸಲ್ಪಟ್ಟಿದೆ ಎಂಬುದರ ಆಧಾರದ ಮೇಲೆ ಡೀಮನ್ನಲ್ಲಿ ಅಥವಾ ಕರ್ನಲ್ನಲ್ಲಿ ಇರಬಹುದು.
ವಿಳಾಸದ ಮಾಲೀಕತ್ವವೇ ಪೂರ್ವಪ್ರತ್ಯಯವನ್ನು ಗುಂಪು ಆಯ್ಕೆಗಾರನಾಗಿ ಬಳಸಲು ಸಾಧ್ಯವಾಗಿಸುತ್ತದೆ. ಪ್ರತಿ ದೃಢೀಕೃತ ಗುರುತು ಊಹಿಸಬಹುದಾದ ವಿಳಾಸ ಅಥವಾ ಶ್ರೇಣಿಗೆ ಹೊಂದಿಕೆಯಾಗಬೇಕು, ಮತ್ತು ಹಲವು ಸಾಧನಗಳು ಒಂದೇ ರುಜುವಾತು ಮತ್ತು ಒಂದೇ ಹಂಚಿಕೆಯನ್ನು ಹಂಚಿಕೊಂಡ ಕ್ಷಣ ಆ ಹೊಂದಾಣಿಕೆ ವಿಫಲವಾಗುತ್ತದೆ. ಮೂಲ ಪೂರ್ವಪ್ರತ್ಯಯವನ್ನು ಅವಲಂಬಿಸುವ ಮೊದಲು ಗುರುತು ಮತ್ತು ಸಮಕಾಲೀನತೆಯನ್ನು ಬಗೆಹರಿಸಿ, ಏಕೆಂದರೆ ಯಾವ ಯಂತ್ರ ಕರೆ ಮಾಡುತ್ತಿದೆ ಎಂದು ಊಹಿಸುವ ನೀತಿ ಅತ್ಯಂತ ಕೆಟ್ಟ ಕ್ಷಣದಲ್ಲಿ ತಪ್ಪಾದುದಕ್ಕೆ ಅನುಮತಿ ನೀಡುತ್ತದೆ.
ಪೀರ್ ಸಂಚಾರವನ್ನು ಸಾಗಿಸುವ ಮಾರ್ಗವನ್ನು ಆಯ್ಕೆಮಾಡಿ
ಡೀಮನ್ ತನ್ನ ಪ್ರಕ್ರಿಯೆಯ ಒಳಗೆ ಪೀರ್ ಪ್ಯಾಕೆಟ್ಗಳನ್ನು ಫಾರ್ವರ್ಡ್ ಮಾಡುವಾಗ, ಆ ಪ್ಯಾಕೆಟ್ಗಳು ಹೋಸ್ಟ್ನ ಫಾರ್ವರ್ಡಿಂಗ್ ಕೊಕ್ಕೆಗೆ ಎಂದಿಗೂ ತಲುಪುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಕರ್ನಲ್ ನಿಯಮ ಅವನ್ನು ನೋಡಲಾಗದು. ಆ ಆಂತರಿಕ ಫಾರ್ವರ್ಡಿಂಗ್ ಅನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಿ, ಕರ್ನಲ್ ಫಾರ್ವರ್ಡಿಂಗ್ ಬಿಂದುವಾಗುತ್ತದೆ, ಅಲ್ಲಿ ಸಾಮಾನ್ಯ ಫಾರ್ವರ್ಡ್ ನಿಯಮಗಳು ಅನ್ವಯಿಸುತ್ತವೆ.
# peer forwarding inside the daemon: enforce with per-group policy instead of FORWARD rules
client-to-client
# kernel forwarding path: remove the line above, then filter in the forward chain
ಆಫ್ಲೋಡ್ ಆದ ಡೇಟಾ ಚಾನೆಲ್ಗಳು ಮತ್ತು ಉತ್ಪನ್ನ-ನಿರ್ವಹಿತ ಸರ್ವರ್ಗಳು ತಮ್ಮದೇ ಜಾರಿಗೊಳಿಸುವ ಮಾದರಿಗಳನ್ನು ಪ್ರಕಟಿಸುತ್ತವೆ, ಆದ್ದರಿಂದ ಸಮುದಾಯದ ವರ್ತನೆಯನ್ನು ಊಹಿಸುವ ಬದಲು ನೀವು ಯಾವುದನ್ನು ಚಲಾಯಿಸುತ್ತಿದ್ದೀರಿ ಎಂದು ದೃಢೀಕರಿಸಿ. ತಪ್ಪಿಸಲು ಯೋಗ್ಯವಾದ ವೈಫಲ್ಯ ಎಂದರೆ ಪರಿಶೀಲನೆಯಲ್ಲಿ ಸರಿ ಕಾಣುವ ಮತ್ತು ರನ್ಟೈಮ್ನಲ್ಲಿ ಎಂದಿಗೂ ಪ್ರಶ್ನಿಸದ ನಿಯಮ.
ನಿಯಮಗಳನ್ನು ಬರೆಯುವ ಮೊದಲು ಮ್ಯಾಟ್ರಿಕ್ಸ್ ಬರೆಯಿರಿ
ಸಣ್ಣ ಮ್ಯಾಟ್ರಿಕ್ಸ್ ನಿಯಮಗಳ ಗುಂಪಿಗಿಂತ ಪರಿಶೀಲಿಸಲು ಸುಲಭ, ಮತ್ತು ಅದು ಅನುಷ್ಠಾನ ಪೂರೈಸಬೇಕಾದ ಒಪ್ಪಂದ: ಒಂದೇ ಗುಂಪಿನ ಪೀರ್ಗಳಿಗೆ ಅನುಮತಿ, ಗುಂಪುಗಳ ನಡುವಿನ ಪೀರ್ಗಳಿಗೆ ನಿಷೇಧ, ಎರಡೂ ಗುಂಪುಗಳಿಗೆ ಒಂದು ಹೆಸರಿನ ಹಂಚಿದ ಸೇವೆಗೆ ಅನುಮತಿ, ಉಳಿದೆಲ್ಲದಕ್ಕೆ ನಿಷೇಧ. ಫೈರ್ವಾಲ್ ಸಂಪಾದಕ ತೆರೆಯುವ ಮೊದಲು ಆ ನಾಲ್ಕು ಸಾಲುಗಳನ್ನು ಬರೆಯಿರಿ. ನಿಯಮಗಳ ವಾಕ್ಯರಚನೆ ಓದದ ಪರಿಶೀಲಕರೂ ಮ್ಯಾಟ್ರಿಕ್ಸ್ ಪರಿಶೀಲಿಸಬಹುದು. ನಂತರ ಅನುಷ್ಠಾನ ಕೇವಲ ಸಾಲುಗಳಿಗೆ ಹೊಂದಿಕೆಯಾದರೆ ಸಾಕು.
| Source | Destination | Decision |
|---|---|---|
| Group A address | Another Group A address | Allow |
| Group A address | A Group B address | Deny |
| Either group | The shared internal service | Allow |
| Either group | Anything not listed | Deny |
ಬರೆಯುವಾಗ ಮೂರು ಗಮ್ಯಸ್ಥಾನ ವರ್ಗಗಳನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಇರಿಸಿ. VPN ಹೋಸ್ಟ್ನಲ್ಲಿನ ಸೇವೆ ಸ್ಥಳೀಯ ಇನ್ಪುಟ್, ಇನ್ನೊಂದು ಕ್ಲೈಂಟ್ ಪೀರ್ ಟ್ರಾನ್ಸಿಟ್, ಮತ್ತು ಗೇಟ್ವೇ ಹಿಂದಿನ ಯಂತ್ರ ಬೇರೆ ಫಾರ್ವರ್ಡಿಂಗ್ ಮಾರ್ಗ. ಒಂದು ಉದಾರ ನಿಯಮ ಆಕಸ್ಮಿಕವಾಗಿ ಮೂರನ್ನೂ ನೀಡಬಹುದು, ಮತ್ತು ಹೀಗೆ ಗುಂಪು ನೀತಿ ಹೆಚ್ಚುವರಿ ಹಂತಗಳೊಂದಿಗೆ ಸಮತಟ್ಟಾದ ಜಾಲವಾಗುತ್ತದೆ. ಪ್ರತಿ ಸಾಲಿನ ಪಕ್ಕದಲ್ಲಿ ವರ್ಗವನ್ನು ಬರೆಯಿರಿ, ಆಶಯ ಮುಂದಿನ ಸಂಪಾದನೆಯವರೆಗೂ ಉಳಿಯಲಿ.
ನಿಯಮಗಳು ಉಳಿಯುವ ಸ್ಥಳದಲ್ಲಿ ಅವನ್ನು ಇರಿಸಿ
ಫೈರ್ವಾಲ್ನ ಉಳಿದ ಭಾಗವನ್ನು ನಿರ್ವಹಿಸುವ ಅದೇ ಸ್ಥಳದಲ್ಲಿ ನಿರ್ಣಯಗಳನ್ನು ಸೇರಿಸಿ, ಅವನ್ನು ನುಂಗುವ ಯಾವುದೇ ಅನುಮತಿ ನಿಯಮಕ್ಕಿಂತ ಮೊದಲು. ನಿಯಮಗಳ ಕ್ರಮ ನೀತಿಯ ಭಾಗ, ಮತ್ತು ವಿಶಾಲ ಅನುಮೋದನೆಯ ನಂತರ ಇರಿಸಿದ ಸರಿಯಾದ ನಿಯಮ ಏನನ್ನೂ ಜಾರಿಗೊಳಿಸುವುದಿಲ್ಲ. ಬದಲಾವಣೆಗೆ ಮೊದಲು ಮತ್ತು ನಂತರ ನಿಯಮ ಸಂಖ್ಯೆಗಳನ್ನು ಗಮನಿಸಿ. ಸಂಪಾದಕದಲ್ಲಿದ್ದು ಚಾಲಿತ ನಿಯಮಗಳ ಗುಂಪಿನಲ್ಲಿಲ್ಲದ ನೀತಿ ಯೋಜನೆ, ನಿಯಂತ್ರಣವಲ್ಲ.
ನೀತಿ ಬದಲಾದಾಗ ಈಗಾಗಲೇ ಇರುವ ಹರಿವುಗಳಿಗೆ ಏನಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸಿ, ಏಕೆಂದರೆ ಬದಲಾವಣೆಗೆ ಮೊದಲು ತೆರೆದ ಅವಧಿ ನಂತರವೂ ಮುಂದುವರಿಯಬಹುದು. ನಿರ್ಗಮಿಸುವ ಸದಸ್ಯನು ತಕ್ಷಣ ಪ್ರವೇಶ ಕಳೆದುಕೊಳ್ಳಬೇಕಿದ್ದರೆ, ಸಂಪರ್ಕ ತಾನೇ ಮುಚ್ಚುವವರೆಗೆ ಕಾಯುವ ಬದಲು ಆ ಸ್ಥಿತಿಯನ್ನು ಕೊನೆಗೊಳಿಸುವ ದಾರಿ ನಿಯಮಗಳ ಗುಂಪಿಗೆ ಬೇಕು.
ಫೈರ್ವಾಲ್ನ ಉಳಿದ ಭಾಗವನ್ನು ಹೊಂದಿರುವ ಕಾರ್ಯವಿಧಾನದ ಮೂಲಕ ನಿಯಮಗಳನ್ನು ಶಾಶ್ವತಗೊಳಿಸಿ, ಮತ್ತು ಅವುಗಳ ಪಕ್ಕದಲ್ಲಿ ಮ್ಯಾಟ್ರಿಕ್ಸ್ ದಾಖಲಿಸಿ. ದಾಖಲಿಸದ ನೀತಿ ಮುಂದಿನ ಘಟನೆಯ ಸಮಯದಲ್ಲಿ ಸ್ಮರಣೆಯಿಂದ ಮತ್ತೆ ಪಡೆಯಲ್ಪಡುತ್ತದೆ, ಸಾಮಾನ್ಯವಾಗಿ ಆತುರದಲ್ಲಿರುವವರಿಂದ.
ಎರಡೂ ಕಡೆಗಳಿಂದ ಸಾಬೀತುಪಡಿಸಿ
ಪ್ರತಿ ಗುಂಪಿನ ಒಂದು ಕ್ಲೈಂಟ್ನಿಂದ ಒಂದೇ ಗುಂಪಿನ ತಲುಪುವಿಕೆ, ಗುಂಪುಗಳ ನಡುವಿನ ವೈಫಲ್ಯ ಮತ್ತು ಹಂಚಿದ ಸೇವೆಯನ್ನು ಪರೀಕ್ಷಿಸಿ. ಒಂದು ಕ್ಲೈಂಟ್ನಿಂದ ಒಂದೇ ಪರೀಕ್ಷೆ ಮ್ಯಾಟ್ರಿಕ್ಸ್ನ ಅರ್ಧವನ್ನು ಸಾಬೀತುಪಡಿಸುತ್ತದೆ, ಮತ್ತು ಬಿಟ್ಟ ಅರ್ಧ ಸಾಮಾನ್ಯವಾಗಿ ತಪ್ಪಾದದ್ದು. ನಿರಾಕರಣೆಯ ದಿಕ್ಕನ್ನು ಎರಡು ಬಾರಿ ಪುನರಾವರ್ತಿಸಿ, ಏಕೆಂದರೆ ಕ್ಯಾಶ್ ಆದ ಅವಧಿ ಜಾರಿಯ ದೋಷವನ್ನು ಮರೆಮಾಡಬಹುದು. ನೀವು ಯಾವ ಜೋಡಿಯನ್ನು ಪರೀಕ್ಷಿಸಿದಿರಿ ಎಂದು ದಾಖಲಿಸಿ, ಮುಂದಿನ ವ್ಯಕ್ತಿ ಅದನ್ನು ಪುನರಾವರ್ತಿಸದಿರಲಿ.
ಸುರಂಗ IPv6 ಸಾಗಿಸಿದರೆ ಅದರ ಮೇಲೆ ಪರಿಶೀಲನೆಯನ್ನು ಪುನರಾವರ್ತಿಸಿ, ಮತ್ತು ಸಾಮಾನ್ಯ ಅಪ್ಲಿಕೇಶನ್ ದೃಢೀಕರಣವನ್ನು ಇರಿಸಿ. ಮೂಲ ಪೂರ್ವಪ್ರತ್ಯಯ ಖಾತೆ ಅಲ್ಲ, ಆದ್ದರಿಂದ ಜಾಲ ನೀತಿಯನ್ನು ದಾಟುವುದು ಸೇವೆ ಕರೆ ಮಾಡುವವರನ್ನು ನಂಬಬೇಕು ಎಂಬ ಅರ್ಥವಲ್ಲ.