ಅದೇ ಸರ್ವರ್ IP, ಎರಡು ಮಾರ್ಗಗಳು: OpenVPN ನ ಹೊರ ಹರಿವನ್ನು ಗುರುತಿಸುವುದು

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

ಬೇರ್ಪಡಿಸಲು ಬಯಸುವ ಎರಡು ಹರಿವುಗಳಿಂದ ಪ್ರಾರಂಭಿಸಿ

ಒಂದು ಹರಿವು ಗೂಢಲಿಪೀಕರಿಸಿದ OpenVPN ಸಾಗಣೆಯೇ, ಅದು ಅಪ್ಲಿಂಕ್ ಮೂಲಕ ಹೊರಕ್ಕೆ ಹೋಗಬೇಕು, ಇಲ್ಲದಿದ್ದರೆ ಸುರಂಗವು ತನ್ನದೇ ಹೊರ ಸಂಪರ್ಕವನ್ನು ಹೊರುತ್ತದೆ. ಇನ್ನೊಂದು ಅದೇ ಸಾರ್ವಜನಿಕ ವಿಳಾಸಕ್ಕೆ ಹೋಗುವ ಸಾಮಾನ್ಯ HTTPS ವಿನಂತಿ, ಅದನ್ನು ಸುರಂಗದ ಒಳಗೆ ಇಡಲು ಬಯಸುತ್ತೀರಿ, ಇದರಿಂದ ಅದು ಸುರಂಗ ಮೂಲದಿಂದ ಸೇವೆಯನ್ನು ತಲುಪುತ್ತದೆ. ಅದೇ ಗಮ್ಯಸ್ಥಾನ, ಹಲವು ಸಂದರ್ಭಗಳಲ್ಲಿ ಅದೇ ಪೋರ್ಟ್ ಸಂಖ್ಯೆ, ಬೇರೆ ಅಗತ್ಯವಾದ ಮಾರ್ಗ.

ಈ ವಿವರಣೆಯಲ್ಲಿ 10.90.0.10 ನಲ್ಲಿರುವ ಕ್ಲೈಂಟ್ tun1 ಮೂಲಕ ಇದೆ, ಸರ್ವರ್ನ ಸಾರ್ವಜನಿಕ ವಿಳಾಸ 198.51.100.25, ಮತ್ತು ಮುಖ್ಯ ಕೋಷ್ಟಕ ಮುಟ್ಟದೆ ಇದೆ; ಅದರ ಡಿಫಾಲ್ಟ್ ಮಾರ್ಗ ಸಾಮಾನ್ಯ ಅಪ್ಲಿಂಕ್ನತ್ತ ಸಾಗುತ್ತದೆ. ಸರ್ವರ್ ಕಡೆಯೂ ಒಳ ಮಾರ್ಗದಲ್ಲಿ ವೆಬ್ ಸೇವೆಯನ್ನು ಸ್ವೀಕರಿಸಬೇಕು ಮತ್ತು ಸಂಚಾರವನ್ನು ಸುರಂಗ ಮೂಲಕ್ಕೆ ಹಿಂತಿರುಗಿಸಬೇಕು; ಸಾರ್ವಜನಿಕ ವಿಳಾಸಕ್ಕೆ ಪ್ಯಾಕೆಟ್ ಕಳುಹಿಸುವುದು ಸರ್ವರ್ನ ಲಿಸನರ್ ಅಥವಾ ಫೈರ್ವಾಲ್ ನೀತಿಯನ್ನು ರದ್ದು ಮಾಡುವುದಿಲ್ಲ.

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

ಲಕೋಟೆಯನ್ನು ಹೊರುವ ಸಾಕೆಟ್ ಅನ್ನು ಗುರುತಿಸಿ

ಕ್ಲೈಂಟ್ ಸಂರಚನೆಯು ತನ್ನ ಗೂಢಲಿಪೀಕರಿಸಿದ ಹೊರಹೋಗುವ ಪ್ಯಾಕೆಟ್ಗಳಿಗೆ ಗುರುತನ್ನು ಪಡೆಯುತ್ತದೆ ಮತ್ತು ತಾನೇ ಮಾರ್ಗಗಳನ್ನು ಸ್ಥಾಪಿಸುವುದನ್ನು ನಿಲ್ಲಿಸುತ್ತದೆ, ಇದರಿಂದ ಬದಲಿ ನೀತಿಯೇ ಮಾರ್ಗಗಳನ್ನು ನಿರ್ಧರಿಸುವ ಏಕೈಕ ವಿಷಯವಾಗುತ್ತದೆ:

mark 42
route-noexec
disable-dco

ದಶಮಾಂಶ 42 ಎಂಬುದು ಹೆಕ್ಸಾಡೆಸಿಮಲ್ 0x2a, ಮತ್ತು ಹೆಕ್ಸ್ ರೂಪವೇ ರೂಟಿಂಗ್ ನಿಯಮಗಳು ಹೊಂದಿಕೆಯಾಗುವುದು. link-options ಉಲ್ಲೇಖ mark ಅನ್ನು Linux ನಲ್ಲಿ ಗೂಢಲಿಪೀಕರಿಸಿದ ಹೊರಹೋಗುವ ಪ್ಯಾಕೆಟ್ಗಳಿಗೆ ಅನ್ವಯಿಸುವಂತಹದ್ದು ಎಂದು ವಿವರಿಸುತ್ತದೆ, ಅಂದರೆ ನೀವು ಮಾರ್ಗವನ್ನು ನಿಯಂತ್ರಿಸಬೇಕಾದ ಅದೇ ಸಾಕೆಟ್. ಡೇಟಾ ಚಾನೆಲ್ನ ಆಫ್ಲೋಡ್ ಆಫ್ ಮಾಡುವುದು ಈ ಉದಾಹರಣೆಯನ್ನು ಬಳಕೆದಾರ-ಸ್ಥಳ ಮಾರ್ಗದಲ್ಲಿ ಉಳಿಸುತ್ತದೆ, ಅಲ್ಲಿ ಗುರುತಿನ ವರ್ತನೆ ವಿವರಿಸಿದುದೇ.

route-noexec OpenVPN ನ ಸ್ವಯಂಚಾಲಿತ ಮಾರ್ಗ ಸೇರಿಸುವಿಕೆ ಮತ್ತು ತೆಗೆಯುವಿಕೆಯನ್ನು ಹತ್ತಿಕ್ಕುತ್ತದೆ. ಅವುಗಳ ಜಾಗದಲ್ಲಿ ಏನನ್ನೂ ಸ್ಥಾಪಿಸುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಈ ಕ್ಷಣದಿಂದ ಮಾರ್ಗಗಳ ಮಾಲೀಕರು ಸುರಂಗಕ್ಕೆ ಬೇಕಾದ ಪ್ರತಿ ಮಾರ್ಗವನ್ನೂ ನಿರ್ವಹಿಸಬೇಕು. ಬದಲಾವಣೆಯ ನಂತರ ಯಾವುದಾದರೂ ಖಾಸಗಿ ಗಮ್ಯಸ್ಥಾನ ಕಣ್ಮರೆಯಾದರೆ, ಅದು ಕಾಣೆಯಾದ ಬದಲಿ ನೀತಿ, ಗುರುತಿನ ದೋಷವಲ್ಲ.

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

ಉಳಿದೆಲ್ಲವನ್ನೂ ಸುರಂಗ ಕೋಷ್ಟಕಕ್ಕೆ ಕಳುಹಿಸಿ

ಸುರಂಗ ಇಂಟರ್ಫೇಸ್ ಅಸ್ತಿತ್ವದಲ್ಲಿದ್ದು ತನ್ನ ವಿಳಾಸವನ್ನು ಹಿಡಿದಿಟ್ಟುಕೊಂಡಾಗ, ನೀತಿ ಹೀಗೆ ಕಾಣುತ್ತದೆ:

ip -4 route add default dev tun1 src 10.90.0.10 table 47100
ip -4 rule add priority 20000 lookup main suppress_prefixlength 0
ip -4 rule add priority 20001 not fwmark 0x2a lookup 47100
ip -4 rule add priority 20002 not fwmark 0x2a unreachable

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

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

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

ಹಿಂತಿರುಗುವ ಮಾರ್ಗವೂ ಅದೇ ಗುರುತನ್ನು ನೋಡಲಿ

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

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

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

ಎರಡು ಮಾರ್ಗ ಹುಡುಕಾಟಗಳಿಂದ ಇದನ್ನು ಸಾಬೀತುಪಡಿಸಿ

ಕರ್ನಲ್ ಎರಡು ಸಂದರ್ಭಗಳಿಗೆ ಏನು ನಿರ್ಧರಿಸುತ್ತದೆ ಎಂದು ಹೋಲಿಸಿ, ಮತ್ತು ನಿರ್ಗಮನ ಸ್ಥಿತಿಯ ಬದಲು dev ಮತ್ತು src ಕ್ಷೇತ್ರಗಳನ್ನು ಓದಿ:

ip -4 route get 198.51.100.25
ip -4 route get 198.51.100.25 mark 0x2a

ಮೊದಲ ಹುಡುಕಾಟ ಸುರಂಗ ಮೂಲದೊಂದಿಗೆ tun1 ಗೆ ಪರಿಹಾರವಾಗಬೇಕು, ಮತ್ತು ಎರಡನೆಯದು ಅಪ್ಲಿಂಕ್ ಗೆ. ಇವು ಕೃತಕ ಹುಡುಕಾಟಗಳು, ಆದ್ದರಿಂದ ಅವು ನೀತಿಯನ್ನು ಸಾಬೀತುಪಡಿಸುತ್ತವೆ, ನಡೆಯುತ್ತಿರುವ ಪ್ರಕ್ರಿಯೆಯನ್ನಲ್ಲ: ನಡೆಯುತ್ತಿರುವ ಕ್ಲೈಂಟ್ನ ನಿಜವಾದ ಸಾಗಣೆ ಮಾರ್ಗವನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ದೃಢೀಕರಿಸಿ, ನಂತರ ಪ್ರಮಾಣಪತ್ರ ಪರಿಶೀಲನೆ ಆನ್ ಆಗಿರುವಂತೆಯೇ ನಿಜವಾದ HTTPS ವಿನಂತಿ ಮಾಡಿ.

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