VPN ಹೊರಗೆ ಕೇವಲ ಒಂದು ಸ್ಥಳೀಯ ವೆಬ್ ಸೇವೆಯನ್ನು ಪೋರ್ಟ್ ಪ್ರಕಾರ ರೂಟ್ ಮಾಡಿ

ಒಂದು ಹೋಸ್ಟ್ ಸೇವೆ ಭೌತಿಕ ಅಪ್ಲಿಂಕ್ ಮೂಲಕ ಇಂಟರ್ನೆಟ್ಗೆ ಉತ್ತರಿಸಬೇಕು, ಯಂತ್ರದಲ್ಲಿನ ಉಳಿದೆಲ್ಲವೂ ಸುರಂಗವನ್ನೇ ಬಳಸುತ್ತಿರಬೇಕು. ನೀತಿ-ಆಧಾರಿತ ರೂಟಿಂಗ್ ಈ ಹೊರೆಯನ್ನು ಹೊರಬಲ್ಲದೇ ಎಂಬುದನ್ನು ಮೂರು ಷರತ್ತುಗಳು ನಿರ್ಧರಿಸುತ್ತವೆ, ಮತ್ತು ನಿಯಮ ಬರೆಯುವ ಮೊದಲು ಪ್ರತಿಯೊಂದನ್ನು ಪರಿಶೀಲಿಸುವುದು ಅಗ್ಗ. ಸೇವೆ DNAT ಅಥವಾ ಮುಂದಕ್ಕೆ ರವಾನಿಸಿದ ಪೋರ್ಟ್ನ ಹಿಂದೆ ಅಲ್ಲ, ಈ ಹೋಸ್ಟ್ನಲ್ಲೇ ಕೊನೆಗೊಳ್ಳಬೇಕು, VPN ನ ಸ್ವಂತ ನಿಯಮಗಳು ವಿನಾಯಿತಿಗೆ ಅನುಮತಿ ನೀಡಬೇಕು, ಮತ್ತು ನೀವು ವಿನಂತಿಯನ್ನಲ್ಲ, ಉತ್ತರವನ್ನು ಹೊಂದಿಸಬೇಕು. ಮೂರರಲ್ಲಿ ಯಾವುದಾದರೂ ವಿಫಲವಾದರೆ ಕೆಳಗಿನ ಆಜ್ಞೆಗಳು ದೋಷವಿಲ್ಲದೆ ಲೋಡ್ ಆಗುತ್ತವೆ, ಆದರೆ ಉಪಯುಕ್ತವಾದದ್ದನ್ನು ಮಾಡುವುದಿಲ್ಲ.

ನಿಯಮ ಬರೆಯುವ ಮೊದಲು ಮೂರು ಷರತ್ತುಗಳನ್ನು ಪರಿಶೀಲಿಸಿ

DNAT ಮೂಲಕ ಪೋರ್ಟ್ ಪ್ರಕಟಿಸುವ ಕಂಟೇನರ್, ಅಥವಾ ಪೋರ್ಟ್ ಫಾರ್ವರ್ಡಿಂಗ್ನ ಹಿಂದೆ ಕುಳಿತಿರುವ ಸರ್ವರ್, ಈ ಹೋಸ್ಟ್ನಲ್ಲಿ ಹುಟ್ಟದ ಪ್ಯಾಕೆಟ್ಗಳನ್ನು ಉತ್ಪಾದಿಸುತ್ತದೆ. ಆ ಪ್ಯಾಕೆಟ್ಗಳು ಫಾರ್ವರ್ಡ್ ಆಗುತ್ತವೆ, ಆದ್ದರಿಂದ ಹೋಸ್ಟ್-ಸ್ಥಳೀಯ ಇನ್ಪುಟ್ ಆಧರಿಸಿದ ನಿಯಮ ಅವನ್ನು ಎಂದಿಗೂ ನೋಡುವುದಿಲ್ಲ ಮತ್ತು ಸಂಚಾರ ಡೀಫಾಲ್ಟ್ ಮಾರ್ಗವನ್ನೇ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ. ಮುಂದುವರಿಯುವ ಮೊದಲು ಸೇವೆ ನಿಜವಾಗಿ ಎಲ್ಲಿ ಚಲಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ದೃಢೀಕರಿಸಿ, ಏಕೆಂದರೆ ಜನರು ಹೆಚ್ಚಾಗಿ ತಪ್ಪು ಮಾಡುವ ಷರತ್ತು ಇದೇ.

ಎರಡನೇ ಷರತ್ತು ನೀತಿ, ಯಂತ್ರಶಾಸ್ತ್ರವಲ್ಲ. ಸುರಂಗವನ್ನು ಬಳಸದ ಮಾರ್ಗವೆಲ್ಲವೂ ಸುರಂಗದ ಉದ್ದೇಶಕ್ಕೆ ವಿನಾಯಿತಿ, ಮತ್ತು ನಿರ್ವಹಿತ ಹೋಸ್ಟ್ನಲ್ಲಿ ಆ ನಿರ್ಣಯ ನೀತಿಯ ಮಾಲೀಕನದು, ಟೈಮ್ಔಟ್ ಡೀಬಗ್ ಮಾಡುವವನದಲ್ಲ.

ಉತ್ತರವನ್ನು ಹೊಂದಿಸಿ, ಕ್ಲೈಂಟ್ನ ಗಮ್ಯ ಪೋರ್ಟ್ ಅಲ್ಲ

TCP 443 ರಲ್ಲಿ ಕೇಳುತ್ತಿರುವ ಸರ್ವರ್ನ ಉತ್ತರ ಮೂಲ ಪೋರ್ಟ್ 443 ಜೊತೆಗೆ ಹೋಸ್ಟ್ ಬಿಡುತ್ತದೆ. ಅದೇ ಹೋಸ್ಟ್ನ ಬ್ರೌಸರ್ ದೂರದ HTTPS ಸೈಟ್ಗೆ ಸಂಪರ್ಕಿಸುವಾಗ ತಾತ್ಕಾಲಿಕ ಮೂಲ ಪೋರ್ಟ್ ಮತ್ತು ಗಮ್ಯ ಪೋರ್ಟ್ 443 ಕಳುಹಿಸುತ್ತದೆ. ಎರಡೂ ಪೋರ್ಟ್ 443 ಸಂಚಾರ ಮತ್ತು ಅವುಗಳಲ್ಲಿ ಒಂದೇ WAN ಕೋಷ್ಟಕವನ್ನು ತೆಗೆದುಕೊಳ್ಳಬೇಕು, ಆದ್ದರಿಂದ ಗಮ್ಯ-ಪೋರ್ಟ್ ಹೊಂದಾಣಿಕೆ ತಪ್ಪು ಅರ್ಧವನ್ನು ಹಿಡಿಯುತ್ತಿತ್ತು.

ಉತ್ತರದ ದಿಕ್ಕೇ ನೀವು ಪ್ರತ್ಯೇಕಿಸಬಹುದಾದದ್ದು. ಮೂಲ ಪೋರ್ಟ್ ಹೊಂದಿಸಿ, ನಿಯಮವನ್ನು ಸ್ಥಳೀಯವಾಗಿ ಉತ್ಪಾದಿತ ಪ್ಯಾಕೆಟ್ಗಳಿಗೆ ಸೀಮಿತಗೊಳಿಸಿ, ಮತ್ತು ನಿಯಮ ಬ್ರೌಸರ್ನ ವಿನಂತಿಗಳನ್ನು ಮುಟ್ಟದೆ ಸೇವೆಯ ಸ್ವಂತ ಉತ್ತರಗಳನ್ನು ಒಳಗೊಳ್ಳುತ್ತದೆ.

ನಿಯಮ ಅದನ್ನು ಸೂಚಿಸುವ ಮೊದಲು ಸಂಪೂರ್ಣ ರಿಟರ್ನ್ ಕೋಷ್ಟಕವನ್ನು ನಿರ್ಮಿಸಿ

ಖಾಲಿ ಕೋಷ್ಟಕ ಎಂದರೆ ಮಾರ್ಗವಿಲ್ಲ, ಅದು ಮುರಿದ ನೀತಿಗಿಂತ ಮುರಿದ ಸೇವೆಯಂತೆ ಕಾಣುತ್ತದೆ. ಮೊದಲು ಅದನ್ನು ತುಂಬಿಸಿ, ಹೋಸ್ಟ್ನಲ್ಲಿ ಬೇರೆ ಯಾವುದೂ ಕ್ಲೇಮ್ ಮಾಡದ ಕೋಷ್ಟಕ ಸಂಖ್ಯೆ ಮತ್ತು ಆದ್ಯತೆಯೊಂದಿಗೆ:

ip -4 route add table 100 192.0.2.0/24 dev eth0
ip -4 route add table 100 default via 192.0.2.1 dev eth0
ip -4 rule add priority 1000 iif lo ipproto tcp sport 443 lookup 100

ಸಂಖ್ಯೆಗಳನ್ನು ನಕಲಿಸದೆ ಜೀವಂತ ಹೋಸ್ಟ್ನಿಂದ ಓದಿ. ip -4 rule show ಯಾವ ಆದ್ಯತೆಗಳು ತೆಗೆದುಕೊಳ್ಳಲ್ಪಟ್ಟಿವೆ ಎಂದು ಹೇಳುತ್ತದೆ, ಮತ್ತು ಈಗಾಗಲೇ ಇರುವ ಆದ್ಯತೆಗೆ ನಿಯಮ ಸೇರಿಸುವುದು ಪ್ರತ್ಯೇಕವಾಗಿ ಸರಿ ಕಾಣುವ ಎರಡು ನಿಯಮಗಳ ಕ್ರಮವನ್ನು ಸದ್ದಿಲ್ಲದೆ ಬದಲಿಸುತ್ತದೆ.

ಇಲ್ಲಿ ನಿಜವಾದ ಕೆಲಸವನ್ನು ಎರಡು ಆಯ್ಕೆಗಾರರು ಮಾಡುತ್ತಾರೆ. iif lo ಎಂದರೆ ಹೋಸ್ಟ್ ಸ್ವತಃ ಉತ್ಪಾದಿಸಿದ ಪ್ಯಾಕೆಟ್ಗಳನ್ನು ಕರ್ನಲ್ ವರದಿ ಮಾಡುವ ರೀತಿ, ಆದ್ದರಿಂದ ನಿಯಮ ಹೊರಗಿನಿಂದ ಬರುವ ಫಾರ್ವರ್ಡ್ ಸಂಚಾರವನ್ನು ಆಕಸ್ಮಿಕವಾಗಿ ಹಿಡಿಯಲಾರದು. ipproto tcp sport 443 ಅದನ್ನು ಒಂದು ಸಾರಿಗೆ ಮತ್ತು ಒಂದು ಪೋರ್ಟ್ಗೆ ಸಂಕುಚಿಸುತ್ತದೆ, ಅದು ಅಗತ್ಯವು ಅನುಮತಿಸುವಷ್ಟು ಬಿಗಿಯಾಗಿದೆ. ಪ್ರೋಟೋಕಾಲ್ ಆಯ್ಕೆಗಾರವನ್ನು ತೆಗೆದರೆ ನಿಯಮ UDP 443 ಅನ್ನೂ ಹಿಡಿಯುತ್ತದೆ, ಅದು ಬೇರೆ ವರ್ತನೆಯ ಬೇರೆ ಸೇವೆ.

ಖಾಸಗಿ ಉತ್ತರಗಳನ್ನು ಸುರಂಗದ ಒಳಗೇ ಇರಿಸಿ

ಅದೇ ಶ್ರೋತೃವು ಖಾಸಗಿ ಬದಿಯ ಕ್ಲೈಂಟ್ಗಳಿಗೂ ಉತ್ತರಿಸಿದರೆ, ಕೋಷ್ಟಕ 100 ರಲ್ಲಿ ಎಲ್ಲವನ್ನೂ ಹಿಡಿಯುವ WAN ಡೀಫಾಲ್ಟ್ ಆ ಉತ್ತರಗಳನ್ನು ಅಪ್ಲಿಂಕ್ ಮೂಲಕ ಹಿಂತಿರುಗಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತದೆ. WAN ಡೀಫಾಲ್ಟ್ ಅನುಸರಿಸಬಾರದ ಖಾಸಗಿ ಪೂರ್ವಪ್ರತ್ಯಯಗಳನ್ನು ಸೇರಿಸಿ, ಅಥವಾ ಅವನ್ನು ಮುಂದಿನ ನೀತಿ ನಿಯಮಕ್ಕೆ ಬೀಳಲು ಬಿಡಿ:

ip -4 route add table 100 throw 10.90.0.0/24

throw ಮಾರ್ಗವು ಈ ಕೋಷ್ಟಕದಲ್ಲಿ ಹುಡುಕಾಟವನ್ನು ಮುಗಿಸಿ ಪ್ಯಾಕೆಟ್ ಅನ್ನು ನಿಯಮಗಳ ಪಟ್ಟಿಗೆ ಹಿಂತಿರುಗಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಮುಂದಿನ VPN ನೀತಿಗೆ ತನ್ನ ಅವಕಾಶ ಸಿಗುತ್ತದೆ. ಅದು ಸ್ವತಃ ಸುರಂಗಕ್ಕೆ ಏನನ್ನೂ ರೂಟ್ ಮಾಡುವುದಿಲ್ಲ, ಮತ್ತು ಮುಂದಿನ ಯಾವುದೇ ನಿಯಮಕ್ಕೆ ಹೊಂದುವ ಮಾರ್ಗವಿಲ್ಲದಿದ್ದರೆ ಪ್ಯಾಕೆಟ್ ಹೇಗಿದ್ದರೂ ವಿಫಲವಾಗುತ್ತದೆ; throw ಸರಿಪಡಿಸುವಿಕೆ ಎಂದು ಭಾವಿಸದೆ ಮುಂದಿನ ನೀತಿಯನ್ನು ಪರಿಶೀಲಿಸಿ.

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

TCP, ನಂತರ QUIC, ನಂತರ ರೀಬೂಟ್ ಪರೀಕ್ಷಿಸಿ

ಅಧಿಕೃತ ಬಾಹ್ಯ ಕ್ಲೈಂಟ್ನಿಂದ ಒಂದು ಮತ್ತು ಖಾಸಗಿ ಬದಿಯಿಂದ ಒಂದು ಸಂಪರ್ಕ ತೆರೆಯಿರಿ, ನಂತರ ನಿಜವಾದ ವಿಳಾಸ ಮತ್ತು ಪೋರ್ಟ್ಗಳೊಂದಿಗೆ ಉತ್ತರ-ಹುಡುಕಾಟವನ್ನು ಪರಿಶೀಲಿಸಿ. ಬಾಹ್ಯ ಉತ್ತರ ಕೋಷ್ಟಕ 100 ತೆಗೆದುಕೊಂಡು ಖಾಸಗಿ ಉತ್ತರ ತೆಗೆದುಕೊಳ್ಳದಿದ್ದರೆ, ನೀತಿ ನೀವು ಕೇಳಿದ್ದನ್ನೇ ಮಾಡುತ್ತಿದೆ.

HTTP/3 ಅನ್ನು UDP ಮೇಲೆ ನೀಡಲಾಗುತ್ತದೆ ಮತ್ತು TCP ನಿಯಮದಿಂದ ಹೊಂದಿಸಲ್ಪಡುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ QUIC ಶ್ರೋತೃವಿಗೆ ತನ್ನದೇ ಆಯ್ಕೆಗಾರ ಬೇಕು, ಇಲ್ಲದಿದ್ದರೆ HTTPS ಕೆಲಸ ಮಾಡುತ್ತಿರುವಾಗಲೂ ಅದು ಸುರಂಗವನ್ನೇ ಬಳಸುತ್ತದೆ. ನೀವು ನೆಲೆಗೊಳ್ಳುವ ನಿಯಮಗಳನ್ನು ಇಂಟರ್ಫೇಸ್ ಹೊಂದಿರುವ ಘಟಕದಲ್ಲಿ ಉಳಿಸಿ, ಮತ್ತು ಮತ್ತೆ ಸಂಪರ್ಕಿಸಿದ ನಂತರ ಅಥವಾ DHCP ನವೀಕರಣದ ನಂತರ ಅವನ್ನು ದೃಢೀಕರಿಸಿ. ರೀಬೂಟ್ ನಂತರ ಸ್ಪರ್ಧಿ ನಿರ್ವಾಹಕ ರನ್ಟೈಮ್ ಮಾರ್ಗವನ್ನು ತೆಗೆದರೆ, ಅದು ಮೂಲದಲ್ಲಿ ಸರಿಪಡಿಸಬೇಕಾದ ಮಾಲೀಕತ್ವದ ಸಮಸ್ಯೆ, ಮೇಲೆ ಹೆಚ್ಚು ವಿಶಾಲ NAT ನಿಯಮಗಳನ್ನು ಸೇರಿಸುವ ಕಾರಣವಲ್ಲ.