Postfix, VPN ಮತ್ತು smarthost: ಸರದಿ ಫೈರ್ವಾಲ್ ಅಲ್ಲ

VPN ಏರುವವರೆಗೆ ಮೇಲ್ ಅನ್ನು ಸರದಿಯಲ್ಲಿ ಇಡುವುದು ವೇಳಾಪಟ್ಟಿ ಸಮಸ್ಯೆ, ಮತ್ತು ಸಾಮಾನ್ಯ ಪರಿಹಾರ Postfix ನಿಲ್ಲಿಸಿ, main.cf ಬದಲಿಸಿ ಮತ್ತೆ ಪ್ರಾರಂಭಿಸುವುದು. ಅದು ಕೆಲಸ ಮಾಡುತ್ತದೆ, ಮತ್ತು ಅದು ತಪ್ಪು ರೂಪ, ಏಕೆಂದರೆ ಅದು ಎರಡು ಅಗತ್ಯಗಳನ್ನು ಬೆರೆಸುತ್ತದೆ: ವಿತರಣೆಯನ್ನು ಯಾವಾಗ ಪ್ರಯತ್ನಿಸಬೇಕು, ಮತ್ತು ಯಾವ ನೆಟ್ವರ್ಕ್ ಮಾರ್ಗ ಅದನ್ನು ಸಾಗಿಸಬಹುದು. ಎರಡನೆಯದು ಫೈರ್ವಾಲ್ನ ನಿರ್ಧಾರ, ಮತ್ತು ಯಾವುದೇ Postfix ಸೂಚನೆ ಅದನ್ನು ತೆಗೆದುಕೊಳ್ಳಲಾಗದು. ಎರಡೂ ಬೇರ್ಪಟ್ಟ ಮೇಲೆ, ಪ್ರತಿಯೊಂದಕ್ಕೂ ಸಣ್ಣ ಮತ್ತು ಪರೀಕ್ಷಿಸಬಹುದಾದ ಉತ್ತರವಿದೆ.

ರಿಲೇಯ ಗಮ್ಯಸ್ಥಾನವನ್ನು ಸ್ಥಿರವಾಗಿಡಿ, ನೆಟ್ವರ್ಕ್ ಗಡಿಯಲ್ಲಿ ನೇರ ವಿತರಣೆಯನ್ನು ತಡೆಯಿರಿ, ಮತ್ತು ಕಾಯುವಿಕೆಯನ್ನು ಸರದಿಗೆ ಬಿಡಿ.

ಜನರು ಒಂದಾಗಿ ಸೇರಿಸುವ ಎರಡು ಅಗತ್ಯಗಳು

ರಿಲೇ Postfix ಗೆ ಮೇಲ್ ಎಲ್ಲಿ ಒಪ್ಪಿಸಬೇಕೆಂದು ಹೇಳುತ್ತದೆ; relayhost = [smtp.corp.example]:587 ಹೋಸ್ಟ್ ಮತ್ತು ಪೋರ್ಟ್ ಹೆಸರಿಸುತ್ತದೆ, ಮತ್ತು ಆವರಣಗಳು ಮುಂದಿನ ಹಾಪ್ಗೆ MX ಆಧಾರಿತ ಆಯ್ಕೆಯನ್ನು ನಿಗ್ರಹಿಸುತ್ತವೆ. ಮಾರ್ಗವು ಪ್ಯಾಕೆಟ್ಗಳು ಎಲ್ಲಿಗೆ ಹೋಗಬಹುದೆಂದು ಕರ್ನೆಲ್ಗೆ ಹೇಳುತ್ತದೆ. ಮಾರ್ಗ ನಿರ್ಬಂಧವಿಲ್ಲದ ಸರಿಯಾದ relayhost ಆಗಲೂ ರೂಟಿಂಗ್ ಕೋಷ್ಟಕ ಅನುಮತಿಸಿದಾಗ Postfix ನೇರವಾಗಿ ಇಂಟರ್ನೆಟ್ ತಲುಪಲು ಬಿಡುತ್ತದೆ, ಮತ್ತು ತಪ್ಪು relayhost ಜೊತೆಗಿನ ಸರಿಯಾದ ಫೈರ್ವಾಲ್ ಮೇಲ್ ಅನ್ನು ತಪ್ಪು ಜಾಗಕ್ಕೆ ಕಳುಹಿಸುತ್ತದೆ. ಯಾವುದೂ ಇನ್ನೊಂದನ್ನು ಸೂಚಿಸುವುದಿಲ್ಲ.

ಸಾಗಣೆ ನಕ್ಷೆಗಳು, ಪ್ರತಿ ಕಳುಹಿಸುವವರ ಮೇಲ್ಬರಹ ಮತ್ತು ಬ್ಯಾಕಪ್ ರಿಲೇಗಳು ಪ್ರತಿಯೊಂದೂ ಅದೇ ಓದಿಗೆ ಅರ್ಹ. ಸ್ಥಿರ relayhost ಎಲ್ಲಾ ಸಂರಚಿತ ವಿತರಣಾ ಮಾರ್ಗ ಅದನ್ನು ಬಳಸುತ್ತದೆ ಎಂಬುದಕ್ಕೆ ಸಾಕ್ಷಿಯಲ್ಲ, ಮತ್ತು ರಿಲೇಯನ್ನು ಬಳಸದ ಬ್ಯಾಕಪ್ ಮಾರ್ಗ ಅದೇ ವೈಫಲ್ಯ, ಉತ್ತಮ ಮರೆವಿನಲ್ಲಿ.

defer_transports ನಿಜವಾಗಿ ಏನು ಮಾಡುತ್ತದೆ

defer_transports ಹೆಸರಿಸಿದ ಸಾಗಣೆಗಳಿಗೆ ಸಂದೇಶಗಳನ್ನು ತಡೆಹಿಡಿಯುತ್ತದೆ, ಹೀಗಾಗಿ ಸರದಿ ಸುತ್ತು ಅವುಗಳನ್ನು ಸ್ಪರ್ಶಿಸುವವರೆಗೆ ಯಾವುದೇ ವಿತರಣಾ ಪ್ರಯತ್ನ ನಡೆಯುವುದಿಲ್ಲ. ಇದು ವೇಳಾಪಟ್ಟಿ ನಿಯಂತ್ರಣ, ಮತ್ತು ಸರದಿ ಫ್ಲಷ್ ಅದನ್ನು ಮೀರುತ್ತದೆ; ಇದು ವಿನ್ಯಾಸ, ದೋಷವಲ್ಲ. master.cf ನ ನಿಜವಾದ ಸಾಗಣೆ ಹೆಸರುಗಳನ್ನು ಬಳಸಿ, ಏಕೆಂದರೆ ಕಸ್ಟಮ್ ಸಾಗಣೆ ಅಥವಾ ಪ್ರತ್ಯೇಕ ಹೆಸರಿನ ರಿಲೇ ಸಾಗಣೆ ಅದರ ಪ್ರೋಗ್ರಾಂ SMTP ಕೂಡ ಮಾತನಾಡುತ್ತದೆ ಎಂಬ ಕಾರಣಕ್ಕೆ ಮಾತ್ರ ಒಳಗೊಳ್ಳುವುದಿಲ್ಲ. ಸಾಮಾನ್ಯ ಮರುಪ್ರಯತ್ನ ಬೇರೆ ವ್ಯವಸ್ಥೆ: fail-closed ಮಾರ್ಗದಲ್ಲಿ ವಿತರಣಾ ಪ್ರಯತ್ನಗಳು ಸರಳವಾಗಿ ವಿಫಲವಾಗಿ ಸರದಿಯಲ್ಲಿ ಉಳಿಯುತ್ತವೆ, ಯಾವುದೇ ವಿಳಂಬ ಸೂಚನೆ ಒಳಗೊಂಡಿಲ್ಲ.

ಶಾಶ್ವತ ವೈಫಲ್ಯಗಳು ವಿನಯದಿಂದ ಕಾಯುವುದಿಲ್ಲ. ಕೆಟ್ಟ ಸ್ವೀಕರಿಸುವವರು ಅಥವಾ ನಿರಾಕರಿಸಿದ ರುಜುವಾತು ಸುರಂಗ ಬರುವವರೆಗೆ ಕುಳಿತುಕೊಳ್ಳುವ ಬದಲು ಹಿಂತಿರುಗುತ್ತದೆ ಅಥವಾ ಕಠಿಣ ದೋಷವಾಗಿ ಸಿಕ್ಕಿಕೊಳ್ಳುತ್ತದೆ, ಆದ್ದರಿಂದ ವಿಳಂಬಿತ ಮೇಲ್ನಿಂದ ತುಂಬಿದ ಸರದಿ ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಸುರಕ್ಷಿತ ಸರದಿ ಅಲ್ಲ.

ನೆಟ್ವರ್ಕ್ ಪದರದಲ್ಲಿ ಮಾರ್ಗವನ್ನು ಜಾರಿಗೊಳಿಸಿ

ನಿರ್ಬಂಧ ಸ್ಥಳೀಯ ಔಟ್ಪುಟ್ ಗಡಿಯಲ್ಲಿ ಅಥವಾ ಪ್ರತ್ಯೇಕಿಸಿದ ನೆಟ್ವರ್ಕ್ ನೇಮ್ಸ್ಪೇಸ್ ಒಳಗೆ ಇರಬೇಕು. ಅದು ರಿಲೇಯ ನಿಜವಾದ ವಿಳಾಸಗಳು, ಸಾಗಣೆ ಮತ್ತು ಪೋರ್ಟ್ ಅನ್ನು ಒಳಗೊಳ್ಳಬೇಕು, ಸಕ್ರಿಯವಾಗಿದ್ದರೆ IPv6 ಸಹ, ಏಕೆಂದರೆ TCP 25 ತಡೆಯುವ ನಿಯಮ 587 ಅಥವಾ 465 ನಲ್ಲಿರುವ ರಿಲೇಗೆ ಏನನ್ನೂ ಮಾಡುವುದಿಲ್ಲ. ಲೂಪ್ಬ್ಯಾಕ್ ಮತ್ತು ಸ್ಥಳೀಯ ಸಲ್ಲಿಕೆ ಮಾರ್ಗಗಳನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿಡಿ, ಸರದಿಯೇ ಕೆಲಸ ಮಾಡುತ್ತಿರಲಿ. ಸುರಂಗ ಮಾರ್ಗ ಕಣ್ಮರೆಯಾದಾಗ ಅಥವಾ ಬೇರೆ ಇಂಟರ್ಫೇಸ್ ಹೆಸರಿನಲ್ಲಿ ಮತ್ತೆ ಕಾಣಿಸಿಕೊಂಡಾಗ ನೀತಿ ಮುಚ್ಚಿದ್ದಾಗಿರಬೇಕು.

ಇಂಟರ್ಫೇಸ್ ಏರಿದ ಘಟನೆ ರಿಲೇ ಅದರ ಮೂಲಕ ತಲುಪಬಹುದೆಂದು ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ. ಆದ್ದರಿಂದ ಲಿಂಕ್ ಪರಿಶೀಲಿಸಿ ನಂತರ ಸರದಿ ಖಾಲಿ ಮಾಡುವ ಹುಕ್ ಸೌಲಭ್ಯ, ಖಾತರಿ ಅಲ್ಲ: ಪರಿಶೀಲನೆ ಮತ್ತು ವಿತರಣಾ ಪ್ರಯತ್ನದ ನಡುವೆ ಲಿಂಕ್ ಬದಲಾಗಬಹುದು.

ಒಂದು ಹಾನಿಕರವಲ್ಲದ ಸಂದೇಶದಿಂದ ಸಾಬೀತುಪಡಿಸಿ

VPN ಕೆಳಗಿರುವಾಗ ಒಂದು ಹಾನಿಕರವಲ್ಲದ ಸಂದೇಶ ಕಳುಹಿಸಿ, ನಂತರ ವಿಳಂಬದ ಕಾರಣ ಮತ್ತು ಸರದಿ ID ಗಾಗಿ postqueue -p ಪರಿಶೀಲಿಸಿ. ಉದ್ದೇಶಿತ ಮಾರ್ಗವನ್ನು ಮರುಸ್ಥಾಪಿಸಿ ಮತ್ತು ನಿಯಂತ್ರಿತ ಸರದಿ ಸುತ್ತನ್ನು ಕೋರಿ, ಸಂದೇಶ ಬೇರೆಡೆಗೆ ಅಲ್ಲದೆ ರಿಲೇ ಮೂಲಕ ಹೊರಡುತ್ತದೆಯೇ ಎಂದು ಗಮನಿಸಿ. ನಂತರ ಹಾರಾಟದ ಮಧ್ಯದಲ್ಲಿ ಮಾರ್ಗವನ್ನು ಮತ್ತೆ ಮುರಿಯಿರಿ ಮತ್ತು ಸಂದೇಶ ಸರದಿಗೆ ಮರಳುತ್ತದೆ ಎಂದು ದೃಢೀಕರಿಸಿ. ಅಡಚಣೆ ಎಷ್ಟು ಕಾಲ ಇರಬಹುದು ಎಂದು ನಿರ್ಧರಿಸುವ ಮೊದಲು maximal_queue_lifetime ಪರಿಶೀಲಿಸಿ, ಏಕೆಂದರೆ ಶೂನ್ಯ ಮೌಲ್ಯ ಎಂದರೆ ಒಂದು ಪ್ರಯತ್ನ, ಅಪರಿಮಿತ ಧಾರಣೆಯಲ್ಲ.

ಸರದಿಯ ವಯಸ್ಸು ಮತ್ತು ಡಿಸ್ಕ್ ಬಳಕೆಯನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಿ. VPN ಗಾಗಿ ಕಾಯುವ ನೀತಿ, ಶುಕ್ರವಾರದಿಂದ ಸರದಿ ಬೆಳೆಯುತ್ತಿದೆ ಎಂದು ಯಾರೂ ಗಮನಿಸದಿದ್ದರೆ ಮೇಲ್ ಅಡಚಣೆಯಾಗುತ್ತದೆ.

ರಿಲೇ, ಸಾಗಣೆ, ಫೈರ್ವಾಲ್ ನಿಯಮ ಮತ್ತು ಆಯುಷ್ಯವನ್ನು ಒಟ್ಟಿಗೆ ದಾಖಲಿಸಿ. ಆ ನಾಲ್ಕು ವ್ಯವಸ್ಥೆಯನ್ನು ವಿವರಿಸುತ್ತವೆ; ಅವುಗಳಲ್ಲಿ ಯಾವುದೇ ಒಂದು ಒಂಟಿಯಾಗಿ ಊಹೆಯನ್ನು ವಿವರಿಸುತ್ತದೆ.