webpack ಡೆವ್ ಸರ್ವರ್ ಅನ್ನು VPN ವಿಳಾಸದಲ್ಲಿ ಹೇಗೆ ಸೇವೆ ಮಾಡುವುದು

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

ಮೂರು ಪ್ರಶ್ನೆಗಳು ಉತ್ತರವನ್ನು ನಿರ್ಧರಿಸುತ್ತವೆ: ಯಾರು ಸಂಪರ್ಕಿಸುತ್ತಾರೆ, ಅವರು ಯಾವ ವಿಳಾಸವನ್ನು ತಲುಪಬಹುದು, ಮತ್ತು ಅವರಿಗೆ ಲೈವ್ ರೀಲೋಡ್ ಕೆಲಸ ಮಾಡಬೇಕೇ.

ಸಂರಚನಾ ಕಡತದಿಂದ ಅಲ್ಲ, ಸಾಕೆಟ್‌ನಿಂದ ಪ್ರಾರಂಭಿಸಿ

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

ss -ltn '( sport = :8080 )'
ss -ltnp | grep node

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

ಮಾರ್ಗಗಳು ಅಥವಾ ಫೈರ್‌ವಾಲ್ ನಿಯಮಗಳನ್ನು ಮುಟ್ಟುವ ಮೊದಲು ಆ ವೀಕ್ಷಣೆಗೆ ಹೊಂದಿಕೊಳ್ಳಿ. ಪ್ರಕ್ರಿಯೆಯು ತಪ್ಪು ವಿಳಾಸದಲ್ಲಿ ಕೇಳುತ್ತಿದ್ದರೆ, ಯಾವುದೇ ಪಾಲಿಸಿ ರೌಟಿಂಗ್ ಕ್ಲೈಂಟ್ ಅನ್ನು ಅಲ್ಲಿಗೆ ತಲುಪಿಸುವುದಿಲ್ಲ.

ಯಾರು ತಲುಪಬೇಕು ಎಂಬುದರ ಆಧಾರದ ಮೇಲೆ ಬೈಂಡ್ ವಿಳಾಸವನ್ನು ಆಯ್ಕೆ ಮಾಡಿ

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

ಕಂಟೇನರ್ ಒಳಗಿನ ಬ್ರೌಸರ್ ಸರ್ವರ್ ಅನ್ನು ತಲುಪಬೇಕಾದರೆ, ಬೈಂಡ್ ವಿಳಾಸವು ಕಂಟೇನರ್ ನೆಟ್‌ವರ್ಕ್ ರೌಟ್ ಮಾಡಬಹುದಾದ ವಿಳಾಸವಾಗಿರಬೇಕು, ಮತ್ತು ಅದು ಸಾಮಾನ್ಯವಾಗಿ ಹೋಸ್ಟ್ ತನಗಾಗಿ ಪರಿಹರಿಸುವ ವಿಳಾಸವಲ್ಲ. ಸಂರಚನೆಯನ್ನು ಸಂಪಾದಿಸುವ ಮೊದಲು ಪ್ರಕರಣವನ್ನು ನಿರ್ಧರಿಸಿ, ಏಕೆಂದರೆ ಮೂರು ಪ್ರಕರಣಗಳು ಮೂರು ವಿಭಿನ್ನ ಮೌಲ್ಯಗಳನ್ನು ನೀಡುತ್ತವೆ ಮತ್ತು ಒಂದೇ ಸರಿ. ಇಲ್ಲಿ ಊಹಿಸುವುದು ಸೆಟಪ್‌ನ ಬೇರೆ ಯಾವುದೇ ಭಾಗಕ್ಕಿಂತ ಹೆಚ್ಚು ಸಮಯ ವ್ಯರ್ಥ ಮಾಡುತ್ತದೆ.

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

devServer: {
  host: "10.77.0.20",
  port: 8080,
  allowedHosts: ["dev.corp.example"],
}

ಆ ತುಣುಕಿನಲ್ಲಿನ ವಿಳಾಸವು ಉದಾಹರಣೆಯಾಗಿದ್ದು ಹೋಸ್ಟ್ ಹೊಂದಿರುವ VPN ವಿಳಾಸವನ್ನು ಪ್ರತಿನಿಧಿಸುತ್ತದೆ. ಪ್ರಾಜೆಕ್ಟ್ ಸರ್ವರ್ ಅನ್ನು new WebpackDevServer(options, compiler) ನಿಂದ ನಿರ್ಮಿಸಿದರೆ, ಬದಲಾಗಿ ಆಯ್ಕೆಗಳನ್ನು ಕನ್ಸ್‌ಟ್ರಕ್ಟರ್ ಆರ್ಗ್ಯುಮೆಂಟ್ ಮೂಲಕ ರವಾನಿಸಿ, ಏಕೆಂದರೆ webpack ಸಂರಚನೆಯಲ್ಲಿನ ಪ್ರತ್ಯೇಕ devServer ಗುಣಲಕ್ಷಣವನ್ನು ಆ ಮಾರ್ಗದಲ್ಲಿ ಪರಿಗಣಿಸಲಾಗುವುದಿಲ್ಲ. ಸಂರಚನಾ ಕಡತ ಮತ್ತು Node API ನಡುವಿನ ಈ ವ್ಯತ್ಯಾಸವು ತುಣುಕನ್ನು ಎಂದಿಗೂ ಓದದ ಪ್ರಾಜೆಕ್ಟ್‌ಗೆ ನಕಲಿಸುವವರನ್ನು ಹಿಡಿಯುತ್ತದೆ. dev-server ದಸ್ತಾವೇಜು ಎರಡು ಲಾಂಚ್ ಶೈಲಿಗಳನ್ನು ಪ್ರತ್ಯೇಕಿಸುತ್ತದೆ ಮತ್ತು ಬಳಸುತ್ತಿರುವ ಆವೃತ್ತಿಯೊಂದಿಗೆ ಪರಿಶೀಲಿಸಬೇಕಾದ ಉಲ್ಲೇಖವಾಗಿದೆ.

ನೀವು ಅನುಮೋದಿಸುವ ಹೆಸರುಗಳಿಗೆ ಹೋಸ್ಟ್‌ನಾಮ್ ಪರಿಶೀಲನೆಯನ್ನು ಹೊಂದಿಸಿ

ಹೋಸ್ಟ್‌ನಾಮ್ ಪರಿಶೀಲನೆಯು ದಾಳಿಕೋರರಿಂದ ನಿಯಂತ್ರಿಸಲ್ಪಡುವ ಹೆಸರಿನಿಂದ ನೀಡಲಾದ ಪುಟವು ಬ್ರೌಸರ್ ಮೂಲಕ ನಿಮ್ಮ ಡೆವಲಪ್‌ಮೆಂಟ್ ಸರ್ವರ್‌ನೊಂದಿಗೆ ಮಾತನಾಡದಂತೆ ತಡೆಯಲು ಇದೆ. ಅದನ್ನು allowedHosts: "all" ನಿಂದ ನಿಷ್ಕ್ರಿಯಗೊಳಿಸುವುದು ಆ ರಕ್ಷಣೆಯನ್ನು ತೆಗೆದುಹಾಕುತ್ತದೆ, ಮತ್ತು ಆಂತರಿಕ ಸೇವೆಗಳನ್ನು ತಲುಪಬಲ್ಲ ಯಂತ್ರದಲ್ಲಿ ಆ ಅನುಕೂಲ ಅಪರೂಪವಾಗಿ ಯೋಗ್ಯವಾಗಿರುತ್ತದೆ. ಬ್ರೌಸರ್ ಯಾವ ಹೆಸರುಗಳನ್ನು ಕಳುಹಿಸುತ್ತದೆ ಎಂದು ತಿಳಿದ ನಂತರ ಪರಿಶೀಲನೆಯನ್ನು ಸರಿಯಾಗಿ ಪೂರೈಸುವುದು ಅಗ್ಗವಾಗಿದೆ.

ನೀವು ಬಳಸುವ ನಿಖರ ಹೆಸರುಗಳನ್ನು ಪಟ್ಟಿ ಮಾಡಿ, ಟನೆಲ್ ವಿಳಾಸಕ್ಕೆ ಪರಿಹರಿಸುವ ಖಾಸಗಿ ಹೆಸರೂ ಸೇರಿದಂತೆ. ಕ್ಲೈಂಟ್ ಹೆಸರನ್ನು ನೀವು ಬೈಂಡ್ ಮಾಡಿದ ವಿಳಾಸಕ್ಕಿಂತ ಬೇರೆ ವಿಳಾಸಕ್ಕೆ ಪರಿಹರಿಸಿದರೆ, ನಿಮಗೆ ಹೆಸರು-ಪರಿಹಾರ ಸಮಸ್ಯೆ ಇದೆ, ಸರ್ವರ್ ಸಂರಚನಾ ಸಮಸ್ಯೆ ಅಲ್ಲ, ಮತ್ತು ಅನುಮತಿ ಪಟ್ಟಿಗೆ ಹೆಸರು ಸೇರಿಸುವುದರಿಂದ ಅದು ಸರಿಯಾಗುವುದಿಲ್ಲ. ಪರಿಹಾರವನ್ನು ಸರ್ವರ್‌ನಿಂದ ಅಲ್ಲ, ಕ್ಲೈಂಟ್‌ನಿಂದ ದೃಢೀಕರಿಸಿ.

ಮೂರು ನಿಯಂತ್ರಣಗಳನ್ನು ನಿಮ್ಮ ಮನಸ್ಸಿನಲ್ಲಿ ಪ್ರತ್ಯೇಕವಾಗಿ ಇರಿಸಿಕೊಳ್ಳಿ: ಬೈಂಡ್ ವಿಳಾಸವು ಯಾವ ಇಂಟರ್‌ಫೇಸ್‌ಗಳು ಸಂಪರ್ಕವನ್ನು ಸ್ವೀಕರಿಸುತ್ತವೆ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ, ಅನುಮತಿ ಪಟ್ಟಿಯು ಯಾವ Host ಹೆಡರ್‌ಗಳನ್ನು ಸ್ವೀಕರಿಸಲಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ, ಮತ್ತು ದೃಢೀಕರಣವು ಯಾರಿಗೆ ಒಳಗೆ ಬರಲು ಅನುಮತಿ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ. ಮೂರನೆಯದು ಮಾತ್ರ ಪ್ರವೇಶ ನಿಯಂತ್ರಣ, ಮತ್ತು ಡೆವಲಪ್‌ಮೆಂಟ್ ಸರ್ವರ್‌ನಲ್ಲಿ ಸಾಮಾನ್ಯವಾಗಿ ಯಾವುದೂ ಇರುವುದಿಲ್ಲ. ಟನೆಲ್ ವಿಳಾಸವೂ ದೃಢೀಕರಣ ಕಾರ್ಯವಿಧಾನವಲ್ಲ, ಏಕೆಂದರೆ ಅಲ್ಲಿಗೆ ರೌಟ್ ಮಾಡಬಲ್ಲ ಯಾರಾದರೂ ನೀವು ಅವಲಂಬಿಸಿದ್ದ ಗಡಿಯ ಒಳಗೆ ಈಗಾಗಲೇ ಇದ್ದಾರೆ.

ಪುಟ ಮತ್ತು ಲೈವ್-ರೀಲೋಡ್ ಸಾಕೆಟ್ ಅನ್ನು ಒಟ್ಟಿಗೆ ಪರಿಶೀಲಿಸಿ

ಉದ್ದೇಶಿತ ಕ್ಲೈಂಟ್‌ನಿಂದ ಸಂರಚಿತ ಸ್ಕೀಮ್‌ನೊಂದಿಗೆ ಹೊಸ ವಿನಂತಿಯನ್ನು ಲೋಡ್ ಮಾಡಿ ಮತ್ತು ಕ್ಯಾಶ್ ಬದಲು ಫಲಿತಾಂಶವನ್ನು ಓದಿ. HTTPS ಗಾಗಿ ನಿರೀಕ್ಷಿತ ಹೋಸ್ಟ್‌ನಾಮ್ ಮತ್ತು ಪ್ರಮಾಣಪತ್ರ ಮಾನ್ಯತೆಯನ್ನು ಇರಿಸಿಕೊಳ್ಳಿ, ಏಕೆಂದರೆ ಬ್ರೌಸರ್ ಎಚ್ಚರಿಕೆ ಯಶಸ್ವಿ ಸ್ವೀಕೃತಿ ಪರೀಕ್ಷೆಯಲ್ಲ. ಪುಟವು ರೆಂಡರ್ ಆಗುತ್ತಿದ್ದರೆ ಲೈವ್ ರೀಲೋಡ್ ಸದ್ದಿಲ್ಲದೆ ವಿಫಲವಾದರೆ, ಅದು ಇಲ್ಲಿ ಅತ್ಯಂತ ಸಾಮಾನ್ಯ ಭಾಗಶಃ ಯಶಸ್ಸು, ಮತ್ತು ತ್ವರಿತ ಪರಿಶೀಲನೆಯಲ್ಲಿ ಅದನ್ನು ತಪ್ಪಿಸಿಕೊಳ್ಳುವುದು ಸುಲಭ.

curl -sS -o /dev/null -w "%{http_code} %{remote_ip}\n" http://dev.corp.example:8080/
curl -sS -i http://10.77.0.20:8080/ | head -n 5

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

ಶ್ರೋತೃವಿನ ವಿಳಾಸ, ಸ್ವೀಕೃತ ಹೆಸರು, ಅನುಮತಿಸಿದ ಮೂಲ ಮತ್ತು ಎರಡೂ ಫಲಿತಾಂಶಗಳನ್ನು ಪ್ರಾಜೆಕ್ಟ್ ಟಿಪ್ಪಣಿಗಳಲ್ಲಿ ದಾಖಲಿಸಿ. ಆ ದಾಖಲೆ ಮುಂದಿನ ವ್ಯಕ್ತಿಗೆ ಉಳಿಯುತ್ತದೆ, ಅವರು ಕಾರ್ಯಕ್ಷೇತ್ರವನ್ನು ಪ್ರಾರಂಭಿಸಿ ಪುಟ ಏಕೆ ಲೋಡ್ ಆಗುತ್ತದೆ ಆದರೆ ಎಂದಿಗೂ ರಿಫ್ರೆಶ್ ಆಗುವುದಿಲ್ಲ ಎಂದು ಯೋಚಿಸುತ್ತಾರೆ.