ಪೋರ್ಟ್ 80 ಮತ್ತು 443 ನಿಯಮಗಳು ಬ್ರೌಸರ್ ಅನ್ನು VPN ಮೂಲಕ ಕಳುಹಿಸುವುದಿಲ್ಲ

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

ನಿಯಮವು ಸಾಗಣೆ ವರ್ಗವನ್ನು ವಿವರಿಸುತ್ತದೆ, ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಅಲ್ಲ

Linux ನಲ್ಲಿ, ಗಮ್ಯ-ಪೋರ್ಟ್ ಹೊಂದಾಣಿಕೆ TCP ಶೀರ್ಷಿಕೆಯನ್ನು ಪರಿಶೀಲಿಸುತ್ತದೆ ಮತ್ತು ಅದರ ಮೇಲೆ ಏನೂ ಇಲ್ಲ. ಆ ಪ್ಯಾಕೆಟ್ಗಳನ್ನು ಗುರುತಿಸಿ ನೀತಿ-ಮಾರ್ಗದಿಂದ ನಿರ್ದೇಶಿಸುವುದು ದಾಖಲಿಸಿದಂತೆಯೇ ಕೆಲಸ ಮಾಡುತ್ತದೆ, ಮತ್ತು ಆ ಯಂತ್ರಗಳಲ್ಲಿ ಯಾವುದಕ್ಕೂ ಪೇಲೋಡ್ನ ಅರ್ಥ ಏನು ಅಥವಾ ಯಾವ ಪ್ರಕ್ರಿಯೆ ಅದನ್ನು ಕಳುಹಿಸಿತು ಎಂದು ತಿಳಿದಿಲ್ಲ. ಗುರುತು ಪ್ಯಾಕೆಟ್ಗೆ ಜೋಡಿಸಿದ ಸಂಖ್ಯೆ, ಅಪ್ಲಿಕೇಶನ್ಗೆ ಜೋಡಿಸಿದ ಗುರುತು ಅಲ್ಲ.

nft add rule inet mangle output tcp dport { 80, 443 } meta mark set 0x1
ip rule add fwmark 0x1 table 100
ip route add default dev wg0 table 100

ತಕ್ಷಣ ಎರಡು ಪರಿಣಾಮಗಳು ಬರುತ್ತವೆ. TCP 443 ಗೆ ಸಂಪರ್ಕಿಸುವ ಸಾಫ್ಟ್ವೇರ್ ಅಪ್ಡೇಟರ್ ಬ್ರೌಸರ್ನಂತೆಯೇ ವರ್ತನೆ ಪಡೆಯುತ್ತದೆ, ಅದು ಸರಿಯಾಗಿರಬಹುದು ಅಥವಾ ಮುಂದಿನ ಅಪ್ಡೇಟ್ ಚಕ್ರಕ್ಕೆ ಕಾಯುತ್ತಿರುವ ಅಡಚಣೆಯಾಗಿರಬಹುದು. ಮತ್ತು ಬೇರೆ ಪೋರ್ಟ್ನಲ್ಲಿ, ಹೇಳೋಣ 8443, ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಪ್ರಕಟಿಸಿದ ವೆಬ್ ಸೇವೆ ನಿಯಮದ ಸಂಪೂರ್ಣ ಹೊರಗೆ ಬೀಳುತ್ತದೆ, ಆದರೂ ಅದು ಇನ್ನೂ ಬಳಕೆದಾರರಿಗೆ ಮುಖ್ಯವಾಗಿದ್ದ ವೆಬ್ ಸಂಚಾರವೇ.

ಅಗತ್ಯವು ನಿಜವಾಗಿ ಆ ಪೋರ್ಟ್ಗಳ ಬಗ್ಗೆ ಇದ್ದಾಗ ಸಂಖ್ಯೆಗಳು ಕಾನೂನುಬದ್ಧ ಆಯ್ಕೆಗಾರರು. ಟಿಕೆಟ್ನಲ್ಲಿ «ಬ್ರೌಸರ್» ಎಂದು ಬರೆದು ನಿಯಮಗಳ ಗುಂಪಿನಲ್ಲಿ ಪೋರ್ಟ್ ಶ್ರೇಣಿಯನ್ನು ಜಾರಿಗೆ ತಂದಾಗ ಅವು ಕಲ್ಪನೆಯಾಗುತ್ತವೆ. ಈ ಅಂತರವು ದಾಖಲೀಕರಣದ ಸೂಕ್ಷ್ಮತೆ ಅಲ್ಲ. ಇದು ಪರಿಶೀಲನೆಯಲ್ಲಿ ಸಮರ್ಥಿಸಬಹುದಾದ ನಿಯಮ ಮತ್ತು ಯಾರೂ ಪರೀಕ್ಷಿಸಲಾಗದ ನಿಯಮದ ನಡುವಿನ ವ್ಯತ್ಯಾಸ.

HTTP/3 ನಿಮ್ಮ TCP ನಿಯಮವನ್ನು ಸದ್ದಿಲ್ಲದೆ ಬಿಟ್ಟುಹೋಗುತ್ತದೆ

HTTP/3 QUIC ಮೇಲೆ ಚಲಿಸುತ್ತದೆ, ಮತ್ತು QUIC ಅನ್ನು UDP ನಲ್ಲಿ ಸಾಗಿಸಲಾಗುತ್ತದೆ. TCP ಗೆ ಮಾತ್ರ ಹೊಂದುವ ನಿಯಮವು ಅದನ್ನು ನೋಡಲಾರದು, ಆದ್ದರಿಂದ ನಿಮ್ಮ ಪರೀಕ್ಷಾ ಪುಟವನ್ನು ಪೂರೈಸುವ ಅದೇ ಬ್ರೌಸರ್ ನಂತರದ ವಿನಂತಿಯನ್ನು UDP ಮೂಲಕ ಕಳುಹಿಸಿ ಸುರಂಗವನ್ನು ಬಳಸದೆ ಹೋಗಬಹುದು, ಯಾರೂ ಸೆಟ್ಟಿಂಗ್ ಬದಲಿಸದೆ. RFC 9114 HTTP/3 ಅನ್ನು QUIC ಆಧಾರಿತ ಪ್ರೋಟೋಕಾಲ್ ಎಂದು ವಿವರಿಸುತ್ತದೆ, ಮತ್ತು ಸಾಮಾನ್ಯ ನಿಯೋಜನೆಯಲ್ಲಿ QUIC ಡೀಫಾಲ್ಟ್ ಪೋರ್ಟ್ 443 ಇರುವ UDP ಬಳಸುತ್ತದೆ.

ನಿರ್ದಿಷ್ಟ ಬ್ರೌಸರ್ HTTP/3 ಪ್ರಯತ್ನಿಸುತ್ತದೆಯೇ ಎಂಬುದು ಅದರ ಸಂರಚನೆ, ಸೈಟ್ ಮತ್ತು ಹಿಂದಿನ ಪ್ರಯತ್ನ ಯಶಸ್ವಿಯಾಯಿತೇ ಎಂಬುದನ್ನು ಅವಲಂಬಿಸಿದೆ. ಇದು ಅದರ ಬಗ್ಗೆ ನೆನಪಿನಿಂದ ತರ್ಕಿಸಲು ಕೆಟ್ಟ ವಿಷಯವಾಗಿಸುತ್ತದೆ. ಬದಲಾಗಿ ಸಾಧನವನ್ನೇ ಕೇಳಿ:

curl --http3 -sS -o /dev/null -w '%{http_version} %{time_total}\n' https://example.com
ss -tunp | grep -E ':443\b'

curl ಸಾಲು ಸಂಧಾನವಾದ ಆವೃತ್ತಿಯನ್ನು ಮುದ್ರಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ 3 UDP ಮಾರ್ಗ ಬಳಸಲಾಗಿದೆ ಎಂದು ದೃಢೀಕರಿಸುತ್ತದೆ. ನಂತರ ಸಾಕೆಟ್ ಪಟ್ಟಿ ಆ ಸಂಪರ್ಕವು ಸುರಂಗದ ಇಂಟರ್ಫೇಸ್ಗೆ ಅಥವಾ ಭೌತಿಕದ್ದಕ್ಕೆ ಬಂಧಿಸಲಾಗಿದೆಯೇ ಎಂದು ತೋರಿಸುತ್ತದೆ. ನಿಮ್ಮ curl ಬಿಲ್ಡ್ನಲ್ಲಿ HTTP/3 ಇಲ್ಲದಿದ್ದರೆ, ಫ್ಲ್ಯಾಗ್ ಸದ್ದಿಲ್ಲದೆ ಹಿಂದೆ ಸರಿಯುವ ಬದಲು ಗಟ್ಟಿಯಾಗಿ ವಿಫಲವಾಗುತ್ತದೆ, ಅದು ಅದರದೇ ಸಣ್ಣ ಕರುಣೆ.

DNS ನೀವು ತೆಗೆದುಕೊಳ್ಳಬೇಕಾದ ಪ್ರತ್ಯೇಕ ನಿರ್ಣಯ

ವೆಬ್ ಸಂಚಾರಕ್ಕಾಗಿ ಪೋರ್ಟ್ ನಿಯಮವು ಹೆಸರು ಪರಿಹಾರದ ಬಗ್ಗೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ. ಬ್ರೌಸರ್ ಸಿಸ್ಟಮ್ ಪರಿಹಾರಕ, ಬ್ರೌಸರ್ನ ಒಳಗೆ ಸಂರಚಿಸಿದ ಪರಿಹಾರಕ, ಅಥವಾ ಕೊನೆಯದಾಗಿ ಸಂಪರ್ಕಿಸಿದ್ದು ತಳ್ಳಿದ ಒಂದನ್ನು ಬಳಸಬಹುದು. ಅವುಗಳಲ್ಲಿ ಪ್ರತಿಯೊಂದೂ ನಿಮ್ಮ ನಿಯಮ ಆಯ್ಕೆ ಮಾಡುವ ಮಾರ್ಗಕ್ಕಿಂತ ಬೇರೆ ಮಾರ್ಗದಲ್ಲಿ ಪ್ರಶ್ನೆಗಳನ್ನು ಕಳುಹಿಸಬಹುದು, ಇದು ಪರಿಚಿತ ಸೀಳಿಕೆಯನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ: ಪುಟ ಲೋಡ್ ಆಗುತ್ತದೆ, ಹೆಸರು ನೀವು ನಿರೀಕ್ಷಿಸದ ಜಾಗದಲ್ಲಿ ಪರಿಹಾರವಾಗುತ್ತದೆ, ಮತ್ತು ಒಳಗಿನ ಸೈಟ್ ಸಾರ್ವಜನಿಕ ವಿಳಾಸಕ್ಕೆ ಪರಿಹಾರವಾಗುತ್ತದೆ ಅಥವಾ ಲವಲೇಶವೂ ಆಗುವುದಿಲ್ಲ.

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

ನಂತರ ಪುಟದಿಂದ ಅಲ್ಲ, ಪರಿಹಾರಕದಿಂದ ಪರಿಶೀಲಿಸಿ:

resolvectl query intranet.example.internal
resolvectl status | grep -A3 'Current DNS Server'

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

ಮೂರು ಗಡಿಗಳು, ಮೂರು ಬೇರೆ ಬೇರೆ ವ್ಯವಸ್ಥೆಗಳು

ನಿಮಗೆ ಬೇಕಾದ ಗಡಿಗೆ ಹೆಸರಿಸಿದ ಕ್ಷಣದಲ್ಲೇ ಬಹುಪಾಲು ಗೊಂದಲ ಮಾಯವಾಗುತ್ತದೆ. ಅವು ಪರಸ್ಪರ ಬದಲಾಯಿಸಲಾಗದವು, ಮತ್ತು ಸುರಂಗ ಕುಸಿದಾಗ ಪ್ರತಿಯೊಂದಕ್ಕೂ ಬೇರೆ ವೈಫಲ್ಯ ವಿಧಾನವಿದೆ.

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

ಯಾವ ಸಾಲು ಅನ್ವಯವಾದರೂ, ಸುರಂಗ ಬಿದ್ದಾಗ ಏನಾಗಬೇಕು ಎಂದು ಬರೆಯಿರಿ. ಇಂಟರ್ಫೇಸ್ನೊಂದಿಗೆ ಮಾಯವಾಗುವ ಗುರುತು ಆಧಾರಿತ ಮಾರ್ಗ ಸಾಮಾನ್ಯವಾಗಿ ಭೌತಿಕ ಡೀಫಾಲ್ಟ್ ಮಾರ್ಗಕ್ಕೆ ಹಿಂತಿರುಗುತ್ತದೆ, ಅದು fail-open ವರ್ತನೆ. ಅದು ಬ್ರೌಸಿಂಗ್ಗೆ ಸ್ವೀಕಾರಾರ್ಹ ಮತ್ತು ಬೇರೆ ಎಲ್ಲದಕ್ಕೂ ಅಲ್ಲದಿರಬಹುದು, ಮತ್ತು ಅದು ನಿರ್ಣಯ, ಅನುಷ್ಠಾನದ ವಿವರ ಅಲ್ಲ.

ನೀವು ಆವರಿಸುತ್ತೇವೆ ಎಂದು ಹೇಳುವ ಹರಿವುಗಳನ್ನು ಪರೀಕ್ಷಿಸಿ

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

ip route get 203.0.113.40
curl -sS -o /dev/null -w 'v4 %{http_version} %{remote_ip}\n' https://example.com
nft list ruleset | grep -A2 'dport'

ಮಾರ್ಗ ಹುಡುಕಾಟವು ಗಮ್ಯವು ನಿಜವಾಗಿ ಯಾವ ಇಂಟರ್ಫೇಸ್ ಬಳಸುತ್ತದೆ ಎಂದು ಹೇಳುತ್ತದೆ, ಮತ್ತು ಇದೇ ಹೆಚ್ಚಿನ ವರದಿಗಳು ತಪ್ಪಾಗಿ ಹೇಳುವ ಸತ್ಯ. curl ಸಾಲು ಸಂಧಾನವಾದ ಆವೃತ್ತಿ ಮತ್ತು ವಿಳಾಸ ಕುಟುಂಬವನ್ನು ದೃಢೀಕರಿಸುತ್ತದೆ. ನಿಯಮಗಳ ಗುಂಪಿನ ಡಂಪ್ ಪರೀಕ್ಷೆಯ ಸಮಯದಲ್ಲಿ ಸೇರಿಸಿ ಮಿತಿಗೊಳಿಸಲು ಮರೆತ ನಿಯಮವನ್ನು ಹಿಡಿಯುತ್ತದೆ, ಮತ್ತು ಹೀಗೆ ತಾತ್ಕಾಲಿಕ ಗುರುತು ಶಾಶ್ವತ fail-open ರೂಟಿಂಗ್ ಆಗುತ್ತದೆ.

ಮೂರೂ ಔಟ್ಪುಟ್ಗಳನ್ನು ಸಮಯ ಮುದ್ರೆಯೊಂದಿಗೆ ದಾಖಲಿಸಿ ಮತ್ತು ಬದಲಾವಣೆಯೊಂದಿಗೆ ಇರಿಸಿ. ನಂತರ ಯಾರಾದರೂ «VPN ಇಂಟ್ರಾನೆಟ್ ಮುರಿಯಿತು» ಎಂದು ವರದಿ ಮಾಡಿದಾಗ, ಉದ್ದೇಶಿತ ಮತ್ತು ಜಾರಿಗೊಳಿಸಿದ ಗಡಿಯ ವ್ಯತ್ಯಾಸ ಆ ದಾಖಲೆಯಲ್ಲಿ ಕಾಣುತ್ತದೆ, ಮತ್ತು ಸರಿಪಡಿಸುವಿಕೆ ನಿಯಮ ಬದಲಾವಣೆಯಾಗುತ್ತದೆ, ವಾದವಲ್ಲ.