GCE ನಲ್ಲಿ OpenVPN: routes push ಮಾಡುವ ಮೊದಲು alias IP ಸೇರಿಸಿ

ಕ್ಲೈಂಟ್ Compute Engine VM ನಲ್ಲಿನ OpenVPN ಸರ್ವರ್ಗೆ ಡಯಲ್ ಮಾಡುತ್ತದೆ, ಸ್ಥಿತಿ ವಿಂಡೋ ಸಂಪರ್ಕವಾಗಿದೆ ಎಂದು ಹೇಳುತ್ತದೆ, ಆದರೆ VPC ಒಳಗಿನ host ಗೆ ping ಇನ್ನೂ ಎಲ್ಲಿಗೂ ತಲುಪುತ್ತಿಲ್ಲ. ಸಹಜ ಪ್ರವೃತ್ತಿ ಇನ್ನೊಂದು push ಸಾಲನ್ನು ಸೇರಿಸಲು ಹೇಳುತ್ತದೆ, ಅದು ಎಂದಿಗೂ ಸರಿಪಡಿಸುವುದಿಲ್ಲ. Compute Engine ತನ್ನ ಸ್ವಂತ route ಕೋಷ್ಟಕ ಮತ್ತು VM ಇಂಟರ್ಫೇಸ್ ನಿಜವಾಗಿ ಹೊಂದಿರುವ ವಿಳಾಸಗಳ ಆಧಾರದ ಮೇಲೆ packet ಎಲ್ಲಿಗೆ ಹೋಗುತ್ತವೆ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ VM ಗೆ ಸ್ವಂತವಲ್ಲದ tunnel pool ಎಂದರೆ ಯಾರೂ ತಲುಪಿಸದ pool.

ಕಾನ್ಫಿಗರೇಶನ್ ಫೈಲ್ ಬದಲು ವಿಫಲವಾಗುತ್ತಿರುವ packet ಅನ್ನು ಅನುಸರಿಸಿ, ಮತ್ತು ಕಾಣೆಯಾದ ಭಾಗಗಳು ಕ್ರಮವಾಗಿ ಕಾಣಿಸುತ್ತವೆ.

ಸಾಯುತ್ತಿರುವ packet ನಿಂದ ಪ್ರಾರಂಭಿಸಿ

SYN ಕ್ಲೈಂಟ್ ಬಿಟ್ಟು, tunnel ಗೆ ಪ್ರವೇಶಿಸಿ, VPC ಒಳಗಿನ ಗಮ್ಯಸ್ಥಾನಕ್ಕಾಗಿ encapsulated packet ಆಗಿ VM ತಲುಪುತ್ತದೆ. OpenVPN ಅದನ್ನು decapsulate ಮಾಡಿ eth0 ಮೂಲಕ ಕಳುಹಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತದೆ, ಅಲ್ಲಿ fabric ಎಲ್ಲದಕ್ಕೂ ಮೊದಲು ಒಂದು ಪ್ರಶ್ನೆ ಕೇಳುತ್ತದೆ: ಈ instance ಗಮ್ಯ ವಿಳಾಸದ ಮಾಲೀಕನೇ. ಇನ್ನೊಬ್ಬರ subnet ನಿಂದ ಕತ್ತರಿಸಿದ tunnel pool ಆ ಪ್ರಶ್ನೆಯಲ್ಲಿ ವಿಫಲವಾಗುತ್ತದೆ, ಮತ್ತು ಯಾವುದೇ route ಅಥವಾ firewall ನಿಯಮ ನೋಡುವ ಮೊದಲೇ packet ಎಸೆಯಲ್ಪಡುತ್ತದೆ.

ಆದ್ದರಿಂದ ಕ್ಲೈಂಟ್ನಿಂದ VPC ದಿಕ್ಕಿಗೆ ಎರಡು ಪ್ರತ್ಯೇಕ ಅಗತ್ಯಗಳಿವೆ, ಅವುಗಳಲ್ಲಿ ಯಾವುದೂ push ಸೂಚನೆ ಅಲ್ಲ. VM ಗೆ tunnel pool ಅನ್ನು ಆವರಿಸುವ alias ಶ್ರೇಣಿ ಬೇಕು, ಅದೇ ಅದನ್ನು ಆ ವಿಳಾಸಗಳ ಕಾನೂನುಬದ್ಧ ಮಾಲೀಕನನ್ನಾಗಿ ಮಾಡುತ್ತದೆ. VPC ಗೆ ಪ್ರತಿ ಸಂರಕ್ಷಿತ prefix ಗೆ VM ಅನ್ನು next hop ಎಂದು ಹೆಸರಿಸುವ route ಬೇಕು. ಒಂದು ತಪ್ಪಿದರೂ packet ಬೇರೆಡೆ ಸಾಯುತ್ತದೆ, ಕ್ಲೈಂಟ್ ಮಾತ್ರ ಅದೇ ಮೌನವನ್ನು ಕಾಣುತ್ತದೆ.

ವೈಫಲ್ಯವನ್ನು ಅದೇ ಕ್ರಮದಲ್ಲಿ ಓದಿ, ಏಕೆಂದರೆ ಕ್ಲೈಂಟ್ ಬದಿಯಿಂದ ಎರಡೂ ಷರತ್ತುಗಳು ಒಂದೇ ರೀತಿ ಕಾಣುತ್ತವೆ. ಯಾವುದೂ ಉತ್ತರಿಸದಿರುವಾಗ ಸಂಪರ್ಕವಾಗಿದೆ ಎಂದು ವರದಿ ಮಾಡುವ tunnel ಟೋಪಾಲಜಿ ಸಮಸ್ಯೆಯ ಸೂಚನೆ, ಕೆಟ್ಟ cipher ನದಲ್ಲ.

instance tunnel pool ನ ಮಾಲೀಕನೇ

VM ಗೆ ಅದರ ಸ್ವಂತ subnet ಒಳಗೆ ದ್ವಿತೀಯ ಶ್ರೇಣಿ ನೀಡಿ, ನಂತರ OpenVPN ಸರಿಯಾಗಿ ಅದೇ ಶ್ರೇಣಿಯಿಂದ ವಿಳಾಸಗಳನ್ನು ಹಂಚಲಿ. ಪ್ರಾಥಮಿಕ ವಿಳಾಸ 10.156.0.10/20 ಇರುವ instance ನಲ್ಲಿ, /28 alias pool ಅನ್ನು ಇತರ instance ಗಳು ಈಗಾಗಲೇ ಹೊಂದಿರುವ ವಿಳಾಸಗಳಿಂದ ಪ್ರತ್ಯೇಕಿಸುತ್ತದೆ:

gcloud compute instances network-interfaces update openvpn-vm \
  --zone=europe-west1-b \
  --aliases=eth0:10.156.1.0/28

ನಂತರ server ಸೂಚನೆ ಅದೇ block ಅನ್ನು ವಿವರಿಸಬೇಕು. ಅದರ ಮೊದಲ ವಿಳಾಸ tunnel ನ gateway ಆಗುತ್ತದೆ, ಉಳಿದ ವಿಳಾಸಗಳನ್ನು ಕ್ಲೈಂಟ್ಗಳಿಗೆ ನೀಡಲಾಗುತ್ತದೆ. ಇಲ್ಲಿ ಎರಡು ಸಂಖ್ಯೆಗಳು ಒಂದು block ಅನ್ನು ವಿವರಿಸುತ್ತವೆ, ಒಂದು network ಮತ್ತು ಒಂದು netmask, ಅದೇ OpenVPN ಇನ್ನೂ ನಿರೀಕ್ಷಿಸುವ pool ಸಿಂಟ್ಯಾಕ್ಸ್.

server 10.156.1.0 255.255.255.240

ವಿಳಾಸ ನಿಜವಾಗಿ ಇಂಟರ್ಫೇಸ್ಗೆ ಬಂದಿದೆಯೇ, OpenVPN ಕಾನ್ಫಿಗರೇಶನ್ನಲ್ಲಿ ಮಾತ್ರವಲ್ಲವೇ ಎಂದು ಖಚಿತಪಡಿಸಿ. fabric NIC ವರದಿ ಮಾಡಿದ್ದನ್ನು ಕಳುಹಿಸುತ್ತದೆ, daemon ನಂಬಿದ್ದನ್ನು ಅಲ್ಲ. ಒಂದು ಆದೇಶ ಅದನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ:

ip -4 addr show dev eth0

ಎಂದಿಗೂ eth0 ತಲುಪದ ದ್ವಿತೀಯ ವಿಳಾಸ, ಅಥವಾ ಇನ್ನೊಂದು subnet ಜೊತೆ ಅತಿವ್ಯಾಪಿಸುವ pool, ನಂತರ ಆರಂಭಿಕ ದೋಷವಾಗಿ ಅಲ್ಲದೆ ಮಧ್ಯಂತರ packet ನಷ್ಟವಾಗಿ ಕಾಣಿಸುತ್ತದೆ. daemon ಪ್ರಾರಂಭವಾಗುತ್ತದೆ, ಕ್ಲೈಂಟ್ಗಳು ಸಂಪರ್ಕಗೊಳ್ಳುತ್ತವೆ, ಕೆಲವು ಗಮ್ಯಸ್ಥಾನಗಳು ಮಾತ್ರ ತಪ್ಪಾಗಿ ವರ್ತಿಸುತ್ತವೆ. route ಕೋಷ್ಟಕದಲ್ಲಿ pool ಸುಲಭವಾಗಿ ಗುರುತಿಸಲು alias ಶ್ರೇಣಿಯನ್ನು ಚಿಕ್ಕದಾಗಿ ಇರಿಸಿ. ಇನ್ನೊಂದು instance ಈಗಾಗಲೇ ಬಳಸುತ್ತಿರುವ subnet ನಿಂದ ಅದನ್ನು ಎಂದಿಗೂ ಕತ್ತರಿಸಬೇಡಿ.

ಹಿಂತಿರುಗುವ traffic ಗೆ next hop ನೀಡಿ

VPC ಯ host ನಿಂದ ಬರುವ ಉತ್ತರ tunnel pool ನಲ್ಲಿನ ಕ್ಲೈಂಟ್ ವಿಳಾಸಕ್ಕೆ ಕಳುಹಿಸಲ್ಪಡುತ್ತದೆ, ಅದು VPC ಗೆ ತಿಳಿದ ಯಾವುದೇ subnet ಗೆ ಸೇರಿಲ್ಲ. ಆ pool ಗೆ route ಇಲ್ಲದಿದ್ದರೆ ಉತ್ತರ ಹೊಂದಿಕೆಯಿಲ್ಲದ ಮೊದಲ hop ನಲ್ಲಿ ನಿಲ್ಲುತ್ತದೆ, ಮತ್ತು ವಿನಂತಿ ಆಚೆ ತುದಿಯಲ್ಲಿ ಯಶಸ್ವಿಯಾಗಿರಬಹುದು.

gcloud compute routes create openvpn-return \
  --network=prod-vpc \
  --destination-range=192.168.127.0/24 \
  --next-hop-instance=openvpn-vm \
  --next-hop-instance-zone=europe-west1-b \
  --priority=800

ಅದೇ route VPC ಒಳಗೆ ಅಲ್ಲದೆ ಕ್ಲೈಂಟ್ನ ಹಿಂದೆ ಇರುವ ಪ್ರತಿ prefix ಗೆ ಬೇಕು. ಆ prefix ಗಳಿಗೆ ಆ ಕ್ಲೈಂಟ್ನ ccd ಫೈಲ್ನಲ್ಲಿ iroute ನಮೂದು ಕೂಡ ಬೇಕು. ಆ ನಮೂದು ಸರ್ವರ್ ಬದಿಯ ಲೆಕ್ಕ: ಯಾವ ಕ್ಲೈಂಟ್ prefix ನ ಮಾಲೀಕ ಎಂದು ಸರ್ವರ್ಗೆ ಹೇಳುತ್ತದೆ, ಕ್ಲೈಂಟ್ ಮೇಲೆಯೇ ಏನನ್ನೂ ಸ್ಥಾಪಿಸುವುದಿಲ್ಲ.

push ಪಟ್ಟಿಯನ್ನು ಸಂಭಾಷಣೆಯ ಕ್ಲೈಂಟ್ ಬದಿಗೆ ಇರಿಸಿ, ಏಕೆಂದರೆ ಅದು ಸಂಪರ್ಕಗೊಳ್ಳುವ ಯಂತ್ರಕ್ಕೆ route ಗಳನ್ನು ಮಾತ್ರ ಸೇರಿಸುತ್ತದೆ. VPC subnet ಗೆ push ಸಾಲು ಮತ್ತು pool ಕಡೆಗೆ ಹಿಂತಿರುಗುವ VPC route ಒಂದೇ ಮಾರ್ಗದ ಎರಡು ಅರ್ಧಗಳು, ಯಾವುದೇ ಅರ್ಧ ಒಂಟಿಯಾಗಿ ವಿನಂತಿಗಳನ್ನು ಸಾಗಿಸುವ ಆದರೆ ಉತ್ತರಗಳನ್ನು ಸಾಗಿಸದ tunnel ಸೃಷ್ಟಿಸುತ್ತದೆ.

Firewall, forwarding ಮತ್ತು ನಡುವಿನ hop

VPC ಯ firewall decapsulated packet ಅನ್ನು ಮೌಲ್ಯಮಾಪನ ಮಾಡುತ್ತದೆ, ಆದ್ದರಿಂದ ingress ನಿಯಮ tunnel pool ಮತ್ತು ಆ ಮಾರ್ಗದಿಂದ VM ತಲುಪುವ ಪ್ರತಿ site prefix ಅನ್ನು ಅನುಮತಿಸಬೇಕು. default-deny ನಿಲುವು ಇಲ್ಲಿ ಮೌನವಾಗಿ ವಿಫಲವಾಗುತ್ತದೆ: decapsulation ನಂತರ packet ಎಸೆಯಲ್ಪಡುತ್ತದೆ, OpenVPN ಲಾಗ್ ಆರೋಗ್ಯಕರ session ತೋರಿಸುತ್ತದೆ.

terminate ಮಾಡದೆ forward ಮಾಡುವ ಪ್ರತಿ Linux host ನಲ್ಲಿ net.ipv4.ip_forward ಆನ್ ಆಗಿದೆಯೇ ಪರಿಶೀಲಿಸಿ. ಮಾಲೀಕತ್ವದ ನಿಯಮ ಅಲ್ಲಿಯೂ ಅನ್ವಯಿಸುತ್ತದೆ: ತನಗಿಲ್ಲದ subnet ಗೆ forward ಮಾಡುವ ಯಂತ್ರ VM ನಂತೆಯೇ packet ಎಸೆಯುತ್ತದೆ. tunnel ಅನ್ನು ದೂಷಿಸುವ ಮೊದಲು ಮೌಲ್ಯ ಓದಿ.

ನಿಖರವಾಗಿ ಒಂದು prefix ವಿಫಲವಾದಾಗ

ಭಾಗಶಃ ವೈಫಲ್ಯ ಓದಲು ಸುಲಭವಾದ ಸಂದರ್ಭ, ಏಕೆಂದರೆ ಮಾರ್ಗದಲ್ಲಿ ಉಳಿದೆಲ್ಲವೂ ಈಗಾಗಲೇ ಸಾಬೀತಾಗಿದೆ. route ಪಟ್ಟಿಯಿಂದ ಪ್ರಾರಂಭಿಸಿ prefix ಅನ್ನು ಆವರಿಸಬೇಕಾದ ನಮೂದಿನ ಗಮ್ಯ ಶ್ರೇಣಿ ಮತ್ತು next hop ಓದಿ, ನಂತರ instance ವಿವರಣೆ ಓದಿ ಅದರ alias ಶ್ರೇಣಿಯನ್ನು ಸರ್ವರ್ ಹಂಚುವ pool ನೊಂದಿಗೆ ಹೋಲಿಸಿ.

gcloud compute routes list --filter=destination-range~10.164.0.0
 gcloud compute instances describe openvpn-vm --format=get(networkInterfaces[0].aliasIpRanges)

ಕಾಣೆಯಾದ route prefix ಗೆ next hop ಇಲ್ಲದಿರುವಂತೆ ಕಾಣಿಸುತ್ತದೆ, ಕಾಣೆಯಾದ alias ಇಂಟರ್ಫೇಸ್ನಲ್ಲಿ ಎಸೆದ packet ಆಗಿ ಕಾಣಿಸುತ್ತದೆ; ಕ್ಲೈಂಟ್ನಿಂದ ಎರಡೂ ಒಂದೇ ರೀತಿ ಕಾಣುತ್ತವೆ ಮತ್ತು ಆ ಎರಡು ಔಟ್ಪುಟ್ಗಳಲ್ಲಿ ಸಂಪೂರ್ಣವಾಗಿ ಭಿನ್ನ. ಎರಡೂ ಇದ್ದರೆ, ಉಳಿದ ಶಂಕಿತ prefix ಅನ್ನು ಕ್ಲೈಮ್ ಮಾಡುವ ಕ್ಲೈಂಟ್ನ ccd iroute.

ನಾಲ್ಕು ಮೌಲ್ಯಗಳನ್ನು tunnel ಪಕ್ಕದಲ್ಲಿ ಬರೆಯಿರಿ: alias ಶ್ರೇಣಿ, ಸರ್ವರ್ pool, push ಮಾಡಿದ prefix ಗಳು, VPC route ಗಳು. ಹಳೆಯ alias pool ನ ಪ್ರತಿ ವಿಳಾಸವನ್ನೂ ಮುರಿಯುತ್ತದೆ, ಹಳೆಯ route ಒಂದು ದಿಕ್ಕನ್ನು ಮುರಿಯುತ್ತದೆ, ಕಾಣೆಯಾದ push prefix ಅನ್ನು ಕ್ಲೈಂಟ್ನಿಂದ ಮರೆಮಾಡುತ್ತದೆ, ತಪ್ಪು iroute prefix ಅನ್ನು ತಪ್ಪು peer ಗೆ ಕಳುಹಿಸುತ್ತದೆ. ಮುಂದೆ subnet ಸೇರಿಸುವ ವ್ಯಕ್ತಿಗೆ ನಾಲ್ಕೂ ಒಂದೇ ಸ್ಥಳದಲ್ಲಿ ಬೇಕು, ಆ ಟಿಪ್ಪಣಿ ಸಂಜೆಗಿಂತ ಅಗ್ಗ.