ಒಂದು Pi, ಎರಡು OpenVPN ಇನ್ಸ್ಟಾನ್ಸ್ಗಳು: ಪ್ರತಿ ಯೂನಿಟ್ ಏನನ್ನು ಓದುತ್ತದೆ
ಒಂದೇ Pi ಮೇಲಿನ ಎರಡು OpenVPN ಡೀಮನ್ಗಳು ಬೇರೆ ಬೇರೆ ಕಾನ್ಫಿಗ್ ಫೈಲ್ಗಳನ್ನು ಓದಿ ಬೇರೆ ಬೇರೆ ಹುಕ್ ಮೂಲಕ ಹೊರಡುತ್ತವೆ. ಪ್ರತಿ ಇನ್ಸ್ಟಾನ್ಸ್ ಅನ್ನು ನಕ್ಷೆ ಮಾಡಿ, ನಂತರ ಪೇಲೋಡ್ ಮಾರ್ಗವನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಪರೀಕ್ಷಿಸಿ.
ಪ್ರೊಫೈಲ್ ಮುಟ್ಟುವ ಮೊದಲು OpenVPN ಪ್ರಕ್ರಿಯೆಗಳನ್ನು ಎಣಿಸಿ. ರೋಮಿಂಗ್ ಬಳಕೆದಾರರನ್ನು ಸ್ವೀಕರಿಸುತ್ತಾ ಅದೇ ಸಮಯದಲ್ಲಿ ಅಪ್ಸ್ಟ್ರೀಮ್ ಸೇವೆಗೆ ಡಯಲ್ ಮಾಡುವ Pi ಎರಡು ಡೀಮನ್ಗಳನ್ನು ಚಲಾಯಿಸುತ್ತದೆ, ಮತ್ತು ಅವುಗಳಲ್ಲಿ ಪ್ರತಿಯೊಂದೂ ನೀವು ಟೈಪ್ ಮಾಡಿದ ಇನ್ಸ್ಟಾನ್ಸ್ ಹೆಸರಿನಿಂದ ಆಯ್ಕೆಯಾದ ಕಾನ್ಫಿಗ್ ಫೈಲ್ ಅನ್ನು ಓದುತ್ತದೆ. ಪ್ಯಾಕೇಜ್ ಟೆಂಪ್ಲೇಟ್ಗಳು ನಂತರ ಪ್ರತಿ ಡೀಮನ್ಗೆ ತನ್ನದೇ ಕೆಲಸದ ಡೈರೆಕ್ಟರಿ, ತನ್ನದೇ ರನ್ಟೈಮ್ ಸ್ಥಿತಿ ಫೈಲ್ ಮತ್ತು ತನ್ನದೇ ಟನೆಲ್ ಸಾಧನವನ್ನು ನೀಡುತ್ತವೆ. ಈ ವಿಭಜನೆಯನ್ನು ತಪ್ಪಾಗಿ ಮಾಡಿದರೆ, ಚಾಲನೆಯಲ್ಲಿರುವ ಪ್ರಕ್ರಿಯೆ ಎಂದಿಗೂ ತೆರೆಯದ ಫೈಲ್ನಲ್ಲಿನ ಸರಿಯಾದ ಸೆಟ್ಟಿಂಗ್ ಅನ್ನು ಬದಲಾಯಿಸುತ್ತಾ ಒಂದು ಸಂಜೆ ಕಳೆಯುತ್ತೀರಿ.
ಪ್ರತಿ ಇನ್ಸ್ಟಾನ್ಸ್ ಹೆಸರು ತನ್ನದೇ ಫೈಲ್ ಆಯ್ಕೆ ಮಾಡುತ್ತದೆ
OpenVPN 2.6 ಜೊತೆ ಬರುವ ಯೂನಿಟ್ ಫೈಲ್ಗಳಲ್ಲಿ, ಸ್ಟಾರ್ಟ್ ಆರ್ಗ್ಯುಮೆಂಟ್ಗಳು @ ಚಿಹ್ನೆಯ ನಂತರದ ಪಠ್ಯದಿಂದ ತುಂಬುವ ಇನ್ಸ್ಟಾನ್ಸ್ ಪ್ಲೇಸ್ಹೋಲ್ಡರ್ ಅನ್ನು ಹೊಂದಿರುತ್ತವೆ. ಸರ್ವರ್ ಟೆಂಪ್ಲೇಟ್ ಸರ್ವರ್ ಕಾನ್ಫಿಗ್ ಡೈರೆಕ್ಟರಿಯಿಂದ ಚಲಿಸಿ ತನ್ನ ಆರ್ಗ್ಯುಮೆಂಟ್ ಅನ್ನು ಅಲ್ಲಿನ %i.conf ಗೆ ವಿರುದ್ಧವಾಗಿ ಪರಿಹರಿಸುತ್ತದೆ, ಕ್ಲೈಂಟ್ ಟೆಂಪ್ಲೇಟ್ ಕ್ಲೈಂಟ್ ಡೈರೆಕ್ಟರಿಯಿಂದ ಅದೇ ರೀತಿ ಮಾಡುತ್ತದೆ. ಹಾಗಾಗಿ [email protected] ಸರ್ವರ್ ಡೈರೆಕ್ಟರಿಯಲ್ಲಿನ admits.conf ಓದುತ್ತದೆ ಮತ್ತು [email protected] ಕ್ಲೈಂಟ್ ಡೈರೆಕ್ಟರಿಯಲ್ಲಿನ uplink.conf ಓದುತ್ತದೆ, ಮತ್ತು ಆ ಹೆಸರುಗಳಲ್ಲಿ ಯಾವುದಕ್ಕೂ ಇನ್ನೊಂದು ಡೈರೆಕ್ಟರಿಯಲ್ಲಿ ಯಾವುದೇ ಅರ್ಥವಿಲ್ಲ.
ಪ್ಯಾಕೇಜ್ ಅಪ್ಸ್ಟ್ರೀಮ್ ಡಿಫಾಲ್ಟ್ಗಳನ್ನು ಉಳಿಸಿಕೊಂಡಿದೆ ಎಂದು ಊಹಿಸದೆ, ಯಂತ್ರದಲ್ಲಿ ನಕ್ಷೆಯನ್ನು ದೃಢೀಕರಿಸಿ. ಡಿಸ್ಟ್ರಿಬ್ಯೂಷನ್ drop-in ಕೆಲಸದ ಡೈರೆಕ್ಟರಿ ಅಥವಾ ಕಾನ್ಫಿಗ್ ಆರ್ಗ್ಯುಮೆಂಟ್ ಅನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಬದಲಾಯಿಸಬಹುದು.
systemctl cat [email protected]
systemctl cat [email protected]ಆ ಔಟ್ಪುಟ್ನಲ್ಲಿ WorkingDirectory ಸಾಲು ಮತ್ತು ಕಾನ್ಫಿಗ್ ಆರ್ಗ್ಯುಮೆಂಟ್ ಓದಿ, ಏಕೆಂದರೆ ಯಾವ ಫೈಲ್ ಲೋಡ್ ಆಗುತ್ತದೆ ಎಂಬುದನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಿದ ಯೂನಿಟ್ ಮಾತ್ರ ನಿರ್ಧರಿಸುತ್ತದೆ. ExecStart ಗೆ --config ಸೇರಿಸುವ drop-in, ಟೆಂಪ್ಲೇಟ್ ಮಾರ್ಗ ಸರಿಯಾಗಿ ಕಂಡರೂ ಟೆಂಪ್ಲೇಟ್ ಮೇಲೆ ಗೆಲ್ಲುತ್ತದೆ. ಸ್ಥಳೀಯ ಓವರ್ರೈಡ್ ಇದೆಯೇ ಎಂದು ತಿಳಿಯಲು ಫ್ರಾಗ್ಮೆಂಟ್ ಮತ್ತು drop-in ಮಾರ್ಗಗಳನ್ನು ಕೇಳಿ. ಎರಡೂ ಪಾತ್ರಗಳು ಒಂದೇ ಫೈಲ್ಗೆ ಪರಿಹರಿಸಿದರೆ, ಒಂದೇ ಪ್ರಕ್ರಿಯೆ ಸರ್ವರ್ ಮತ್ತು ಕ್ಲೈಂಟ್ ಎರಡೂ ಆಗಲು ಪ್ರಯತ್ನಿಸುತ್ತಿದೆ, ಮತ್ತು ಆ ಫೈಲ್ನಲ್ಲಿ ನಂತರದ ಆಯ್ಕೆ ಮೌನವಾಗಿ ಗೆಲ್ಲುತ್ತದೆ.
ಸ್ಥಳೀಯ ಸಾಗಣೆ ಮತ್ತು ಫಾರ್ವರ್ಡ್ ಆದ ಪೇಲೋಡ್ ಬೇರೆ ಬೇರೆ ಹುಕ್ ತಲುಪುತ್ತವೆ
ಸರ್ವರ್ನ ಪ್ರತಿ ರೋಮಿಂಗ್ ಬಳಕೆದಾರರಿಗೆ ಇರುವ ಗೂಢಲಿಪೀಕೃತ ಸಂಪರ್ಕ Pi ಯಲ್ಲೇ ಉತ್ಪಾದನೆಯಾಗುತ್ತದೆ, ಆದ್ದರಿಂದ ಅದರ ಹೊರಗಿನ ಪ್ರತ್ಯುತ್ತರಗಳು ಸ್ಥಳೀಯ ಔಟ್ಪುಟ್ ಹುಕ್ ಮೂಲಕ ಹೊರಡುತ್ತವೆ. ಕ್ಲೈಂಟ್ನ ಅಪ್ಸ್ಟ್ರೀಮ್ ಪೀರ್ನೊಂದಿಗಿನ ಸಂಪರ್ಕವೂ ಸ್ಥಳೀಯವಾಗಿ ಉತ್ಪಾದಿಸಿದ ಔಟ್ಪುಟ್, ಅದು ದೂರದ ನೆಟ್ವರ್ಕ್ ತಲುಪಿದರೂ ಸಹ. ಫಾರ್ವರ್ಡ್ ಆದ ಪೇಲೋಡ್ ಮೂರನೇ ವರ್ಗ, ಮತ್ತು ಪ್ಯಾಕೆಟ್ಗೆ ಹೊರಹೋಗುವ ಸಾಧನವನ್ನು ಈಗಾಗಲೇ ಆಯ್ಕೆ ಮಾಡಿದ ನಂತರವೇ ಕರ್ನಲ್ ಅದನ್ನು ಹೊಂದಿಸುತ್ತದೆ.
| Flow | Hook that sees it | What to inspect |
|---|---|---|
| Roaming user handshakes to the server | Local input and local output | Listener socket, bind address, rule admitting the UDP port |
| User payload leaving through the upstream tunnel | Forward | IPv4 forwarding switch, selected route, permission rule, any translation |
| Pi's own connection to the upstream peer | Local output | Underlay route to the provider endpoint, not the tunnel route |
ಫಾರ್ವರ್ಡ್ ಸರಪಳಿಯಲ್ಲಿ ಹೊರಹೋಗುವ ಇಂಟರ್ಫೇಸ್ಗೆ ಹೊಂದುವ ನಿಯಮವು, ರೂಟಿಂಗ್ ಈಗಾಗಲೇ ಆ ಇಂಟರ್ಫೇಸ್ಗೆ ನಿಗದಿಪಡಿಸಿದ ಪ್ಯಾಕೆಟ್ ಅನ್ನು ಅನುಮತಿಸಬಹುದು ಅಥವಾ ಬಿಡಬಹುದು, ಆದರೆ ಅದು ಎಂದಿಗೂ ಇಂಟರ್ಫೇಸ್ ಆಯ್ಕೆ ಮಾಡುವುದಿಲ್ಲ. ಒಂದು ಹೋಸ್ಟ್ ಒಂದು ಟನೆಲ್ ಅನ್ನು ಕೊನೆಗೊಳಿಸಿ ಇನ್ನೊಂದನ್ನು ಪ್ರಾರಂಭಿಸಿದಾಗ, ಬಳಕೆದಾರರ ಪೇಲೋಡ್ ಅನ್ನು ಅಪ್ಸ್ಟ್ರೀಮ್ ಟನೆಲ್ಗೆ ಕಳುಹಿಸುವ ನೀತಿ ಮತ್ತು Pi ಯ ಸ್ವಂತ ಗೂಢಲಿಪೀಕೃತ ಪ್ರತ್ಯುತ್ತರಗಳನ್ನು ರಕ್ಷಿಸುವ ನೀತಿ ಬೇರೆ ಬೇರೆ ನಿರ್ಧಾರಗಳು. ಅವು ಆಕಸ್ಮಿಕವಾಗಿ ಒಂದೇ ಭೌತಿಕ NIC ಮೇಲೆ ಬೀಳುತ್ತವೆ, ಹಾಗಾಗಿ ಅವು ಗೊಂದಲಕ್ಕೊಳಗಾಗುತ್ತವೆ.
ಆ ವ್ಯತ್ಯಾಸವು ಸಾಮಾನ್ಯ ಅರ್ಧ-ವೈಫಲ್ಯವನ್ನು ವಿವರಿಸುತ್ತದೆ. ಬಳಕೆದಾರರು ಸಂಪರ್ಕಗೊಳ್ಳುತ್ತಾರೆ, handshake ಪೂರ್ಣಗೊಳ್ಳುತ್ತದೆ, ಆದರೂ ಅವರ ಸಂಚಾರ ತಪ್ಪು ದಾರಿಯಲ್ಲಿ ಹೊರಡುತ್ತದೆ, ಏಕೆಂದರೆ handshake ಸ್ಥಳೀಯವಾಗಿತ್ತು ಮತ್ತು ಪೇಲೋಡ್ ಫಾರ್ವರ್ಡ್ ಆಗಿತ್ತು ಮತ್ತು ಎರಡರಲ್ಲಿ ಒಂದನ್ನು ಮಾತ್ರ ಪರೀಕ್ಷಿಸಲಾಗಿತ್ತು.
ಆಮದು ಮಾಡಿದ ಮಾರ್ಗವು ನಿಮ್ಮ ಬಳಕೆದಾರರಿಗೆ ಪ್ರತ್ಯುತ್ತರಗಳನ್ನು ನುಂಗಬಹುದು
ಕ್ಲೈಂಟ್ ಪ್ರೊಫೈಲ್ನ ಭದ್ರತಾ ಸೆಟ್ಟಿಂಗ್, ಅಪ್ಸ್ಟ್ರೀಮ್ Pi ಯ ರೂಟಿಂಗ್ ಟೇಬಲ್ಗೆ ಏನನ್ನು push ಮಾಡಬಹುದು ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ, ಮತ್ತು ವಿಶಾಲ redirect ಎಂಬುದು ಕೆಲಸ ಮಾಡುತ್ತಿದ್ದ ದ್ವಿ-ಪಾತ್ರ ಹೋಸ್ಟ್ ಅನ್ನು ಮುರಿದದ್ದಾಗಿ ಮಾಡುವ ಆಯ್ಕೆ. push ಆದ ಮಾರ್ಗವು ರೋಮಿಂಗ್ ಬಳಕೆದಾರರ ಸಾರ್ವಜನಿಕ ವಿಳಾಸಗಳನ್ನು ಆವರಿಸಿದರೆ, ಸರ್ವರ್ ಅವರ ಕಡೆಗೆ ಉತ್ಪಾದಿಸುವ ಪ್ರತ್ಯುತ್ತರಗಳು underlay ಮೂಲಕ ಹೊರಡುವ ಬದಲು ಹೊಸ ಮಾರ್ಗವನ್ನು ಅನುಸರಿಸಿ ಅಪ್ಸ್ಟ್ರೀಮ್ ಟನೆಲ್ ಪ್ರವೇಶಿಸಬಹುದು. ಪ್ರೊವೈಡರ್ಗೆ ಇರುವ ಟನೆಲ್ ಇನ್ನೂ ಕೆಲಸ ಮಾಡುತ್ತದೆ ಎಂದು ಖಚಿತಪಡಿಸಿ ಅಲ್ಲೇ ನಿಲ್ಲುತ್ತಾರೆ, ಏಕೆಂದರೆ ಆ ಸಂಚಾರ ಟನೆಲ್ನ ಸ್ವಂತ ಸಾಗಣೆ ಮತ್ತು ಉಳಿದೆಲ್ಲವೂ ತಪ್ಪಾಗಿ ವರ್ತಿಸುತ್ತಿದ್ದರೂ ಅದು ಹರಿಯುತ್ತಲೇ ಇರುತ್ತದೆ.
ಮೂಲ ಅಥವಾ mark ಆಧಾರಿತ ನೀತಿಯೇ ಎರಡು ಹರಿವುಗಳನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಇರಿಸುವ ದಾರಿ. OpenVPN ನ Linux mark ಆಯ್ಕೆ ಡೀಮನ್ನ ಸ್ವಂತ ಗೂಢಲಿಪೀಕೃತ ಪ್ಯಾಕೆಟ್ಗಳಿಗೆ firewall mark ಹಾಕುತ್ತದೆ, ನಂತರ ರೂಟಿಂಗ್ ನಿಯಮ ಅದನ್ನು ಮೀಸಲಾದ ಟೇಬಲ್ಗೆ ಕಳುಹಿಸಬಹುದು. ಸರ್ವರ್ನ ಹೊರಗಿನ ಪ್ರತ್ಯುತ್ತರಗಳು ಯಾವಾಗಲೂ ಒಂದೇ underlay ವಿಳಾಸದಿಂದ ಹೊರಟಾಗ ಮೂಲ ವಿಳಾಸಗಳೂ ಸಮಾನವಾಗಿ ಕೆಲಸ ಮಾಡುತ್ತವೆ. ಎರಡೂ ವಿಧಾನಗಳಿಗೂ ಅದು ಆಯ್ಕೆ ಮಾಡುವ ಟೇಬಲ್ನಲ್ಲಿ ಮಾನ್ಯ ಮಾರ್ಗಗಳು ಮತ್ತು ಪ್ರೊವೈಡರ್ನ endpoint ಗೆ ವಿನಾಯಿತಿ ಬೇಕು, ಇಲ್ಲದಿದ್ದರೆ ಟನೆಲ್ ಸ್ವತಃ ಮೇಲೇಳುವುದಿಲ್ಲ.
ಯಾವುದೇ ನಿಯಮ ಬರೆಯುವ ಮೊದಲು ಪ್ರತ್ಯುತ್ತರವು ನಿಜವಾಗಿ ಹೋಗುವ ಮಾರ್ಗವನ್ನು ಕರ್ನಲ್ಗೆ ಕೇಳಿ. ಕೆಳಗಿನ ವಿಳಾಸಗಳು Pi ಯ underlay ವಿಳಾಸ ಮತ್ತು ಒಬ್ಬ ರೋಮಿಂಗ್ ಬಳಕೆದಾರರ ಸಾರ್ವಜನಿಕ ವಿಳಾಸಕ್ಕೆ ಪ್ಲೇಸ್ಹೋಲ್ಡರ್ಗಳು.
ip rule show
ip route get 198.51.100.7 from 192.0.2.10ವಿಭಜನೆಯನ್ನು ಪರಿಶೀಲಿಸಿ, ನಂತರ ಒಂದೊಂದು ಪಾತ್ರವನ್ನು ನಿಲ್ಲಿಸಿ
ಮೂರು ಹರಿವುಗಳನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಪರೀಕ್ಷಿಸಿ, ಏಕೆಂದರೆ ಯಶಸ್ವಿ handshake ಉಳಿದ ಎರಡರ ಬಗ್ಗೆ ಏನನ್ನೂ ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ. ಹೊಸ ಒಳಬರುವ ಸಂಪರ್ಕವನ್ನು ಸ್ವೀಕರಿಸಿ, ಒಂದು ಅನುಮತಿಸಿದ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಅಪ್ಸ್ಟ್ರೀಮ್ ನಿರ್ಗಮನದ ಮೂಲಕ ಕಳುಹಿಸಿ, ಮತ್ತು ಎರಡೂ ಪ್ರಕ್ರಿಯೆಗಳು ಇನ್ನೂ ತಮ್ಮ ಪೀರ್ಗಳನ್ನು ತಲುಪುತ್ತವೆ ಎಂದು ದೃಢೀಕರಿಸಿ.
ನಂತರ ಕ್ಲೈಂಟ್ ಪಾತ್ರವನ್ನು ನಿಲ್ಲಿಸಿ ಸರ್ವರ್ ಪಾತ್ರ ಏನನ್ನು ಉಳಿಸಿಕೊಳ್ಳುತ್ತದೆ ಎಂದು ಗಮನಿಸಿ. ಒಂದು ಇನ್ಸ್ಟಾನ್ಸ್ಗೆ ಉದ್ದೇಶಿಸಿ ಎರಡಕ್ಕೂ ಅನ್ವಯಿಸಿದ ಮಾರ್ಗ ಅಥವಾ mark ನಿಯಮವನ್ನು ಹುಡುಕುವ ಅಗ್ಗದ ದಾರಿ ಇದು.
systemctl stop [email protected]
systemctl status [email protected] --no-pager
ss -lunp | grep openvpn
journalctl -u [email protected] -n 20 --no-pagerಕ್ಲೈಂಟ್ ಪಾತ್ರ ಕೆಳಗಿರುವಾಗ listener ಇನ್ನೂ ಬೈಂಡ್ ಆಗಿರುವುದು, ಟನೆಲ್ ಸಾಧನ ಇನ್ನೂ ಇರುವುದು ಮತ್ತು ಲಾಗ್ ಹೊಸ ದೋಷಗಳಿಂದ ಮುಕ್ತವಾಗಿರುವುದನ್ನು ನೀವು ನೋಡಲು ಬಯಸುತ್ತೀರಿ. ಕ್ಲೈಂಟ್ ನಿಲ್ಲಿಸಿದರೆ ಸರ್ವರ್ನ ಪ್ರಸ್ತುತ ಬಳಕೆದಾರರಿಗೆ ಇರುವ ಪ್ರತ್ಯುತ್ತರಗಳೂ ಕಡಿತಗೊಂಡರೆ, ಎರಡೂ ಪಾತ್ರಗಳು ಒಂದಕ್ಕೆ ಮಾತ್ರ ಸೀಮಿತವಾಗಿರಬೇಕಿದ್ದ ಯಾವುದನ್ನೋ ಹಂಚಿಕೊಳ್ಳುತ್ತಿವೆ. ಪ್ರತಿ ಬದಲಾವಣೆ ಯಾವ ಇನ್ಸ್ಟಾನ್ಸ್, ಯಾವ ಕಾನ್ಫಿಗ್ ಫೈಲ್ ಮತ್ತು ಯಾವ ಹರಿವಿನ ಮಾಲೀಕರನ್ನು ಮುಟ್ಟಿತು ಎಂದು ದಾಖಲಿಸಿ, ಇಲ್ಲದಿದ್ದರೆ ಈ ಹೋಸ್ಟ್ ಅನ್ನು ಮುಂದೆ ಡೀಬಗ್ ಮಾಡುವವರು ಅದೇ ಅನ್ವೇಷಣೆಯನ್ನು ಶೂನ್ಯದಿಂದ ಪುನರಾವರ್ತಿಸುತ್ತಾರೆ.