ನಿಮ್ಮ ಹಾಟ್ಸ್ಪಾಟ್ ನ ಫೈರ್ವಾಲ್ ಗುತ್ತಿಗೆಗಿಂತ ಮೊದಲು DHCP ಅನ್ನು ತಡೆಯುತ್ತದೆ

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

ಕ್ಲೈಂಟ್ ಸೇರುವುದನ್ನು ಗಮನಿಸಿ

ಕ್ಲೈಂಟ್ ನ ಬದಿಯಿಂದ ಒಂದು ಸಂಯೋಜನೆಯನ್ನು ಅನುಸರಿಸಿ. ರೇಡಿಯೋ ಸಂಯೋಜನೆಗೊಳ್ಳುತ್ತದೆ, ಕ್ಲೈಂಟ್ DHCP ಶೋಧವನ್ನು ಕಳುಹಿಸುತ್ತದೆ, ಸರ್ವರ್ ಆಫರ್ ನೀಡುತ್ತದೆ, ಕ್ಲೈಂಟ್ ವಿನಂತಿಸುತ್ತದೆ, ಸರ್ವರ್ ದೃಢೀಕರಿಸುತ್ತದೆ, ಮತ್ತು ಆಗ ಮಾತ್ರ ಕ್ಲೈಂಟ್ ಗೆ ಬೇರೆ ಯಾವುದಕ್ಕೂ ಬಳಸಬಹುದಾದ ವಿಳಾಸ ಇರುತ್ತದೆ.

ಆ ಅಂತಿಮ ದೃಢೀಕರಣಕ್ಕೆ ಮೊದಲಿನ ಎಲ್ಲವೂ ಕ್ಲೈಂಟ್ ಸಾಮಾನ್ಯ ಸಂಚಾರಕ್ಕೆ ಗೇಟ್ವೇ ಬಳಸಲಾಗದ ಸಮಯದಲ್ಲಿ ನಡೆಯುತ್ತದೆ. ಸಬ್ನೆಟ್ ನಿಯಮ ಮರೆತುಬಿಡುವ ಕಿಟಕಿ ಅದೇ.

ಮೊದಲ ಪ್ಯಾಕೆಟ್ ನಲ್ಲಿ ವಾಸ್ತವವಾಗಿ ಏನಿದೆ

RFC 2131 ವಿಳಾಸ ಪಡೆಯುವ ಮೊದಲು ಕ್ಲೈಂಟ್ ನ DHCP ಪ್ರಸಾರಗಳು ಶೂನ್ಯ ಮೂಲ ವಿಳಾಸವನ್ನು ಬಳಸುತ್ತವೆ ಎಂದು ನಿರ್ದಿಷ್ಟಪಡಿಸುತ್ತದೆ. ಕ್ಲೈಂಟ್ ನಿಂದ ಸರ್ವರ್ ಗೆ ಸಂದೇಶಗಳು UDP ಪೋರ್ಟ್ 67 ಗೆ, ಮತ್ತು ಸರ್ವರ್ ನಿಂದ ಕ್ಲೈಂಟ್ ಗೆ ಸಂದೇಶಗಳು UDP ಪೋರ್ಟ್ 68 ಗೆ ಹೋಗುತ್ತವೆ. ಆದ್ದರಿಂದ ಶೋಧವು 0.0.0.0 ಅನ್ನು ಮೂಲವಾಗಿ ಪಡೆದು ಬರುತ್ತದೆ, ಮತ್ತು ನಿಮ್ಮ ಕ್ಲೈಂಟ್ ಸಬ್ನೆಟ್ ಒಳಗೆ ಮೂಲವನ್ನು ಒತ್ತಾಯಿಸುವ ನಿಯಮವು ಅದಕ್ಕೆ ಸರಳವಾಗಿ ಹೊಂದಿಕೆಯಾಗುವುದಿಲ್ಲ.

ಇದು ಕ್ಲೈಂಟ್ ನ ಕಡೆಯಿಂದ ತಪ್ಪಾದ ಸಂರಚನೆ ಅಲ್ಲ. ಇದು ಪ್ರೋಟೋಕಾಲ್, ವಿನ್ಯಾಸಗೊಂಡಂತೆಯೇ ಕೆಲಸ ಮಾಡುತ್ತಿದೆ, ಅದು ಸಾಧ್ಯವಿರುವ ಏಕೈಕ ಕಿಟಕಿಯಲ್ಲಿ.

ಯಾವ ಮಾರ್ಗವು ಅದನ್ನು ನಿಜವಾಗಿ ನಿರ್ವಹಿಸುತ್ತದೆ

ಪ್ರವೇಶ ಬಿಂದುವೇ ಗುತ್ತಿಗೆಗಳನ್ನು ನೀಡುತ್ತಿದ್ದರೆ, ಇದು ಸ್ಥಳೀಯ ಸೇವಾ ಸಂಭಾಷಣೆ, ಮತ್ತು IP ಯಿಂದ ಫಿಲ್ಟರ್ ಮಾಡಿದ ಸ್ಥಳೀಯ ಮಾರ್ಗದಲ್ಲಿ ಇದು ಇನ್ಪುಟ್ ಮತ್ತು ಔಟ್ಪುಟ್ ನೀತಿಗೆ ಸಂಬಂಧಿಸಿದೆ. VPN ಮೂಲಕ ಮುಂದಕ್ಕೆ ರವಾನೆಯಾದ ಕ್ಲೈಂಟ್ ಸಂಚಾರ ಬೇರೆ ನಿರ್ಧಾರ, ಮತ್ತು ಆ ಸಂಚಾರಕ್ಕೆ NAT ಮತ್ತೆ ಬೇರೆಯದು. ಈ ಮೂರನ್ನು ಬೆರೆಸುವುದೇ ಸಣ್ಣ ವಿನಾಯಿತಿಯನ್ನು ದೊಡ್ಡದಾಗಿಸುವ ದಾರಿ.

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

ಫೋರಂನಿಂದ ನಕಲಿಸಿದ ಸಾಮಾನ್ಯ ಇನ್ಪುಟ್/ಔಟ್ಪುಟ್ ಪಾಕವಿಧಾನವು ನಿಮ್ಮ ಅನುಷ್ಠಾನವು ಆ ಸರಪಳಿಗಳ ಮೂಲಕ ಅದೇ ರೀತಿಯಲ್ಲಿ ಹಾದುಹೋಗುತ್ತದೆ ಎಂಬುದಕ್ಕೆ ಸಾಕ್ಷಿಯಲ್ಲ.

ಉತ್ತರ ಯಾವಾಗಲೂ ಪ್ರಸಾರವಲ್ಲ

ಪ್ರಸಾರ ಉತ್ತರಗಳಿಗೆ ಮಾತ್ರ ಅನುಮತಿ ನೀಡುವ ವಿನಾಯಿತಿಯೂ ತಪ್ಪು. DHCP ಉತ್ತರದ ಗಮ್ಯಸ್ಥಾನವು ಕ್ಲೈಂಟ್ ನ ಸ್ಥಿತಿ ಮತ್ತು ಸಂದೇಶದ ಕ್ಷೇತ್ರಗಳನ್ನು ಅವಲಂಬಿಸಿದೆ, ಮತ್ತು ಪ್ರೋಟೋಕಾಲ್ ಪ್ರಸಾರ ಮತ್ತು ಯುನಿಕಾಸ್ಟ್ ಎರಡೂ ಸಂದರ್ಭಗಳನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸುತ್ತದೆ. ನಿಮ್ಮ ಸರ್ವರ್ ನೀಡಲಿರುವ ವಿಳಾಸಕ್ಕೆ ಯುನಿಕಾಸ್ಟ್ ನಲ್ಲಿ ಉತ್ತರಿಸಿದರೆ, ಪ್ರಸಾರ-ಮಾತ್ರ ನಿಯಮವು ಕೆಲಸ ಮುಗಿಸುವ ಹಂತವನ್ನು ತಡೆಯುತ್ತದೆ. ಸಂರಚಿತ ಸರ್ವರ್ ನಿಜವಾಗಿ ಮಾಡುವ ವಿನಿಮಯಕ್ಕೆ ಅನುಗುಣವಾಗಿ ನಿಯಮ ಬರೆಯಿರಿ.

ನಂತರದ ಗುತ್ತಿಗೆ ನವೀಕರಣಗಳು ಬೇರೆ ಸ್ಥಿತಿಯಲ್ಲಿ ಅದೇ ವಿನಿಮಯವನ್ನು ಪುನರಾವರ್ತಿಸುತ್ತವೆ, ಆದ್ದರಿಂದ ಮೊದಲ ಸೇರ್ಪಡೆಗೆ ಮಾತ್ರವಲ್ಲ, ಅವುಗಳಿಗೂ ಜಾಗ ಬಿಡಿ.

ಸಣ್ಣದಾಗಿ ಸರಿಪಡಿಸಿ, ನಂತರ ಉಳಿದದ್ದನ್ನು ಪರಿಶೀಲಿಸಿ

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

ಕೋಷ್ಟಕವನ್ನು ಫ್ಲಶ್ ಮಾಡುವುದು DHCP ಸಂರಚನೆಯ ಹಂತವಲ್ಲ. iptables ನಲ್ಲಿ flush ಆಯ್ಕೆಮಾಡಿದ ಸರಪಳಿ ಅಥವಾ ಕೋಷ್ಟಕದಿಂದ ನಿಯಮಗಳನ್ನು ಅಳಿಸುತ್ತದೆ, ಮತ್ತು NAT ಕೋಷ್ಟಕವನ್ನು ಫ್ಲಶ್ ಮಾಡಿದರೆ ಅನುವಾದ ನಿಯಮ ಸೃಷ್ಟಿಯಾಗುವುದಿಲ್ಲ. ವಿಶಾಲ ACCEPT ನೀತಿಗಳನ್ನು ಹೊಂದಿಸುವುದು ಗುತ್ತಿಗೆಗೆ ಸಂಬಂಧವಿಲ್ಲದ ರಕ್ಷಣೆಯನ್ನು ತೆಗೆದುಹಾಕುತ್ತದೆ, ಆದ್ದರಿಂದ ಎರಡೂ ಮರುಬಳಕೆ ಮಾಡಬಹುದಾದ ಹಾಟ್ಸ್ಪಾಟ್ ಸರಿಪಡಿಸುವಿಕೆಗೆ ಸೇರುವುದಿಲ್ಲ.

ಕ್ಲೈಂಟ್ ಗುತ್ತಿಗೆ ಹೊಂದಿದ ನಂತರ, DNS, ಫಾರ್ವರ್ಡಿಂಗ್ ಮತ್ತು VPN ನಿರ್ಗಮನವನ್ನು ಪ್ರತ್ಯೇಕ ಕಾರ್ಯಗಳಾಗಿ ಪರಿಶೀಲಿಸಿ. ಗುತ್ತಿಗೆ ಸ್ಥಳೀಯ ವಿಳಾಸೀಕರಣವನ್ನು ಸ್ಥಾಪಿಸುತ್ತದೆ, ಅಷ್ಟಕ್ಕೂ ಹೆಚ್ಚಲ್ಲ.