ಹಂಚಿಕೆಯ TAP VPN ಗೆ ಪೋರ್ಟಲ್‌ನಲ್ಲಿ ಇನ್ನೂ HTTPS ಏಕೆ ಬೇಕು
TAP VPN ಪೀರ್ ಅನ್ನು ದೃಢೀಕರಿಸುತ್ತದೆ, ಅದರ ಹಿಂದಿನ ಸೇವೆಯನ್ನಲ್ಲ. ಪೋರ್ಟಲ್‌ನಲ್ಲಿ ಹೋಸ್ಟ್‌ನಾಮ್ ಮೌಲ್ಯೀಕರಣವನ್ನು ಇರಿಸಿ ಮತ್ತು ನೀವು ನಂಬದ ನೆರೆಹೊರೆಯವರನ್ನು ಪ್ರತ್ಯೇಕಿಸಿ.
ಎರಡು ಸಾಧನಗಳು ಮಾನ್ಯವಾದ VPN ರುಜುವಾತುಗಳನ್ನು ಹೊಂದಿದ್ದು ಒಂದೇ ಬ್ರಿಡ್ಜ್ ಮಾಡಿದ Ethernet ವಿಭಾಗವನ್ನು ಹಂಚಿಕೊಳ್ಳುತ್ತವೆ. ಅವುಗಳಲ್ಲಿ ಒಂದೇ ಕಚೇರಿ ಪೋರ್ಟಲ್‌ಗೆ ಉತ್ತರಿಸಬೇಕು, ಮತ್ತು ಇನ್ನೊಂದು ಆ ವಿಭಾಗದಲ್ಲಿ ಪೋರ್ಟಲ್‌ನ ವಿಳಾಸವನ್ನು ಇನ್ನೂ ಕ್ಲೇಮ್ ಮಾಡಬಹುದು. ಸುರಂಗವು ತನ್ನ ಕೆಲಸ ಮಾಡಿತು: ಅದು ಎರಡೂ ಪೀರ್‌ಗಳನ್ನು ದೃಢೀಕರಿಸಿ ಸರ್ವರ್‌ವರೆಗಿನ ಪ್ರತಿ ಮಾರ್ಗವನ್ನು ಗೂಢಲಿಪೀಕರಿಸಿತು. ಅದು ಮಾಡದಿರುವುದು ಅವುಗಳಲ್ಲಿ ಯಾರು ಸೇವಾ ಹೆಸರನ್ನು ಹೊಂದಿದ್ದಾರೆ ಎಂಬುದನ್ನು ಪ್ರಮಾಣೀಕರಿಸುವುದು, ಮತ್ತು ಆ ಕೊರತೆಯೇ ಪೋರ್ಟಲ್‌ಗೆ ಇನ್ನೂ ಮಾನ್ಯ ಪ್ರಮಾಣಪತ್ರ ಬೇಕಾಗಿರುವ ಕಾರಣ.
VPN ವಾಸ್ತವವಾಗಿ ಏನನ್ನು ದೃಢೀಕರಿಸುತ್ತದೆ
VPN ಹ್ಯಾಂಡ್‌ಶೇಕ್ ಒಂದು ಪ್ರಶ್ನೆಗೆ ಉತ್ತರಿಸುತ್ತದೆ: ಯಾವ ಪೀರ್ ಈ ಸುರಂಗವನ್ನು ಯಾವ ಕೀ ವಸ್ತುವಿನೊಂದಿಗೆ ಪೂರ್ಣಗೊಳಿಸಿತು. ಆ ಉತ್ತರ ಪೀರ್‌ಗೆ ಮತ್ತು ಸಂಪರ್ಕಕ್ಕೆ ಸಂಬಂಧಿಸಿದ್ದು, ಮತ್ತು ಆ ಪೀರ್ ನಂತರ ಒದಗಿಸುವ ಸೇವೆಗಳ ಬಗ್ಗೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ. TAP ವಿಭಾಗದಲ್ಲಿ ಪೀರ್ ಒಂದೇ ವಿಳಾಸವೂ ಅಲ್ಲ, ಏಕೆಂದರೆ ಬ್ರಿಡ್ಜ್ ಕಲಿಯಲು ಸಿದ್ಧವಿರುವ ಯಾವುದೇ MAC ಮತ್ತು ಯಾವುದೇ IP ಅನ್ನು ಅದು ಪ್ರಸ್ತುತಪಡಿಸಬಹುದು. ದೃಢೀಕರಣವು ಸುರಂಗದ ಅಂತ್ಯದ ಹಂತದಲ್ಲಿ ನಿಲ್ಲುತ್ತದೆ, ಅಪ್ಲಿಕೇಶನ್‌ನಲ್ಲಿ ಅಲ್ಲ.
ಮೂರು ಪ್ರಶ್ನೆಗಳನ್ನು ಒಂದಾಗಿ ವಿಲೀನಗೊಳಿಸುವ ಬದಲು ಪ್ರತ್ಯೇಕಿಸಿ. ಪ್ರತಿಯೊಂದಕ್ಕೂ ತನ್ನದೇ ಕಾರ್ಯವಿಧಾನ ಮತ್ತು ತನ್ನದೇ ವೈಫಲ್ಯ ವಿಧಾನವಿದೆ.
| Question | Answered by |
|---|---|
| Which peer sent this packet? | VPN transport authentication |
| Which device owns this IPv4 address? | ARP, trusted only as far as the segment |
| Which service am I talking to? | Application TLS and hostname validation |
ನಿಯೋಜನೆಯಲ್ಲಿ ಸಂಪೂರ್ಣವಾಗಿ ದೃಢೀಕರಿಸಿದ ಸುರಂಗ ಮತ್ತು ಅದರ ಹಿಂದೆ ಸಂಪೂರ್ಣವಾಗಿ ದೃಢೀಕರಿಸದ ಸೇವೆ ಇರಬಹುದು. ಎರಡನೇ ಪದರದ ವಿಳಾಸವನ್ನು ಇನ್ನೊಂದು ಪೀರ್ ಕ್ಲೇಮ್ ಮಾಡುತ್ತಿರುವ ಹೋಸ್ಟ್‌ನಲ್ಲಿ ಮಾನ್ಯಗೊಳಿಸಿದ ಪ್ರಮಾಣಪತ್ರವೂ ಇರಬಹುದು, ಆದ್ದರಿಂದ ವಿನ್ಯಾಸದಲ್ಲಿ ಒಂದು ಇನ್ನೊಂದನ್ನು ಬದಲಿಸುವ ಬದಲು ಎರಡೂ ನಿಯಂತ್ರಣಗಳು ಇರಬೇಕು. ಕೋಷ್ಟಕವು ಮೂರು ಸಾಲುಗಳಲ್ಲಿ ಇಡೀ ವಾದವಾಗಿದೆ.
ಹಂಚಿಕೆಯ ವಿಭಾಗದಲ್ಲಿ ARP ಡೈರೆಕ್ಟರಿ ಅಲ್ಲ
ARP ಸ್ಥಳೀಯ ಲಿಂಕ್‌ನಲ್ಲಿ IPv4 ವಿಳಾಸವನ್ನು MAC ಗೆ ನಕ್ಷೆ ಮಾಡುತ್ತದೆ ಮತ್ತು ಆ ಲಿಂಕ್‌ನಲ್ಲಿ ಯಾರಿಂದಲಾದರೂ ಉತ್ತರಗಳನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ. ಅನುಮತಿಸುವ ಬ್ರಿಡ್ಜ್ ಮಾಡಿದ ವಿಭಾಗದಲ್ಲಿ ಪೀರ್ ಇನ್ನೊಂದು ಸಾಧನಕ್ಕೆ ಸೇರಿದ ವಿಳಾಸವನ್ನು ಕ್ಲೇಮ್ ಮಾಡಬಹುದು, ಮತ್ತು ಬ್ರಿಡ್ಜ್ ಚೌಕಟ್ಟುಗಳನ್ನು ಕೊನೆಯದಾಗಿ ಉತ್ತರಿಸಿದವರಿಗೆ ರವಾನಿಸುತ್ತದೆ. ಸರ್ವರ್‌ಗೆ ಪ್ರತಿ ಕ್ಲೈಂಟ್ ಮಾರ್ಗವನ್ನು ಗೂಢಲಿಪೀಕರಿಸುವುದರಿಂದ ಅದು ಬದಲಾಗುವುದಿಲ್ಲ, ಏಕೆಂದರೆ ಚೌಕಟ್ಟುಗಳು ಬ್ರಿಡ್ಜ್ ತಲುಪುವ ಮೊದಲೇ ಡೀಕ್ರಿಪ್ಟ್ ಆಗುತ್ತವೆ. ARP ನ ನಂಬಿಕೆಯ ಗಡಿ ಸುರಂಗವಲ್ಲ, ವಿಭಾಗ.
ಹೋಸ್ಟ್ ವಾಸ್ತವವಾಗಿ ಏನನ್ನು ಕಲಿತಿದೆ ಎಂದು ನೋಡಿ: ip neigh show ಪ್ರಸ್ತುತ ನಕ್ಷೆಗಳು ಮತ್ತು ಅವುಗಳ ಸ್ಥಿತಿಯನ್ನು ಪಟ್ಟಿ ಮಾಡುತ್ತದೆ, ಮತ್ತು ಸಾಮಾನ್ಯ ಕಾರ್ಯಾಚರಣೆಯಲ್ಲಿ ಎರಡು MAC ವಿಳಾಸಗಳ ನಡುವೆ ಬದಲಾಗುವ ನಮೂದು ನಿರ್ಲಕ್ಷಿಸುವ ಬದಲು ತನಿಖೆಗೆ ಅರ್ಹವಾದ ಲಕ್ಷಣವಾಗಿದೆ. ಆರೋಗ್ಯಕರ ಸಣ್ಣ ವಿಭಾಗದಲ್ಲಿ ಅಂತಹ ನಮೂದುಗಳು ದೀರ್ಘಕಾಲ ಸ್ಥಿರವಾಗಿರುತ್ತವೆ.
ಪೀರ್ ಪ್ರತ್ಯೇಕತೆ ಮತ್ತು ಬ್ರಿಡ್ಜ್ ನೀತಿ ನಿಖರವಾಗಿ ಈ ಸಂದರ್ಭಕ್ಕಾಗಿ ಅಸ್ತಿತ್ವದಲ್ಲಿವೆ. ಸೇವೆ ಕೇವಲ IP ಆಗಿದ್ದು ಸಾಧನಗಳಿಗೆ ಪರಸ್ಪರರ ಚೌಕಟ್ಟುಗಳನ್ನು ನೋಡಲು ಯಾವುದೇ ಕಾರಣವಿಲ್ಲದಿದ್ದಾಗ ರೂಟ್ ಮಾಡಿದ ವಿನ್ಯಾಸ ಸಾಮಾನ್ಯವಾಗಿ ಉತ್ತಮ ಉತ್ತರ.
ಪ್ರಮಾಣಪತ್ರ ಮೌಲ್ಯೀಕರಣವನ್ನು ಸೇವೆ ಇರುವಲ್ಲಿಯೇ ಇರಿಸಿ
ಅಪ್ಲಿಕೇಶನ್‌ನ TLS ಸುರಂಗ ಉತ್ತರಿಸಲಾಗದ ಪ್ರಶ್ನೆಗೆ ಉತ್ತರಿಸುತ್ತದೆ: ನಾನು ತಲುಪಲು ಬಯಸಿದ ಸೇವೆ ಇದೇನಾ. ಬ್ರೌಸರ್ ಹೋಸ್ಟ್‌ನಾಮ್ ಅನ್ನು ಪ್ರಮಾಣಪತ್ರದ ವಿರುದ್ಧ ಪರಿಶೀಲಿಸುತ್ತದೆ, ಮತ್ತು ಆ ಪರಿಶೀಲನೆಯೇ ಪೀರ್ ಬದಲು ಪೋರ್ಟಲ್ ಅನ್ನು ಹೆಸರಿಸುವ ಸರಪಳಿಯ ಏಕೈಕ ಭಾಗ.
ಎಚ್ಚರಿಕೆ ಕೇವಲ ಮೇಲ್ನೋಟದ್ದು ಎಂದು ನಿರ್ಧರಿಸುವ ಮೊದಲು ಸರ್ವರ್ ಏನನ್ನು ಪ್ರಸ್ತುತಪಡಿಸುತ್ತದೆ ಎಂದು ಪರಿಶೀಲಿಸಿ. openssl s_client -connect portal.example.internal:443 -servername portal.example.internal ಸರಪಳಿ ಮತ್ತು ವಿಷಯದ ಪರ್ಯಾಯ ಹೆಸರುಗಳನ್ನು ಮುದ್ರಿಸುತ್ತದೆ. ನೀವು ಟೈಪ್ ಮಾಡಿದ ಹೆಸರು ಆ ಪಟ್ಟಿಯಲ್ಲಿಲ್ಲದಿದ್ದರೆ ಎಚ್ಚರಿಕೆ ಸರಿಯಾಗಿದೆ ಮತ್ತು ಪ್ರಮಾಣಪತ್ರವೇ ಸರಿಪಡಿಸಬೇಕಾದುದು. ಬಳಕೆದಾರರಿಗೆ ಅದನ್ನು ದಾಟಲು ಕಲಿಸುವುದು ಕಾರ್ಯನಿರ್ವಹಿಸುವ ನಿಯಂತ್ರಣವನ್ನು ಅಲಂಕಾರವಾಗಿ ಮಾರ್ಪಡಿಸುತ್ತದೆ.
OpenVPN ಬ್ರಿಡ್ಜಿಂಗ್ ಮಾರ್ಗದರ್ಶಿ Ethernet ಮಾದರಿ ಮತ್ತು ಅದರ ಸುತ್ತಲಿನ ನೀತಿ ಆಯ್ಕೆಗಳನ್ನು ವಿವರಿಸುತ್ತದೆ, ಮತ್ತು ವಿಭಾಗ ಏನನ್ನು ಅನುಮತಿಸಬೇಕು ಎಂಬುದಕ್ಕೆ ಇದು ಸರಿಯಾದ ಉಲ್ಲೇಖ. ಬ್ರಿಡ್ಜ್ ನಿಯಮವನ್ನು ಸಡಿಲಗೊಳಿಸುವ ಮೊದಲು ಅದನ್ನು ಓದಿ, ಏಕೆಂದರೆ ಅದು ವಿವರಿಸುವ ಮಾದರಿಯೇ ಮೇಲಿನ ಪ್ರತಿ ಪರಿಶೀಲನೆಯೂ ಊಹಿಸುವುದು.
ಆ ಪೀರ್‌ಗಳು ವಿಭಾಗವನ್ನು ಹಂಚಿಕೊಳ್ಳಬೇಕೇ ಎಂದು ನಿರ್ಧರಿಸಿ
ಅಗತ್ಯವು ಕೇವಲ IP ತಲುಪುವಿಕೆಯಾದಾಗ ಎರಡನೇ ಪದರವನ್ನು ಹಂಚಿಕೊಳ್ಳುವುದನ್ನು ನಿಲ್ಲಿಸುವುದು ಸಾಮಾನ್ಯವಾಗಿ ಅಗ್ಗದ ಪರಿಹಾರ. ರೂಟ್ ಮಾಡಿದ VPN ಪ್ರತಿ ಕ್ಲೈಂಟ್‌ಗೆ ಅದರ ಸ್ವಂತ ವಿಳಾಸವನ್ನು ನೀಡುತ್ತದೆ, ಹಂಚಿಕೆಯ ಪ್ರಸಾರ ಡೊಮೇನ್ ಅನ್ನು ತೆಗೆದುಹಾಕುತ್ತದೆ ಮತ್ತು ಪೀರ್‌ಗಳ ನಡುವಿನ ಸಂಚಾರವನ್ನು ಡೀಫಾಲ್ಟ್ ಬದಲು ನೀತಿ ನಿರ್ಣಯವಾಗಿ ಮಾರ್ಪಡಿಸುತ್ತದೆ. ಆಗ ಪೋರ್ಟಲ್‌ಗೆ ರಕ್ಷಿಸಲು ಒಂದೇ ವಿಳಾಸ ಇರುತ್ತದೆ ಮತ್ತು ಅದನ್ನು ಕ್ಲೇಮ್ ಮಾಡಬಲ್ಲ ನೆರೆಹೊರೆಯವರಿಲ್ಲ.
ವಿಭಾಗ ಉಳಿಯಬೇಕಾದರೆ, ಕ್ಲೈಂಟ್ಗಳು ಪರಸ್ಪರ ತಲುಪಲು ಅನುಮತಿಸುವ ಸರ್ವರ್-ಸೈಡ್ ಸೆಟ್ಟಿಂಗ್ ಪರಿಶೀಲಿಸಿ: grep -n client-to-client /etc/openvpn/server.conf. ಅದು ನಿಷ್ಕ್ರಿಯವಾಗಿದ್ದಾಗ ಕ್ಲೈಂಟ್ ಸಂಚಾರ ಸರ್ವರ್ ಮೂಲಕ ಹಾದುಹೋಗುತ್ತದೆ ಮತ್ತು ಅಲ್ಲಿಯೇ ಫಿಲ್ಟರ್ ಮಾಡಬಹುದು. ಅದು ಸಕ್ರಿಯವಾಗಿದ್ದಾಗ ಪೀರ್‌ಗಳು ನೇರವಾಗಿ ಬ್ರಿಡ್ಜ್ ಮೂಲಕ ಚೌಕಟ್ಟುಗಳನ್ನು ವಿನಿಮಯ ಮಾಡಿಕೊಳ್ಳುತ್ತವೆ, ಮತ್ತು ನಿಮ್ಮ ಫಿಲ್ಟರಿಂಗ್ ಬಿಂದುಗಳು ಬ್ರಿಡ್ಜ್ ಮತ್ತು ಹೋಸ್ಟ್ ಫೈರ್‌ವಾಲ್.
ಪ್ರತಿ ಹೋಸ್ಟ್ ವಾಸ್ತವವಾಗಿ ಯಾವ ರಕ್ಷಣೆಗಳನ್ನು ಅವಲಂಬಿಸಿದೆ ಎಂದು ಬರೆಯಿರಿ: ಸುರಂಗ ದೃಢೀಕರಣ, ವಿಭಾಗ ಪ್ರತ್ಯೇಕತೆ ಅಥವಾ ಅಪ್ಲಿಕೇಶನ್ TLS. ಮೂರನ್ನೂ ಅವಲಂಬಿಸುವ ಹೋಸ್ಟ್ ಸರಿಯಾಗಿದೆ. ಮೊದಲನೆಯದನ್ನು ಅವಲಂಬಿಸಿ ಉಳಿದೆರಡು ಅದರೊಂದಿಗೆ ಬಂದವು ಎಂದು ಭಾವಿಸುವ ಹೋಸ್ಟ್ ಅಂತಿಮವಾಗಿ ತಪ್ಪು ವಿಷಯವನ್ನು ನೀಡುತ್ತದೆ.