GCE లో OpenVPN: routes push చేయడానికి ముందు alias IP జోడించండి

push చేసిన route VM ను next hop గా చేయదు. alias IP పరిధిని జోడించండి, దానిని సర్వర్ pool తో సరిపోల్చండి మరియు క్లయింట్లను పరీక్షించే ముందు VPC లో తిరిగి వెళ్లే route ను సృష్టించండి.

ఒక క్లయింట్ 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 జోడించే వ్యక్తికి నాలుగూ ఒకే చోట కావాలి, ఆ నోట్ సాయంత్రం కంటే చవక.

సంబంధిత వ్యాసాలు