ಫೋನ್ನ Wi-Fi Calling ಮುರಿಯದೆ IPsec ಬ್ಲಾಕ್ ಮಾಡುವುದು
ಆರು ಪರಿಶೀಲನೆಗಳು ಸಾಮಾನ್ಯ ಪ್ರೋಟೋಕಾಲ್ ಬ್ಲಾಕ್ ಅನ್ನು ನೀವು ಸಮರ್ಥಿಸಬಹುದಾದ ಸೇವಾ-ವಿನಾಯಿತಿಯಾಗಿ ಬದಲಾಯಿಸುತ್ತವೆ: ವೈಶಿಷ್ಟ್ಯ, ಮೂಲ, ಗಮ್ಯಸ್ಥಾನಗಳು, ಮಿತಿ ಮತ್ತು ಪರಿಶೀಲನಾ ದಿನಾಂಕ.
ವಿನಂತಿ ಯಾವಾಗಲೂ ಒಂದೇ ರೂಪದಲ್ಲಿ ಬರುತ್ತದೆ: ತುದಿಯಲ್ಲಿ IPsec ಮುಚ್ಚಿ ಏಕೆಂದರೆ ಅದು ಯಾರೂ ಅನುಮೋದಿಸದ ಸುರಂಗಗಳನ್ನು ಸಾಗಿಸುತ್ತದೆ, ಮತ್ತು ಮೊದಲ ದೂರು ತನ್ನ ಫೋನ್ Wi-Fi ಮೂಲಕ ಕರೆ ಮಾಡುವುದನ್ನು ನಿಲ್ಲಿಸಿದ ವ್ಯಕ್ತಿಯಿಂದ ಬರುತ್ತದೆ. ಎರಡೂ ಸತ್ಯಗಳು ಒಂದೇ ಸಮಯದಲ್ಲಿ ನಿಜ, ಮತ್ತು ಯಾವುದೂ ನಿಯಂತ್ರಣವನ್ನು ಬಿಡಲು ಸಮರ್ಥನೆ ನೀಡುವುದಿಲ್ಲ. ಫೈರ್ವಾಲ್ಗೆ ಹೆಸರಿಸಿದ ವೈಶಿಷ್ಟ್ಯ, ಮಿತವಾದ ಮೂಲ, ದಾಖಲಿತ ಗಮ್ಯಸ್ಥಾನಗಳು ಮತ್ತು ಮಾಲೀಕರನ್ನು ಹೊಂದಿರುವ ಸೇವಾ-ವಿನಾಯಿತಿ ಬೇಕು. ಐದು ಹಂತಗಳು ಅದನ್ನು ಮುಂದಿನ ವರ್ಷ ಅಪರಿಚಿತ ವ್ಯಕ್ತಿ ಪರಿಶೀಲಿಸಬಹುದಾದ ನಿಯಮವಾಗಿ ಬದಲಾಯಿಸುತ್ತವೆ.
ಪ್ರೋಟೋಕಾಲ್ಗೆ ಹೆಸರಿಡುವ ಮೊದಲು ಸೇವೆಗೆ ಹೆಸರಿಡಿ
SIP ಸೇವೆಯಲ್ಲಿನ ಡೆಸ್ಕ್ ಫೋನ್ ಮತ್ತು ವಾಹಕದ Wi-Fi Calling ಮಾಡುವ ಹ್ಯಾಂಡ್ಸೆಟ್ ಒಂದೇ ನೆಟ್ವರ್ಕ್ ಪ್ರೊಫೈಲ್ ಹಂಚಿಕೊಳ್ಳುವುದಿಲ್ಲ, ಮತ್ತು ಫೈರ್ವಾಲ್ ಪದವಾಗಿ VoIP ಅವುಗಳಲ್ಲಿ ಯಾವುದನ್ನೂ ವಿವರಿಸುವುದಿಲ್ಲ. ಪೋರ್ಟ್ ಮತ್ತು ಗಮ್ಯಸ್ಥಾನದ ಮಾಹಿತಿ ಸೇವೆಯನ್ನು ನಡೆಸುವ ಮಾರಾಟಗಾರ ಅಥವಾ ವಾಹಕದಿಂದ ಬರಬೇಕು, ಬೇರೆ ಫೋನ್ ವ್ಯವಸ್ಥೆಗೆ ಸೇರಿದ ನೆನಪಿನ ಪೋರ್ಟ್ ಪಟ್ಟಿಯಿಂದ ಅಲ್ಲ. ಇದು ವೈಶಿಷ್ಟ್ಯವನ್ನು ರಕ್ಷಿಸುವ ನಿಯಮ ಮತ್ತು ಪದವನ್ನು ರಕ್ಷಿಸುವ ನಿಯಮದ ನಡುವಿನ ವ್ಯತ್ಯಾಸ.
Apple ನ ಸೇವಾ-ಪೋರ್ಟ್ ಉಲ್ಲೇಖ Wi-Fi Calling ಗಾಗಿ UDP 500 ಮತ್ತು 4500 ಪಟ್ಟಿ ಮಾಡುತ್ತದೆ, ಇದು ಹೆಚ್ಚಿನ ಸಾಮಾನ್ಯ IPsec ಬ್ಲಾಕ್ಗಳು ಬಿಟ್ಟುಬಿಡುವ ನಿಖರ ಜೋಡಿ. ಆ ಪೋರ್ಟ್ಗಳ ಪಕ್ಕದಲ್ಲಿ ಬದಲಾವಣೆ ದಾಖಲೆಯಲ್ಲಿ ವೈಶಿಷ್ಟ್ಯದ ಹೆಸರು ಬರೆಯಿರಿ. ನೀವು ಬಳಸಿದ ಉಲ್ಲೇಖದ ಆವೃತ್ತಿ ಅಥವಾ ದಿನಾಂಕ ಸೇರಿಸಿ, ಏಕೆಂದರೆ ಮಾರಾಟಗಾರರ ಕೋಷ್ಟಕಗಳು ಸಂಪಾದನೆಯಾಗುತ್ತವೆ. ತಾನು ಇರುವ ಸೇವೆಯನ್ನು ಹೆಸರಿಸುವ ನಿಯಮವನ್ನು ಪರಿಶೀಲಿಸಬಹುದು; ಪ್ರೋಟೋಕಾಲ್ ವರ್ಗವನ್ನು ಹೆಸರಿಸುವುದನ್ನು ಸಾಧ್ಯವಿಲ್ಲ.
ವಿನಾಯಿತಿಯನ್ನು ಉಪಕಾರವಲ್ಲ, ಒಪ್ಪಂದವಾಗಿ ಬರೆಯಿರಿ
ವಿನಾಯಿತಿ ಅನುಮತಿಸಿದ ವೈಶಿಷ್ಟ್ಯ, ಅದನ್ನು ಬಳಸುವ ಸಾಧನ ವರ್ಗಗಳು, ಅಗತ್ಯವಿರುವ ಸಾಗಣೆ ಮತ್ತು ಜವಾಬ್ದಾರ ಪಕ್ಷ ದಾಖಲಿಸುವ ಗಮ್ಯಸ್ಥಾನಗಳನ್ನು ತಿಳಿಸುತ್ತದೆ. ಅದರಲ್ಲಿ ಮಾಲೀಕ ಮತ್ತು ಪರಿಶೀಲನಾ ದಿನಾಂಕವೂ ಇರುತ್ತದೆ, ಏಕೆಂದರೆ ವಾಹಕದ ಅಂತ್ಯಬಿಂದುಗಳು ಮತ್ತು ಹ್ಯಾಂಡ್ಸೆಟ್ ಮಾದರಿಗಳು ಫೈರ್ವಾಲ್ ತಂಡಕ್ಕೆ ತಿಳಿಸದೆ ಬದಲಾಗುತ್ತವೆ. ಪರಿಶೀಲನೆಯನ್ನು ತಂಡಕ್ಕಿಂತ ಹೆಚ್ಚು ಕಾಲ ಉಳಿಯುವ ತಂಡದ ಹೆಸರಿಗಲ್ಲ, ವ್ಯಕ್ತಿಗೆ ನೀಡಿ. ಅಪರಿಚಿತ ವ್ಯಕ್ತಿ ದಾಖಲೆಯಿಂದಲೇ ನಿಯಮವನ್ನು ಮರುಪಡೆಯಬಹುದಾದಷ್ಟು ನಿರ್ದಿಷ್ಟವಾಗಿ ಪದಗಳನ್ನು ಇರಿಸಿ.
ವಿನಾಯಿತಿಯನ್ನು ಉಳಿದ ತುದಿ ನೀತಿಯ ಅದೇ ಚಕ್ರದಲ್ಲಿ ಇರಿಸಿ, ಇದರಿಂದ ವಾಹಕ ಗಮ್ಯಸ್ಥಾನವನ್ನು ಸರಿಸಿದರೆ ಅಥವಾ ಸಮೂಹ ಹ್ಯಾಂಡ್ಸೆಟ್ ಮಾದರಿ ಬದಲಿಸಿದರೆ ಮುಂದಿನ ಅಡಚಣೆಯಲ್ಲಿ ಅಲ್ಲ, ಪರಿಶೀಲನೆಯಲ್ಲಿ ಗಮನಕ್ಕೆ ಬರುತ್ತದೆ. ಮುರಿದ ಕರೆಗಳನ್ನು ವರದಿ ಮಾಡಿದವರೊಂದಿಗೆ ಚಕ್ರ ಮುಚ್ಚಿ, ಏಕೆಂದರೆ ಬ್ಲಾಕ್ ಮುಚ್ಚಬೇಕಿದ್ದ ಸುರಂಗವನ್ನು ಮತ್ತೆ ತೆರೆಯದೆ ಸರಿಪಡಿಸುವಿಕೆಯನ್ನು ಅವರೊಬ್ಬರೇ ದೃಢೀಕರಿಸಬಲ್ಲರು. ಆ ದೃಢೀಕರಣವೂ ದಿನಾಂಕದೊಂದಿಗೆ ದಾಖಲೆಯಲ್ಲಿ ಇರಬೇಕು.
ತಾತ್ಕಾಲಿಕ ಫೋನ್ ಸರಿಪಡಿಸುವಿಕೆ ಎಂದು ಲೇಬಲ್ ಮಾಡಿದ ಶಾಶ್ವತ ಅನುಮತಿ ಎರಡು ವರ್ಷಗಳ ನಂತರ ಸಮರ್ಥಿಸಲಾಗದು. ಗುರುತಿಸಿದ ಸೇವೆಗೆ ಬದ್ಧವಾದ ಅನುಮತಿಗೆ ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ನವೀಕರಿಸುವ ಅವಧಿ ಇರುತ್ತದೆ.
ಮೂಲವನ್ನು ಪ್ರಾಮಾಣಿಕವಾಗಿ ಮಿತಿಗೊಳಿಸಿ
ವಿನಾಯಿತಿಯನ್ನು ನಿರ್ವಹಿತ ಸಾಧನ ವಿಭಾಗಕ್ಕೆ ಸೀಮಿತಗೊಳಿಸುವುದು ಕಟ್ಟಡದ ಪ್ರತಿ ಲ್ಯಾಪ್ಟಾಪ್ಗೂ ಪ್ರೋಟೋಕಾಲ್ ತೆರೆಯುವುದಕ್ಕಿಂತ ಬಹಳ ಬಲವಾದದ್ದು. ನೆಟ್ವರ್ಕ್ ಆ ವಿಭಾಗವನ್ನು ಗುರುತಿಸಲು ಸಾಧ್ಯವಾಗದಿದ್ದರೆ, ನಿಯಮ ಸಾಧನಗಳನ್ನು ತಿಳಿದಿದೆ ಎಂದು ಸೂಚಿಸುವ ಬದಲು ಅದನ್ನು ಬರೆಯಿರಿ. ಅಗ್ಗದ ಒಳ್ಳೆಯ ಫಲಿತಾಂಶ ಬೇರೆ ಕಾರಣಕ್ಕಾಗಿ ಈಗಾಗಲೇ ಇರುವ ಗಡಿಯನ್ನು ಮರುಬಳಸುವುದು, ಇದರಿಂದ ವಿನಾಯಿತಿ ಹೊಸ ನಿಯಂತ್ರಣವನ್ನು ಕಂಡುಹಿಡಿಯುವ ಬದಲು ಒಂದನ್ನು ಬಳುವಳಿಯಾಗಿ ಪಡೆಯುತ್ತದೆ. ವಿಳಾಸದಿಂದ ಫಿಲ್ಟರ್ ಮಾಡುವುದು ಸಾಧನ ದೃಢೀಕರಣವಲ್ಲ, ಮತ್ತು ಬದಲಾವಣೆ ದಾಖಲೆ ವಿರುದ್ಧವಾಗಿ ಸೂಚಿಸಬಾರದು.
ಮೂಲ ವಿಳಾಸ ಅಥವಾ ಹಾರ್ಡ್ವೇರ್ ವಿಳಾಸ ಭೌತಿಕ ಹ್ಯಾಂಡ್ಸೆಟ್ನ ಸಾಕ್ಷ್ಯವಲ್ಲ. ಅವುಗಳಲ್ಲಿ ಯಾವುದಕ್ಕಾದರೂ ಅರ್ಥವಿದೆಯೇ ಎಂಬುದು ಆ ವಿಭಾಗದೊಳಗಿನ ಇತರ ನಿಯಂತ್ರಣಗಳ ಮೇಲೆ ಸಂಪೂರ್ಣ ಅವಲಂಬಿತವಾಗಿದೆ. ನಿಯಮದ ವಾದ MAC ವಿಳಾಸದ ಮೇಲೆ ನಿಂತಿದ್ದರೆ, ನಿಯಮ ಹೊರಡುವ ಮೊದಲು ಬಳಕೆದಾರರನ್ನು ಅದನ್ನು ಬದಲಿಸದಂತೆ ಯಾವುದು ತಡೆಯುತ್ತದೆ ಎಂದು ಪರಿಶೀಲಿಸಿ.
ಪೋರ್ಟ್ ನಿಯಮ ಹೇಳಲಾಗದ್ದನ್ನು ಒಪ್ಪಿಕೊಳ್ಳಿ
ಪೋರ್ಟ್ಗಳು ಸಾಗಣೆಯ ಅಂತ್ಯಬಿಂದುಗಳನ್ನು ಗುರುತಿಸುತ್ತವೆ, ವ್ಯಾಪಾರ ಉದ್ದೇಶವನ್ನಲ್ಲ. ಅನುಮೋದಿತ ಕರೆ ಸೇವೆ ಮತ್ತು ಅನುಮೋದಿಸದ ಸುರಂಗ ಎರಡೂ ಒಂದೇ UDP 4500 ಮೇಲೆ ಸಾಗಿದಾಗ, ಯಾವುದೇ ಪೋರ್ಟ್-ಆಧಾರಿತ ನಿಯಮ ಅವನ್ನು ಬೇರ್ಪಡಿಸುವುದಿಲ್ಲ. ಹಾಗೆ ಮಾಡುತ್ತದೆ ಎಂದು ಹೇಳಿಕೊಳ್ಳುವ ನಿಯಮ ನಿಖರವಾಗಿ ಕಾಣುತ್ತದೆ, ಆದರೆ ಅಲ್ಲ, ಇದು ತನ್ನ ರೂಪವನ್ನು ಒಪ್ಪಿಕೊಳ್ಳುವ ನಿಯಮಕ್ಕಿಂತ ಕೆಟ್ಟದು. ಇದು ವ್ಯವಸ್ಥೆಯ ಮಿತಿ, ಬರೆದವರ ತಪ್ಪಲ್ಲ.
ಅದನ್ನು ನಿಯಮದ ಪಕ್ಕದಲ್ಲಿ ಹೇಳಿ, ಮತ್ತು ವಿನಾಯಿತಿಯನ್ನು ನೆಟ್ವರ್ಕ್ನಲ್ಲಿರುವ ಜಾರಿಗೆ, ಉದಾಹರಣೆಗೆ ಸಾಧನ ನಿರ್ವಹಣೆ ಅಥವಾ ಅನುಮತಿಸಿದ ಗಮ್ಯಸ್ಥಾನ ಪಟ್ಟಿಯೊಂದಿಗೆ ಜೋಡಿಸಿ. ನಂತರ ವಿನಾಯಿತಿಯನ್ನು ಸಾಧನ ಅನುಮತಿಸುವಷ್ಟು ಸಂಕುಚಿತವಾಗಿ ವ್ಯಕ್ತಪಡಿಸಿ, ಉದಾಹರಣೆಗೆ ವಿಭಾಗ ಮತ್ತು ಪೋರ್ಟ್ ಜೋಡಿಯನ್ನು ಹೆಸರಿಸಿ ಸಾಮಾನ್ಯ ನಿಷೇಧವನ್ನು ಅವುಗಳ ನಂತರ ಇಡುವ nftables ನಿಯಮಗಳಿಂದ:
nft add rule inet edge forward ip saddr 10.40.0.0/24 udp dport { 500, 4500 } counter accept
nft add rule inet edge forward udp dport { 500, 4500 } counter drop
nftables ಕ್ರಮದಲ್ಲಿ ಮೌಲ್ಯಮಾಪನ ಮಾಡಿ ಮೊದಲ ಹೊಂದಾಣಿಕೆಯಲ್ಲಿ ನಿಲ್ಲುತ್ತದೆ, ಆದ್ದರಿಂದ ಮಿತವಾದ ಅನುಮತಿ ಸಾಮಾನ್ಯ ನಿಷೇಧದ ಮೇಲೆ ಇರಬೇಕು. ಎರಡನ್ನೂ ತಿರುಗಿಸಿದರೆ ವಿನಾಯಿತಿ ಸದ್ದಿಲ್ಲದೆ ಏನೂ ಮಾಡುವುದಿಲ್ಲ.
ವೈಶಿಷ್ಟ್ಯ ಮತ್ತು ನಿಷೇಧವನ್ನು ಮೌಲ್ಯೀಕರಿಸಿ
ಅನುಮೋದಿತ ಮೌಲ್ಯೀಕರಣವನ್ನು ಸಾಮಾನ್ಯ Wi-Fi ಕರೆಯಲ್ಲಿ, ವಿನಾಯಿತಿ ಇರುವ ಸಾಧನ ವರ್ಗದಿಂದ ನಡೆಸಿ, ಮತ್ತು ಹೊರಗಿಟ್ಟ ಕ್ಲೈಂಟ್ ಇನ್ನೂ ವಿಫಲವಾಗುತ್ತದೆ ಎಂದು ದೃಢೀಕರಿಸಿ. ಯಾವುದೇ ಸಂದರ್ಭದಲ್ಲೂ ತುರ್ತು ಕರೆಗಳನ್ನು ಪರೀಕ್ಷಾ ಪ್ರಕರಣವಾಗಿ ಬಳಸಬೇಡಿ. ನಂತರ ಹೊರಟ ನಿಯಮವನ್ನು ಪರಿಶೀಲಿಸಿ, ಏಕೆಂದರೆ ಶೂನ್ಯದಲ್ಲಿ ನಿಂತಿರುವ ಕೌಂಟರ್ ವಿನಾಯಿತಿ ಎಂದಿಗೂ ಹೊಂದಲಿಲ್ಲ ಎಂಬುದಕ್ಕೆ ಅತಿ ವೇಗದ ಸಾಕ್ಷ್ಯ:
nft -a list chain inet edge forward
ಪರೀಕ್ಷೆಯಲ್ಲಿ ಮರುಸಂಪರ್ಕ ಅಥವಾ ನೆಟ್ವರ್ಕ್ ಬದಲಾವಣೆ ಸೇರಿಸಿ, ಮತ್ತು ಫೋನ್ ಈಗಾಗಲೇ ಸಂಪರ್ಕಗೊಂಡಿದ್ದಕ್ಕಿಂತ ನೆಟ್ವರ್ಕ್ಗೆ ಸೇರುವ ತಣ್ಣನೆಯ ಆರಂಭದಿಂದ ಅದನ್ನು ಪುನರಾವರ್ತಿಸಿ. ಕರೆಗಳು ವಿಫಲವಾಗುತ್ತಿದ್ದರೂ ಕೌಂಟರ್ ಚಲಿಸಿದರೆ, ಸಮಸ್ಯೆ ಫೈರ್ವಾಲ್ ಬಿಟ್ಟು ವಾಹಕದ ಗಮ್ಯಸ್ಥಾನ ಪಟ್ಟಿಗೆ ಸೇರಿದೆ.