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

ಲುಕಪ್ ಮೂಲವನ್ನು ಮತ್ತೆ ಬರೆಯುವ ಮೊದಲು ನಡೆಯುತ್ತದೆ

VPN ಕ್ಲೈಂಟ್‌ನಿಂದ ರವಾನೆಯಾಗುವ ಪ್ಯಾಕೆಟ್‌ಗೆ ಕರ್ನಲ್ ಒಂದು ನಿಶ್ಚಿತ ಕ್ರಮವನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ. ಅದು ಸುರಂಗ ಇಂಟರ್‌ಫೇಸ್‌ಗೆ ಬರುತ್ತದೆ, conntrack ಮತ್ತು DNAT ಇರುವ prerouting ಮೂಲಕ ಹೋಗುತ್ತದೆ, ನಂತರ ಮಾರ್ಗನಿರ್ಣಯ ಮಾಡಲಾಗುತ್ತದೆ, ನಂತರ ರವಾನೆ, ನಂತರ SNAT ಕೊನೆಯದಾಗಿ ಅನ್ವಯವಾಗುವ postrouting. from ರೂಪದ ನಿಯಮವನ್ನು ಆ ಮಾರ್ಗನಿರ್ಣಯದ ಸಮಯದಲ್ಲಿ ಪರಿಶೀಲಿಸಲಾಗುತ್ತದೆ, ಅಂದರೆ ಅದು ಕ್ಲೈಂಟ್‌ನ ಮೂಲ ವಿಳಾಸವನ್ನು ನೋಡುತ್ತದೆ, ಅನುವಾದಿತವನ್ನಲ್ಲ.

ಆದ್ದರಿಂದ masquerade ನಿಯಮ ಸೇರಿಸುವುದು ಹೊರಹೋಗುವ ಹರಿವಿಗೆ ಯಾವ ನೀತಿ ಹೊಂದುತ್ತದೆ ಎಂಬುದನ್ನು ಬದಲಿಸುವುದಿಲ್ಲ. ಬದಲಾಗುವುದು ದೂರದ ತುದಿ ಏನನ್ನು ನೋಡುತ್ತದೆ, ಮತ್ತು ಆದ್ದರಿಂದ ಯಾವ ಹಿಂತಿರುಗುವ ಮಾರ್ಗ ಇದೆ ಎಂಬುದು. ಇವು ಎರಡು ಬೇರೆ ಪರಿಣಾಮಗಳು, ಮತ್ತು ಬದಲಾವಣೆ ವಿಮರ್ಶೆಗಳು ಅವನ್ನು ನಿರಂತರವಾಗಿ ಗೊಂದಲಗೊಳಿಸುತ್ತವೆ. ಅವನ್ನು ಬೇರ್ಪಡಿಸಿ, ವಿನ್ಯಾಸ ಸಾಮಾನ್ಯವಾಗಿ ಒಂದು ನಿಮಿಷದಲ್ಲಿ ಸ್ಪಷ್ಟವಾಗುತ್ತದೆ.

ಅನುವಾದಿತ ವಿಳಾಸವು ನಿಯಮಗಳಲ್ಲಿ ಉತ್ತರದ ದಿಕ್ಕಿನಲ್ಲಿ ಕಾಣಿಸುತ್ತದೆ. ಗೇಟ್‌ವೇಗೆ ಹಿಂತಿರುಗುವ ಪ್ಯಾಕೆಟ್ ಅನುವಾದಿತ ವಿಳಾಸಕ್ಕೆ ಉದ್ದೇಶಿಸಲಾಗಿದೆ, ಮತ್ತು ಗಮ್ಯಸ್ಥಾನ ಅಥವಾ ಅದು ಬಂದ ಇಂಟರ್‌ಫೇಸ್ ಆಧಾರಿತ ನೀತಿ ನಿಯಮಗಳಿದ್ದರೆ, ನೀವು ಹೊಂದಿಸುವ ಮೌಲ್ಯ ಅದೇ. ಒಂದೇ ಸಂಪರ್ಕ, ಪ್ರತಿ ದಿಕ್ಕಿನಲ್ಲಿ ಸತ್ಯದ ಬೇರೆ ಮೂಲ.

StageSource the kernel seesWhat it means for your rule
PreroutingClient address, 172.31.7.42Where marks and DNAT are applied
Routing decisionStill 172.31.7.42This is where from rules match
PostroutingBecomes 198.51.100.9What the far end and its return route see

ಆದ್ದರಿಂದ ಬೇರೆ ಮೂಲಗಳ ಎರಡು ಪೂಲ್‌ಗಳಿಗೆ ನಿಜವಾಗಿಯೂ ಬೇರೆ ಕೋಷ್ಟಕಗಳು ಬೇಕು, ಮತ್ತು ವಿನ್ಯಾಸ ಸರಿಯಾಗಿದೆ. ಮೇಲಿನ ಕೋಷ್ಟಕವು ತಳ್ಳಿಹಾಕುವುದು ದೂರದ ಸೈಟ್ ಏನನ್ನು ಪಡೆದುಕೊಂಡಿತು ಎಂದು ನೋಡಿ ಅದರಿಂದ ನಿಯಮವನ್ನು ಊಹಿಸುವ ಸಣ್ಣ ದಾರಿಯನ್ನು.

ಗೇಟ್‌ವೇಯಿಂದ ಮಾಡಿದ ಪರೀಕ್ಷೆ ಪೂಲ್‌ನ ಪರೀಕ್ಷೆ ಅಲ್ಲ

ಗೇಟ್‌ವೇ ಸ್ವತಃ ಉತ್ಪಾದಿಸುವ ಟ್ರಾಫಿಕ್ ಎಂದಿಗೂ prerouting ಮೂಲಕ ಹೋಗುವುದಿಲ್ಲ, ಏಕೆಂದರೆ ಅದು ಯಾವ ಇಂಟರ್‌ಫೇಸ್‌ಗೂ ಬಂದಿಲ್ಲ. ಅದು ಔಟ್‌ಪುಟ್ ಮಾರ್ಗದಲ್ಲಿ ಮಾರ್ಗನಿರ್ಣಯಗೊಳ್ಳುತ್ತದೆ, ಮೂಲವಾಗಿ ಗೇಟ್‌ವೇಯ ಸ್ವಂತ ವಿಳಾಸ, ಮತ್ತು ಕ್ಲೈಂಟ್ ಶ್ರೇಣಿ ಆಧರಿಸಿದ from ನಿಯಮ ಹೊಂದುವುದಿಲ್ಲ. ಈ ಕ್ಷೇತ್ರದ ಪ್ರತಿ ಟಿಕೆಟ್, ಬಾಕ್ಸ್‌ನಿಂದ ಕೆಲಸ ಮಾಡುತ್ತದೆ ಆದರೆ ಕ್ಲೈಂಟ್‌ನಿಂದ ಇಲ್ಲ ಎಂದು ಹೇಳುವುದು ಆ ಸತ್ಯದ ಪುನರಾವರ್ತನೆ.

ಕ್ಲೈಂಟ್ ಅನ್ನು ಅಂದಾಜಿಸುವ ಬದಲು ಅನುಕರಿಸಿ. ಮಾರ್ಗನಿರ್ಣಯದ ಲುಕಪ್ ಅನ್ನು ನೇರವಾಗಿ ಕೇಳಬಹುದು, ಮೂಲ ಮತ್ತು ಪ್ರವೇಶ ಇಂಟರ್‌ಫೇಸ್ ನೀಡಿ:

ip route get 198.51.100.9 from 172.31.7.42 iif tun0
ip route get 198.51.100.9 from 172.31.8.42 iif tun0
ip route show table 201

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

ಆದ್ಯತೆ, ಫೈಲ್‌ನಲ್ಲಿ ಸ್ಥಾನವಲ್ಲ

ನಿಯಮಗಳನ್ನು ಆದ್ಯತೆಯ ಏರಿಕೆ ಕ್ರಮದಲ್ಲಿ ಮೌಲ್ಯಮಾಪನ ಮಾಡಲಾಗುತ್ತದೆ, ಮತ್ತು ಸಂಖ್ಯೆಯೇ ಮುಖ್ಯ, ನೀವು ಟೈಪ್ ಮಾಡಿದ ಕ್ರಮವಲ್ಲ. local ಕೋಷ್ಟಕ ಆದ್ಯತೆ 0 ರಲ್ಲಿದೆ, main ಕೋಷ್ಟಕ 32766 ರಲ್ಲಿದೆ ಮತ್ತು ಡಿಫಾಲ್ಟ್ ನಿಯಮ 32767 ರಲ್ಲಿದೆ, ಆದ್ದರಿಂದ ಡಿಫಾಲ್ಟ್ ಆದ್ಯತೆಯಿಂದ ಸೇರಿಸಿದ ನಿಯಮ ಪಟ್ಟಿಯ ಕೊನೆಗೆ ಹತ್ತಿರ ಬೀಳುತ್ತದೆ ಮತ್ತು ಬಹುತೇಕ ಎಲ್ಲದಕ್ಕೂ ಸೋಲುತ್ತದೆ.

ip rule show
ip rule add from 172.31.8.0/24 lookup 201 priority 1000
ip -4 route show table 201

ಸ್ಪಷ್ಟ ಆದ್ಯತೆ ಉದ್ದೇಶಿತ ಕ್ರಮವನ್ನು ಫೈಲ್‌ನಲ್ಲಿ ಮತ್ತು ವಿಮರ್ಶೆಯಲ್ಲಿ ಗೋಚರವಾಗಿಸುತ್ತದೆ. ಅದು ನಂತರದ ಸೇರ್ಪಡೆ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ನಿಯಮದ ಮುಂದೆ ಮೌನವಾಗಿ ನುಗ್ಗದಂತೆಯೂ ತಡೆಯುತ್ತದೆ, ಇದು ಸಂಬಂಧವಿಲ್ಲದ ಬದಲಾವಣೆಯ ನಂತರ ಕೆಲಸ ಮಾಡುತ್ತಿದ್ದ ನೀತಿ ನಿಲ್ಲುವ ಸಾಮಾನ್ಯ ಕಾರಣ.

ಅಪೂರ್ಣ ಕೋಷ್ಟಕಕ್ಕೆ ತೋರಿಸುವ ಹೊಂದುವ ನಿಯಮ ಇನ್ನೊಂದು ಬಲೆ. ಕೋಷ್ಟಕ 201 ರಲ್ಲಿ ಡಿಫಾಲ್ಟ್ ಮಾರ್ಗ ಇದ್ದು ಗಮ್ಯಸ್ಥಾನಕ್ಕೆ ಮಾರ್ಗ ಇಲ್ಲದಿದ್ದರೆ, ಪ್ಯಾಕೆಟ್ ಬಿಡಲಾಗುತ್ತದೆ ಅಥವಾ ತಪ್ಪು ಸ್ಥಳಕ್ಕೆ ಕಳುಹಿಸಲಾಗುತ್ತದೆ, ಮತ್ತು ನಿಯಮ ಪ್ರತ್ಯೇಕವಾಗಿ ಸಂಪೂರ್ಣ ಸರಿಯಾಗಿ ಕಾಣುತ್ತದೆ. ನಿಯಮವಲ್ಲ, ಕೋಷ್ಟಕ ಓದಿ. ನಿಯಮ ಒಂದು ಸೂಚಕ, ಮತ್ತು ಖಾಲಿ ಕೋಷ್ಟಕ ಏನೂ ಇಲ್ಲದ ಕಡೆಗಿನ ಸೂಚಕ.

ಹಿಂತಿರುಗುವ ಮಾರ್ಗ ಇನ್ನೂ ಇರಬೇಕು

ಮೂಲ ನೀತಿ ಒಂದು ನಿರ್ಗಮನವನ್ನು ಆಯ್ಕೆ ಮಾಡುತ್ತದೆ. ಅದು ಹಿಂತಿರುಗುವ ಮಾರ್ಗವನ್ನು ಸೃಷ್ಟಿಸುವುದಿಲ್ಲ. ಎರಡನೇ ಪೂಲ್ ಪಾಲುದಾರ ಸುರಂಗದ ಮೂಲಕ ಹೊರಟರೆ, ಪಾಲುದಾರ 172.31.8.0/24 ತಲುಪುವ ಬಗೆ ತಿಳಿದಿರಬೇಕು, ಗೇಟ್‌ವೇಗೆ ಹಿಂತಿರುಗುವ ಮಾರ್ಗದಿಂದ ಅಥವಾ ಈಗಾಗಲೇ ತಿಳಿದಿರುವ ಅನುವಾದಿತ ವಿಳಾಸಗಳನ್ನು ಸ್ವೀಕರಿಸುವ ಮೂಲಕ.

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

ನೀವು ಏನನ್ನು ಆಯ್ಕೆ ಮಾಡಿದರೂ, ಅದನ್ನು ಪೂಲ್ ವ್ಯಾಖ್ಯಾನದ ಪಕ್ಕದಲ್ಲಿ ಬರೆಯಿರಿ. ಕೇವಲ ಯಾರೋ ಒಬ್ಬರ ನೆನಪಿನಲ್ಲಿ ಮಾತ್ರ ಇರುವ ಹಿಂತಿರುಗುವ ಮಾರ್ಗವು ಪಾಲುದಾರ ಫೈರ್‌ವಾಲ್ ಬದಲಿಸುವವರೆಗೆ ಉಳಿಯುವ, ನಂತರ ಮತ್ತೆ ಕಟ್ಟಲು ಒಂದು ದಿನ ತೆಗೆದುಕೊಳ್ಳುವ ಸರಿಯಾದ ವಸ್ತು.

ನೀತಿಯಲ್ಲಿ ಗೇಟ್‌ವೇಯ ಸ್ವಂತ ಸುರಂಗವನ್ನು ಹಿಡಿಯಬೇಡಿ

ಕ್ಲೈಂಟ್‌ಗಳಿಗೆ ಬರೆಯುವ ನಿಯಮಗಳು ಗೇಟ್‌ವೇ ಉತ್ಪಾದಿಸುವ ಟ್ರಾಫಿಕ್‌ಗೂ ಅನ್ವಯವಾಗುತ್ತವೆ, ನೀವು ಅದನ್ನು ಹೊರಗಿಡದಿದ್ದರೆ. ಮಾರ್ಕ್ ಅಥವಾ ಔಟ್‌ಪುಟ್ ಇಂಟರ್‌ಫೇಸ್ ಆಧರಿಸಿದ ವಿಶಾಲ ನಿಯಮ ಗೇಟ್‌ವೇಯ ಸ್ವಂತ ಪಾಲುದಾರ ಸಂಪರ್ಕವನ್ನು ಹಿಡಿಯಬಹುದು, ಮತ್ತು ಆಗ ನೀತಿಯನ್ನು ಹೊತ್ತ ಸುರಂಗವೇ ನೀತಿಯಿಂದ ಮಾರ್ಗನಿರ್ಣಯಗೊಳ್ಳುತ್ತದೆ. ಇದು ಸೇವಾದಾತನ ದೋಷದಂತೆ ಕಾಣುವ ಲೂಪ್ ಅಥವಾ ವಿರಾಮವನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ.

ವಿನ್ಯಾಸ ಅನುಮತಿಸಿದಷ್ಟು ಪ್ರತಿ ನಿಯಮವನ್ನು ಸಂಕುಚಿತಗೊಳಿಸಿ: ಮೂಲ ಪ್ರಿಫಿಕ್ಸ್, ಪ್ರವೇಶ ಇಂಟರ್‌ಫೇಸ್ ಮತ್ತು ಬೆಂಬಲವಿದ್ದಲ್ಲಿ ಕ್ಲೈಂಟ್ ಪ್ಯಾಕೆಟ್‌ಗಳು ಮಾತ್ರ ಹೊತ್ತ ಮಾರ್ಕ್. ನಂತರ ಪ್ರತಿ ನಿಯಮ ಬದಲಾವಣೆಯ ನಂತರ ಗೇಟ್‌ವೇಯ ಸ್ವಂತ ಸಂಪರ್ಕವನ್ನು ಪರೀಕ್ಷಿಸಿ, ಏಕೆಂದರೆ ದೋಷ ಸ್ವಯಂ-ಉಲ್ಲೇಖಿತ ಮತ್ತು ಕ್ಲೈಂಟ್ ಪರೀಕ್ಷೆಯಲ್ಲಿ ಕಾಣಿಸುವುದಿಲ್ಲ.

ip-rule ಕೈಪಿಡಿ ಪುಟ ಆಯ್ಕೆಗಾರ ಮತ್ತು ಆದ್ಯತೆಯ ಅರ್ಥವನ್ನು ದಾಖಲಿಸುತ್ತದೆ. ಅದನ್ನು ಪ್ರತಿ ಪೂಲ್‌ನ ಲುಕಪ್ ಪರೀಕ್ಷೆಯೊಂದಿಗೆ ಸೇರಿಸಿ, ವಿನ್ಯಾಸ ಪರಿಶೀಲನೀಯವಾಗುತ್ತದೆ, ಇದು ಒಂದು ವರ್ಷ ನಿಲ್ಲುವ ನೀತಿ ಮಾರ್ಗನಿರ್ಣಯ ಮತ್ತು ಎಲ್ಲರೂ ಮುಟ್ಟಲು ಹೆದರುವ ಮಾರ್ಗನಿರ್ಣಯದ ನಡುವಿನ ವ್ಯತ್ಯಾಸ.

ಸಂಬಂಧಿತ ಲೇಖನಗಳು