OpenVPN UDP ಗಾಗಿ Nginx stream ರಿಲೇ: ಏನು ಬದಲಾಗುತ್ತದೆ

UDP, HTTP location ಗೆ ಸೇರುವುದಿಲ್ಲ. ಅದನ್ನು stream ಪದರಕ್ಕೆ ಸರಿಸಿ, VPN ಗಾಗಿ ಸೆಷನ್ ಸಮಯ ಮಿತಿಯನ್ನು ನಿಗದಿಪಡಿಸಿ, ಮತ್ತು ಮೂಲವಾಗಿ ಪ್ರಾಕ್ಸಿಯನ್ನು ನಿರೀಕ್ಷಿಸಿ.

ನಿಮ್ಮ ಕ್ಲೈಂಟ್ UDP ಗೆ ಹೊಂದಿಸಲಾಗಿದೆ, Nginx ಸರ್ವರ್‌ನಲ್ಲಿ VPN ಪೋರ್ಟ್‌ಗೆ ತೋರಿಸುವ location ಬ್ಲಾಕ್ ಇದೆ, ಮತ್ತು ಏನೂ ಬರುವುದಿಲ್ಲ. ಇದು ನಿರೀಕ್ಷಿತ: HTTP location ಯಾವುದೇ UDP ಡೇಟಾಗ್ರಾಮ್ ಸಾಗಿಸಲಾರದು, ಮುಂಭಾಗಕ್ಕೆ ಯಾವ ಹೆಸರು ಕೊಟ್ಟರೂ. ಇದಕ್ಕಾಗಿ Nginx ಗೆ stream ಆಲಿಸುವವರು ಬೇಕು, ಮತ್ತು ಸಂರಚನೆಯನ್ನು ಅಲ್ಲಿಗೆ ಸರಿಸಿದ ನಂತರ ಸೆಷನ್ ಉಳಿಯುತ್ತದೆಯೇ ಎಂಬುದನ್ನು ವಿವರಗಳ ಎರಡನೇ ಗುಂಪು ನಿರ್ಧರಿಸುತ್ತದೆ.

ಪ್ರಾಕ್ಸಿ ಪದರ ವಿಳಾಸಕ್ಕಿಂತ ಮೊದಲು ಬರುತ್ತದೆ

Nginx ನ stream ಮಾಡ್ಯೂಲ್ HTTP ಅನ್ನು ಪಾರ್ಸ್ ಮಾಡದೆಯೇ TCP ಮತ್ತು UDP ಅನ್ನು ಪ್ರಾಕ್ಸಿ ಮಾಡುತ್ತದೆ. ಅದರ HTTP ಮಾಡ್ಯೂಲ್ ವಿನಂತಿ ಸಾಲು, ಹೆಡರ್ ಮತ್ತು ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ನಿರೀಕ್ಷಿಸುತ್ತದೆ, ಅವುಗಳಲ್ಲಿ ಯಾವುದೂ ಸ್ಥಳೀಯ OpenVPN ಡೇಟಾಗ್ರಾಮ್‌ನಲ್ಲಿಲ್ಲ. ಆದ್ದರಿಂದ ಪದರವನ್ನು ಆಯ್ಕೆ ಮಾಡುವುದು ಮೊದಲ ನಿರ್ಧಾರ, ಮತ್ತು ಆಲಿಸುವವರು IPv4 ಅಥವಾ IPv6 ಎಂಬುದರ ಮೇಲೆ ಅದು ಅವಲಂಬಿತವಲ್ಲ.

TCP OpenVPN ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವಂತೆ ಕಾಣುವ ಸಂರಚನೆ UDP ಪ್ರಕರಣದ ಬಗ್ಗೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ. ಇಲ್ಲಿ ಸಾಗಣೆ ಪ್ರೋಟೋಕಾಲ್‌ನ ಭಾಗ, ನಿಯೋಜನೆಯ ವಿವರವಲ್ಲ.

ಆಲಿಸುವವರು ಮತ್ತು ಬ್ಯಾಕೆಂಡ್

nginx -V 2>&1 | tr ' ' '\n' | grep stream

stream {
    server {
        listen [::]:1194 udp reuseport;
        proxy_pass [2001:db8::20]:1194;
    }
}

ಏನನ್ನಾದರೂ ಸಂಪಾದಿಸುವ ಮೊದಲು build ನಲ್ಲಿ stream ಮಾಡ್ಯೂಲ್ ಇದೆ ಎಂದು ಖಚಿತಪಡಿಸಿ; ವಿತರಣಾ ಪ್ಯಾಕೇಜ್ ಅದನ್ನು ಪ್ರತ್ಯೇಕ ಮಾಡ್ಯೂಲ್ ಆಗಿ ವಿಭಜಿಸಬಹುದು, ಮತ್ತು ಮಾಡ್ಯೂಲ್ ಇಲ್ಲದಿದ್ದರೆ ಟನೆಲ್ ಬದಲು ಸಂರಚನಾ ದೋಷ ಬರುತ್ತದೆ. ಬ್ಲಾಕ್ ಅನ್ನು ಮುಖ್ಯ ಸಂರಚನಾ ಸಂದರ್ಭದಲ್ಲಿ ಇರಿಸಿ, http ಒಳಗೆ ಅಲ್ಲ, ಮತ್ತು ದಸ್ತಾವೇಜು ವಿಳಾಸವನ್ನು ನಿಜವಾದ ಬ್ಯಾಕೆಂಡ್‌ನಿಂದ ಬದಲಾಯಿಸಿ.

ಎರಡೂ ಮಾರ್ಗಗಳು ಮತ್ತು ಎರಡೂ ಫೈರ್‌ವಾಲ್‌ಗಳು ಡೇಟಾಗ್ರಾಮ್‌ಗಳನ್ನು ಅನುಮತಿಸಬೇಕು: ಆಲಿಸುವವರವರೆಗಿನ ದಾರಿ ಮತ್ತು ಪ್ರಾಕ್ಸಿಯಿಂದ ಬ್ಯಾಕೆಂಡ್‌ವರೆಗಿನ ದಾರಿ. IPv6 ಆಲಿಸುವವರು IPv4 ದಾರಿಯನ್ನೂ ಸೃಷ್ಟಿಸುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಕೆಲವು ಕ್ಲೈಂಟ್‌ಗಳು ಇನ್ನೂ IPv4 ಬಳಸುತ್ತಿದ್ದರೆ, ಆ ಆಲಿಸುವವರು ತಮ್ಮದೇ ಪರೀಕ್ಷೆಯೊಂದಿಗೆ ಪ್ರತ್ಯೇಕ ನಮೂದು. ಬ್ಯಾಕೆಂಡ್‌ನ ಸ್ವಂತ ಫೈರ್‌ವಾಲ್ ಅನ್ನು ಪ್ರಾಕ್ಸಿಯ ವಿಳಾಸದಿಂದ ಪರಿಶೀಲಿಸಿ, ನಿಮ್ಮ ಲ್ಯಾಪ್‌ಟಾಪ್‌ನಿಂದ ಅಲ್ಲ.

ಸೆಷನ್ ಸಮಯ ಮಿತಿಗಳು ವಿನಂತಿ ಸಮಯ ಮಿತಿಗಳಲ್ಲ

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

ನಿಯೋಜನೆಯ ಪರಿಣಾಮಕಾರಿ proxy_timeout ಮತ್ತು ಪ್ರತಿಕ್ರಿಯೆ ಎಣಿಕೆಯ ಯಾವುದೇ ಸೆಟ್ಟಿಂಗ್ ಓದಿ, ನಂತರ ಅವುಗಳನ್ನು VPN ನಿಜವಾಗಿ ಬಳಸುವ keepalive ವರ್ತನೆಯೊಂದಿಗೆ ಹೋಲಿಸಿ. ಬೇರೆ ಬೇರೆ ಜನರು ಬೇರೆ ಬೇರೆ ಫೈಲ್‌ಗಳಲ್ಲಿ ಬರೆದ ಎರಡು ಸಂಖ್ಯೆಗಳು ಕೆಲಸ ಮಾಡುವ ವ್ಯವಸ್ಥೆಯ ಸಾಮಾನ್ಯ ಸ್ಥಿತಿ. ಎಂದಿಗೂ ಹೋಲಿಸದ ಎರಡು ಸಂಖ್ಯೆಗಳು ಅಡ್ಡಿಪಡಿಸುವ ವ್ಯವಸ್ಥೆಯ ಸಾಮಾನ್ಯ ಸ್ಥಿತಿ. ಹೋಲಿಕೆ ಒಮ್ಮೆ, ಹಗಲು ಬೆಳಕಿನಲ್ಲಿ ನಡೆಯಲು ಎರಡನ್ನೂ ಸೇವಾ ದಾಖಲೆಯಲ್ಲಿ ಬರೆಯಿರಿ.

ರಿಲೇ ಏನು ಬದಲಾಯಿಸುತ್ತದೆ ಮತ್ತು ಏನನ್ನು ಬದಲಾಯಿಸುವುದಿಲ್ಲ

stream ಪ್ರಾಕ್ಸಿ OpenVPN ನ TLS ನಿಯಂತ್ರಣ ಚಾನಲ್ ಅನ್ನು ಕೊನೆಗೊಳಿಸುವುದಿಲ್ಲ ಮತ್ತು ಅದನ್ನು HTTPS ಆಗಿ ಪರಿವರ್ತಿಸುವುದಿಲ್ಲ. ಬ್ಯಾಕೆಂಡ್ VPN ಸೇವೆಯಾಗಿಯೇ ಉಳಿಯುತ್ತದೆ, ಮತ್ತು ಪ್ರಮಾಣಪತ್ರದ ಸಂಬಂಧ ಕ್ಲೈಂಟ್ ಮತ್ತು ಆ ಸೇವೆಯ ನಡುವೆಯೇ ಉಳಿಯುತ್ತದೆ. ಉದ್ದೇಶಿತ ಬ್ಯಾಕೆಂಡ್ ಗುರುತನ್ನು ಸಂರಕ್ಷಿಸುವುದು ಇನ್ನೂ ಕ್ಲೈಂಟ್ ಮತ್ತು ಸರ್ವರ್‌ನ ಕೆಲಸ.

ಸಾಮಾನ್ಯ ಪ್ರಾಕ್ಸಿಂಗ್ ಬ್ಯಾಕೆಂಡ್ ನೋಡುವ ಮೂಲ ವಿಳಾಸವನ್ನೂ ಬದಲಾಯಿಸುತ್ತದೆ. ಲಾಗ್‌ಗಳು ಪ್ರಾಕ್ಸಿಯನ್ನು ತೋರಿಸುತ್ತವೆ, ಮತ್ತು VPN ಸರ್ವರ್‌ನಲ್ಲಿ IP ಆಧಾರಿತ ಯಾವುದೇ ಪ್ರವೇಶ ನಿಯಮ ಕ್ಲೈಂಟ್‌ನ ಬದಲು ಆ ವಿಳಾಸವನ್ನು ಮೌಲ್ಯಮಾಪನ ಮಾಡುತ್ತದೆ. ಪಾರದರ್ಶಕ ಮೂಲ ಸಂರಕ್ಷಣೆ ಪ್ರತ್ಯೇಕ ರೂಟಿಂಗ್ ಮತ್ತು ಸವಲತ್ತು ವಿನ್ಯಾಸ, ಆಲಿಸುವವರಿಗೆ udp ಸೇರಿಸುವುದರಿಂದ ಬರುವುದಲ್ಲ. ಕ್ಲೈಂಟ್ ವಿಳಾಸವನ್ನು ಅವಲಂಬಿಸಿರುವ ನೀತಿ ಬರೆಯುವ ಮೊದಲು ಅದನ್ನು ಯೋಜಿಸಿ.

ಪೋರ್ಟ್‌ನಿಂದ ಅಲ್ಲ, ಕ್ಲೈಂಟ್‌ನಿಂದ ಪರಿಶೀಲಿಸಿ

UDP ಪೋರ್ಟ್ ತೆರೆದಿದೆ ಎಂಬ ಸ್ಥಳೀಯ ಪರಿಶೀಲನೆ ಆಲಿಸುವವರು ಇದ್ದಾರೆ ಎಂದು ಸಾಬೀತುಪಡಿಸುತ್ತದೆ. ಕ್ಲೈಂಟ್ ಅದರ ಮೂಲಕ ದೃಢೀಕರಿಸಬಹುದು ಅಥವಾ ಸಂಚಾರ ವಿನಿಮಯ ಮುಂದುವರಿಸಬಹುದು ಎಂದು ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ. ಅನುಮೋದಿತ ಕ್ಲೈಂಟ್‌ನಿಂದ ನಿಜವಾದ ಸಂಪರ್ಕವನ್ನು ಪೂರ್ಣಗೊಳಿಸಿ, ನಂತರ ಸೆಷನ್ ಅರ್ಥಪೂರ್ಣವಾಗಿರಲು ಸಾಕಷ್ಟು ಕಾಲ ಉಳಿಯುತ್ತದೆ ಎಂದು ಖಚಿತಪಡಿಸಿ.

Nginx UDP ಮಾಡಲಾರದು ಎಂದು ಯಾರಾದರೂ ವರದಿ ಮಾಡಿದಾಗ, ಏಕೆಂದರೆ ಅದರ ಬದಲು ಸರಳ ರಿಲೇ ಸಾಧನ ಕೆಲಸ ಮಾಡಿತು, ಆ ಎರಡು ಸಂಗತಿಗಳು ಸಂಬಂಧವಿಲ್ಲದವು. ಸಾಧನವು ಬ್ಯಾಕೆಂಡ್ ಉತ್ತರಿಸುತ್ತದೆ ಎಂದು ಸಾಬೀತುಪಡಿಸಿತು; ಮುಂಭಾಗ ಏನನ್ನು ಬೆಂಬಲಿಸುತ್ತದೆ ಎಂಬುದರ ಬಗ್ಗೆ ಅದು ಏನನ್ನೂ ಹೇಳಲಿಲ್ಲ. ಎರಡೂ ನಿಜವಾಗಿರಬಹುದು, ಮತ್ತು ಅವುಗಳಲ್ಲಿ ಒಂದೇ ಈ ನಿಯೋಜನೆಯ ಸಂರಚನೆ.

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