OpenVPN ಮತ್ತು HTTPS ಪೋರ್ಟ್ 443 ನಲ್ಲಿ: ಆಲಿಸುವವರು ಯಾರದ್ದು?
TCP ಮತ್ತು UDP 443 ಪ್ರತ್ಯೇಕ ಸಾಕೆಟ್‌ಗಳು. ಒಂದು TCP ಆಲಿಸುವವನನ್ನು ಹಂಚಲು ಮಾಲೀಕ ಬೇಕು, ಮತ್ತು OpenVPN ನ ಪೋರ್ಟ್ ಹಂಚಿಕೆ ಕಿರಿದಾದ ಒಪ್ಪಂದ, ಪ್ರಾಕ್ಸಿ ಉಪಾಯವಲ್ಲ.
ಎರಡು ಸೇವೆಗಳು ಎಂದಿಗೂ ಸ್ಪರ್ಧಿಸದೆ ಎರಡೂ ಪೋರ್ಟ್ 443 ನಲ್ಲಿ ಉತ್ತರಿಸಬಹುದು, ಏಕೆಂದರೆ ಆಲಿಸುವವನು ಸಂಖ್ಯೆಯಿಂದ ಮಾತ್ರವಲ್ಲ, ಸಾಗಣೆ, ವಿಳಾಸ ಮತ್ತು ಪೋರ್ಟ್ ಒಟ್ಟಿಗೆ ನಿರ್ಧರಿಸಲ್ಪಡುತ್ತದೆ. ಒಂದೇ ಯಂತ್ರದಲ್ಲಿ ವೆಬ್ ಸರ್ವರ್ ಮತ್ತು OpenVPN ಇರಿಸಿ, ಮತ್ತು ಮೊದಲು ಉತ್ತರಿಸಲು ಯೋಗ್ಯವಾದ ಏಕೈಕ ಪ್ರಶ್ನೆ ಎಂದರೆ ಪ್ರತಿ ಪ್ರಕ್ರಿಯೆ ಕರ್ನೆಲ್‌ನಿಂದ ಯಾವ ಸಾಕೆಟ್ ಕೇಳುತ್ತದೆ ಎಂಬುದು. ಸಂರಚನೆಯನ್ನು ಸಂಪಾದಿಸುವ ಮೊದಲು ಆ ಪಟ್ಟಿಯನ್ನು ಬರೆಯಿರಿ, ಮತ್ತು «ವಿಳಾಸ ಈಗಾಗಲೇ ಬಳಕೆಯಲ್ಲಿದೆ» ದೋಷಗಳ ಬಹುಪಾಲು ತಾವಾಗಿಯೇ ವಿವರಿಸುತ್ತವೆ. ಪಟ್ಟಿಯ ನಂತರದ್ದೆಲ್ಲವೂ UDP ಆಲಿಸುವವ, ಹಂಚಿದ TCP ಸಾಕೆಟ್ ಅಥವಾ ಪ್ರೋಟೋಕಾಲ್ ಪ್ರಕಾರ ಮಾರ್ಗದರ್ಶನ ಮಾಡುವ ಮುಂಭಾಗದ ನಡುವಿನ ಆಯ್ಕೆ.
ಪ್ರತಿ ಪ್ರಕ್ರಿಯೆ ಕೇಳುವ ಸಾಕೆಟ್‌ನಿಂದ ಪ್ರಾರಂಭಿಸಿ
bind ಆ ತ್ರಿವಳಿಯ ಮೇಲೆ ಯಶಸ್ಸು ಅಥವಾ ವೈಫಲ್ಯ ಹೊಂದುತ್ತದೆ, ಆದ್ದರಿಂದ ಎರಡು ಡೀಮನ್‌ಗಳು ಮೂರೂ ಭಾಗಗಳು ಹೊಂದಿಕೆಯಾದಾಗ ಮಾತ್ರ ಘರ್ಷಿಸುತ್ತವೆ. ಆದ್ದರಿಂದ TCP 443 ನಲ್ಲಿ ವೆಬ್‌ಸೈಟ್ UDP 443 ನಲ್ಲಿ OpenVPN ಆಲಿಸುವವನೊಂದಿಗೆ ಅನಿರ್ದಿಷ್ಟವಾಗಿ ಸಹಬಾಳ್ವೆ ನಡೆಸುತ್ತದೆ, ಮತ್ತು ಆದ್ದರಿಂದ ಅವುಗಳಲ್ಲಿ ಒಂದನ್ನು ಅದೇ ಹೋಸ್ಟ್‌ನ ಎರಡನೇ ಸ್ಥಳೀಯ ವಿಳಾಸಕ್ಕೆ ಸರಿಸುವುದೂ ಚರ್ಚೆಯನ್ನು ಕೊನೆಗೊಳಿಸುತ್ತದೆ. ಜೀವಂತ ಆಲಿಸುವವರನ್ನು ಓದಿ, ಅವುಗಳನ್ನು ರಚಿಸಬೇಕಿದ್ದ ಫೈಲ್‌ಗಳನ್ನಲ್ಲ, ಏಕೆಂದರೆ ಹಳೆಯ include ಅಥವಾ ಮರೆತ unit ಫೈಲ್ ನೀವು ನೆನಪಿಟ್ಟುಕೊಂಡ ಸಂಪಾದನೆಗಿಂತ ಹೆಚ್ಚು ಕಾಲ ಉಳಿಯುತ್ತದೆ.
| Line in the listener list | What it establishes | What to do next |
|---|---|---|
| One udp row and one tcp row, each on 443 | Separate transport sockets, nothing contested | Point the VPN profile at udp and stop editing |
| A single tcp address and port listed by two processes | A real bind collision between two daemons | Move one service, or put a dispatcher in front of both |
| A proxy process owns the socket, no vpn process | The proxy accepts and has to hand off correctly | Check that its backend speaks the protocol it forwards |
root ಆಗಿ ss -lntup ಚಲಾಯಿಸಿ ಮತ್ತು 443 ಅನ್ನು ಉಲ್ಲೇಖಿಸುವ ಪ್ರತಿ ಸಾಲನ್ನು, IPv6 ನಮೂದುಗಳೂ ಸೇರಿದಂತೆ ಓದಿ. ಸಾಮಾನ್ಯವಾಗಿ ವೈಲ್ಡ್‌ಕಾರ್ಡ್ v6 ಆಲಿಸುವವ v4 ಸಂಚಾರವನ್ನೂ ಸ್ವೀಕರಿಸುತ್ತದೆ, ಮತ್ತು ಹೀಗೆಯೇ ಮರೆತ ಆಲಿಸುವವ ನೀವು ಜವಾಬ್ದಾರಿ ಎಂದು ಭಾವಿಸಿದ ಫೈಲ್ ಬದಲಿಸಿದ ನಂತರವೂ ಪೋರ್ಟ್ ಅನ್ನು ಆಕ್ರಮಿಸಿಕೊಂಡಿರುತ್ತದೆ. ಪ್ರಕ್ರಿಯೆಯ ಹೆಸರು ನಿಮ್ಮನ್ನು ಬೆಚ್ಚಿಬೀಳಿಸಿದರೆ, ಏನನ್ನೂ ಸ್ಪರ್ಶಿಸುವ ಮೊದಲು ss -lntup 'sport = :443' ನಿಂದ ಔಟ್‌ಪುಟ್ ಕಿರಿದಾಗಿಸಿ.
ಜಾಲಬಂಧ ಅನುಮತಿಸಿದಾಗ ಸುರಂಗವನ್ನು UDP ಗೆ ಬದಲಿಸಿ
UDP ಆಲಿಸುವವ ಘರ್ಷಣೆಯನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ತಪ್ಪಿಸುತ್ತದೆ ಮತ್ತು ಸಾಮಾನ್ಯವಾಗಿ ಅತ್ಯಂತ ಚಿಕ್ಕ ದುರಸ್ತಿ, ಏಕೆಂದರೆ ಯಾವುದೇ ಸಾಕೆಟ್ ಹಂಚಿಕೆಯಾಗುವುದಿಲ್ಲ ಮತ್ತು ಹಾದಿಗೆ ಯಾವುದೇ ಹೆಚ್ಚುವರಿ ಉತ್ಪನ್ನ ಸೇರುವುದಿಲ್ಲ. ಆದರೆ ಅದು ಉಚಿತವಲ್ಲ. ಕೆಲವು ಕ್ಲೈಂಟ್ ಜಾಲಗಳು reset ಕಳುಹಿಸದೆ UDP 443 ಅನ್ನು ಬಿಡುತ್ತವೆ, ಆದ್ದರಿಂದ ಸುರಂಗ bind ನಲ್ಲಿ ವಿಫಲವಾಗುವ ಬದಲು ಸ್ಥಾಪನೆಯಾಗುವುದನ್ನು ನಿಲ್ಲಿಸುತ್ತದೆ, ಮತ್ತು ಬಳಕೆದಾರ ಓದಲು ದೋಷವಿಲ್ಲದೆ VPN ನಿಂತಿದೆ ಎಂದು ವರದಿ ಮಾಡುತ್ತಾನೆ. UDP ಆಲಿಸುವವ ವೆಬ್ ಪದರದ ಮರುಪ್ರಾರಂಭವನ್ನೂ ತಡೆದುಕೊಳ್ಳುತ್ತದೆ, ಇದು ಸೈಟ್ ಆಗಾಗ್ಗೆ ಮರುನಿಯೋಜಿಸಲ್ಪಡುವ ಯಂತ್ರದಲ್ಲಿ ಮುಖ್ಯ. ಬಳಕೆದಾರರು ಕುಳಿತಿರುವ ಜಾಲದಿಂದ ಪರೀಕ್ಷಿಸಿ, ಏಕೆಂದರೆ ಸರ್ವರ್‌ನಲ್ಲಿನ shell ಸರ್ವರ್ ತನ್ನನ್ನೇ ತಲುಪಬಲ್ಲದು ಎಂದು ಮಾತ್ರ ಸಾಬೀತುಪಡಿಸುತ್ತದೆ.
ಸರ್ವರ್ ಸಂರಚನೆಯಲ್ಲಿ ಮತ್ತು ಕ್ಲೈಂಟ್ ಪ್ರೊಫೈಲ್‌ನಲ್ಲಿ ಸಾಗಣೆಯನ್ನು ಒಟ್ಟಿಗೆ ಬದಲಿಸಿ. ಇನ್ನೂ TCP ಕೇಳುವ ಪ್ರೊಫೈಲ್ UDP ಮಾತ್ರ ಇರುವ ಆಲಿಸುವವನ ಎದುರು ಮರುಸಂಪರ್ಕ ಚಕ್ರದಲ್ಲಿ ಸುತ್ತುತ್ತದೆ, ಮತ್ತು ಎರಡೂ ಫೈಲ್‌ಗಳನ್ನು ಹೋಲಿಸುವವರೆಗೆ ಅದು ಜಾಲ ದೋಷದಂತೆ ಕಾಣುತ್ತದೆ.
VPN ಪ್ರಕ್ರಿಯೆಗೆ TCP 443 ಅನ್ನು ಹೊಂದಲು ಬಿಡಿ ಮತ್ತು ಉಳಿದದ್ದನ್ನು ಮುಂದಕ್ಕೆ ಕಳುಹಿಸಿ
TCP ಸರ್ವರ್ ಮೋಡ್‌ನಲ್ಲಿ Community OpenVPN ಒಳಬರುವ ಸಂಪರ್ಕದ ಮೊದಲ ಬೈಟ್‌ಗಳನ್ನು ಓದಿ ತನ್ನದಲ್ಲದ ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು HTTPS ಬ್ಯಾಕೆಂಡ್‌ಗೆ ಕಳುಹಿಸುತ್ತದೆ, port-share ಸೂಚನೆ ಅದಕ್ಕೇ ಇದೆ. ಬ್ಯಾಕೆಂಡ್ TLS ಸಕ್ರಿಯವಾಗಿರುವ ಸಾಮಾನ್ಯ ವೆಬ್ ಸರ್ವರ್, ಅದನ್ನು ಆ ಸೂಚನೆಯಲ್ಲಿ URL ನಿಂದಲ್ಲ, ಹೋಸ್ಟ್ ಮತ್ತು ಪೋರ್ಟ್‌ನಿಂದ ಹೆಸರಿಸಲಾಗುತ್ತದೆ.
port-share 10.0.0.5 8080
ಸೈಟ್‌ಗೆ ಎರಡನೇ ಖಾಸಗಿ ವಿಳಾಸವಿರುವ ಯಂತ್ರದಲ್ಲಿ ಆ ಸಾಲು VPN ಅಲ್ಲದ ಸಂಚಾರವನ್ನು 10.0.0.5:8080 ಗೆ ಕಳುಹಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ HTTPS ವರ್ಚುವಲ್ ಹೋಸ್ಟ್ ಅಲ್ಲಿ ಬೈಂಡ್ ಆಗಿರಬೇಕು ಮತ್ತು ಫೈರ್‌ವಾಲ್ ಸ್ಥಳೀಯ ನೆಗೆತಕ್ಕೆ ಅನುಮತಿ ನೀಡಬೇಕು. ವೆಬ್ ಸರ್ವರ್ TLS ಅನ್ನು ತಾನೇ ಮುಗಿಸಬೇಕು, ಏಕೆಂದರೆ ಬರುವ ಬೈಟ್‌ಗಳು ಬ್ರೌಸರ್‌ನ ಮೂಲ ಹ್ಯಾಂಡ್‌ಶೇಕ್ ಮತ್ತು ನಡುವೆ ಯಾವುದೂ ಅವನ್ನು ಡೀಕ್ರಿಪ್ಟ್ ಮಾಡಿಲ್ಲ. ಸೂಚನೆಯನ್ನು ಸಾಮಾನ್ಯ HTTP ಆಲಿಸುವವನ ಕಡೆಗೆ ತಿರುಗಿಸಿ ಮತ್ತು ಬ್ರೌಸರ್‌ಗೆ ಅಮಾನ್ಯ ವಿಧಾನದ ದೋಷ ಸಿಗುತ್ತದೆ, ಅದು ಬ್ಯಾಕೆಂಡ್ ತಪ್ಪು ಜಾಗದಲ್ಲಿದೆ ಎಂಬಂತೆ ಅಲ್ಲ, ಮುರಿದ ಸೈಟ್‌ನಂತೆ ಓದುತ್ತದೆ. ಸೂಚನೆ TCP ಸರ್ವರ್ ಮೋಡ್‌ನಲ್ಲಿ ಮಾತ್ರ ಇದೆ, ಮತ್ತು UDP ಆಲಿಸುವವನಿಗೆ ಪರಿಶೀಲಿಸಲು ಯಾವುದೇ ಸ್ಟ್ರೀಮ್ ಇಲ್ಲ.
VPN ಪ್ರಕ್ರಿಯೆ ಪ್ರತಿ ಸಂಪರ್ಕವನ್ನೂ ಸ್ವೀಕರಿಸುವುದರಿಂದ, ವೆಬ್ ಅಪ್ಲಿಕೇಶನ್ ಮುಂದಕ್ಕೆ ಕಳುಹಿಸಿದ ವಿನಂತಿ ಸಂದರ್ಶಕನಿಂದಲ್ಲ, ಹೋಸ್ಟ್‌ನ ಸ್ವಂತ ವಿಳಾಸಗಳಿಂದ ಬರುತ್ತಿರುವುದನ್ನು ಕಾಣುತ್ತದೆ. ನಿಜವಾದ ಕ್ಲೈಂಟ್ ವಿಳಾಸ ಬೇಕಾದ ಯಾವುದೂ ಬ್ಯಾಕೆಂಡ್‌ನಲ್ಲಿ PROXY ಪ್ರೋಟೋಕಾಲ್ ಬೆಂಬಲ ಅಥವಾ ಅದನ್ನು ಸೇರಿಸುವ ಮುಂಭಾಗವನ್ನು ಅವಲಂಬಿಸಿದೆ. ಬ್ಯಾಕೆಂಡ್ ಅನ್ನು ಇನ್ನೊಂದು ಸ್ಥಳೀಯ ವಿಳಾಸಕ್ಕೆ ಸರಿಸುವುದು ಸಂದರ್ಶಕನ ವಿಳಾಸವನ್ನು ಮರಳಿ ತರುವುದಿಲ್ಲ; ಅದು ಸೈಟ್ ಹೋಸ್ಟ್‌ನ ಯಾವ ವಿಳಾಸಗಳನ್ನು ದಾಖಲಿಸುತ್ತದೆ ಎಂಬುದನ್ನಷ್ಟೇ ಬದಲಿಸುತ್ತದೆ. ವಿಶ್ಲೇಷಣಾ ವರದಿ ಪ್ರಶ್ನೆ ಎತ್ತುವ ಮೊದಲು ಈ ಮಿತಿಯನ್ನು ನಿಯೋಜನಾ ಟಿಪ್ಪಣಿಗಳಲ್ಲಿ ಬರೆಯಿರಿ.
ರಿವರ್ಸ್ ಪ್ರಾಕ್ಸಿ ತಪ್ಪು ಸಾಧನ; ಲೇಯರ್-ನಾಲ್ಕು ರೌಟರ್ ಅಲ್ಲ
HTTP ರಿವರ್ಸ್ ಪ್ರಾಕ್ಸಿ ವಿನಂತಿಗಳನ್ನು ಓದಲು TLS ಅನ್ನು ಮುಗಿಸುತ್ತದೆ, ಅಂದರೆ ಅದು OpenVPN ಸ್ಟ್ರೀಮ್ ಅನ್ನು ಮುಟ್ಟದೆ ಹಾದುಹೋಗಲು ಬಿಡಲಾರದು. SNI ಅಥವಾ ಮೊದಲ ಪ್ಯಾಕೆಟ್ ಪರಿಶೀಲನೆಯ ಪ್ರಕಾರ ಮುಂದಕ್ಕೆ ಕಳುಹಿಸುವ ಲೇಯರ್-ನಾಲ್ಕು ರೌಟರ್, VPN ಅವಲಂಬಿಸಿರುವ ಅಧಿವೇಶನವನ್ನು ಮುಗಿಸದಿದ್ದರೆ ಎರಡರ ಮುಂದೆಯೂ ನಿಲ್ಲಬಹುದು. ಎರಡೂ ಸಾಧನಗಳು ರೇಖಾಚಿತ್ರದಲ್ಲಿ ಒಂದೇ ರೀತಿ ಕಾಣುತ್ತವೆ ಮತ್ತು ಸಾಕೆಟ್‌ನಲ್ಲಿ ಸಂಪೂರ್ಣವಾಗಿ ಬೇರೆಯಾಗಿ ವರ್ತಿಸುತ್ತವೆ.
ವಾಣಿಜ್ಯ Access Server ತನ್ನದೇ ಪೋರ್ಟ್ ಹಂಚಿಕೆ ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ತರುತ್ತದೆ, ಮತ್ತು ಅವು ಸಮುದಾಯ ಸೂಚನೆಗೆ ಒಂದಕ್ಕೊಂದು ಹೊಂದಿಕೆಯಾಗುವುದಿಲ್ಲ. ಇನ್ನೊಂದಕ್ಕಾಗಿ ಬರೆದ ಮಾರ್ಗದರ್ಶಿಯನ್ನು ಹೊಂದಿಸುವ ಮೊದಲು ಉತ್ಪನ್ನ ಮತ್ತು ಆವೃತ್ತಿಯನ್ನು ಗುರುತಿಸಿ. ಮೌನವಾಗಿ ನಿರ್ಲಕ್ಷಿಸಲ್ಪಟ್ಟ ನಕಲು ಸೆಟ್ಟಿಂಗ್ ಸೆಟ್ಟಿಂಗ್ ಇಲ್ಲದಿರುವುದಕ್ಕಿಂತ ಕೆಟ್ಟದು, ಏಕೆಂದರೆ ನಂತರವೂ ಆಲಿಸುವವರ ಪಟ್ಟಿ ನಂಬಲರ್ಹವಾಗಿ ಕಾಣುತ್ತದೆ.
ವೆಬ್‌ಸೈಟ್ ಮತ್ತು ಸುರಂಗವನ್ನು ಎರಡು ಪ್ರತ್ಯೇಕ ಮಾರ್ಗಗಳಾಗಿ ಪರೀಕ್ಷಿಸಿ
ಸೈಟ್ ಲೋಡ್ ಮಾಡಿ ಮತ್ತು ಸುರಂಗ ಸಂಪರ್ಕಿಸಿ, ನಂತರ 443 ಅನ್ನು ಈಗ ಯಾವ ಪ್ರಕ್ರಿಯೆ ಹೊಂದಿದೆ ಎಂದು ನೋಡಲು ಆಲಿಸುವವರ ಪಟ್ಟಿಯನ್ನು ಮತ್ತೆ ಓದಿ. ಲೋಡ್ ಆಗುವ ಪುಟ VPN ಬಗ್ಗೆ ಏನನ್ನೂ ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ, ಮತ್ತು ಸಂಪರ್ಕಗೊಳ್ಳುವ ಸುರಂಗ ಸೈಟ್ ಬಗ್ಗೆ ಏನನ್ನೂ ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ, ಎರಡೂ ಒಂದೇ ಸಂಖ್ಯೆಯನ್ನು ಬಳಸಿದರೂ. ಕೆಳಗಿನ ಮೂರು ಆಜ್ಞೆಗಳು ಹಂಚಿದ ಸಾಕೆಟ್, ವೆಬ್ ಮಾರ್ಗ ಮತ್ತು VPN ಸೇವೆಯನ್ನು ಆ ಕ್ರಮದಲ್ಲಿ ಪರಿಶೀಲಿಸುತ್ತವೆ.
ss -lntup 'sport = :443' curl -sI https://vpn.example.com/ | head -n 1 journalctl -u openvpn-server@server -n 20
ಅದೇ ಕ್ಷಣಕ್ಕೆ ಬ್ಯಾಕೆಂಡ್‌ನ ಪ್ರವೇಶ ಲಾಗ್‌ನಲ್ಲಿನ ಕ್ಲೈಂಟ್ ವಿಳಾಸವನ್ನು VPN ಲಾಗ್‌ನಲ್ಲಿನದಕ್ಕೆ ಹೋಲಿಸಿ. ಸೈಟ್ ಪ್ರತಿ ಸಂದರ್ಶಕನನ್ನು ಹೋಸ್ಟ್ ತಾನೇ ಎಂದು ದಾಖಲಿಸಿದರೆ ಮುಂದಕ್ಕೆ ಕಳುಹಿಸುವಿಕೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ ಮತ್ತು ವಿಳಾಸ ನಿರ್ವಹಣೆ ಮಾಡುವುದಿಲ್ಲ. ಎರಡೂ ಲಾಗ್‌ಗಳು ಮೌನವಾಗಿದ್ದರೆ ಮುಂಭಾಗ ಸಂಪರ್ಕವನ್ನು ಎಂದಿಗೂ ಒಪ್ಪಿಸಿಲ್ಲ. ಹೇಗಾದರೂ, ಆಲಿಸುವವರ ಪಟ್ಟಿ ಸಾಕೆಟ್ ಅನ್ನು ಯಾರು ಸ್ವೀಕರಿಸುತ್ತಾರೆ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ, ಮತ್ತು ಇನ್ನೊಂದು ಫೈಲ್ ಬದಲಿಸುವ ಮೊದಲು ದೃಢೀಕರಿಸಬೇಕಾದ ಸಂಗತಿ ಅದೇ.
ಆ ಆಲಿಸುವವರ ನಕ್ಷೆಯನ್ನು ಸಂರಚನೆಯ ಪಕ್ಕದಲ್ಲಿ ಬಿಡಿ, ಇದರಿಂದ 443 ಅನ್ನು ಮುಟ್ಟುವ ಮುಂದಿನ ವ್ಯಕ್ತಿ ಯಾವ ಪ್ರಕ್ರಿಯೆ ಸ್ವೀಕರಿಸುತ್ತದೆ ಮತ್ತು ಇನ್ನೊಂದು ಪ್ರೋಟೋಕಾಲ್ ಎಲ್ಲಿಗೆ ಹೋಯಿತು ಎಂದು ತಿಳಿಯುತ್ತಾನೆ. ಸಂಪಾದನೆ ಏನು ಮಾಡಬೇಕಿತ್ತು ಎಂಬುದನ್ನು ನಂಬುವ ಬದಲು ಬದಲಾವಣೆಯ ನಂತರ ಮಾಲೀಕತ್ವವನ್ನು ದೃಢೀಕರಿಸಿ.