GCE પર OpenVPN: રૂટ push કરતા પહેલા alias IP ઉમેરો

push કરેલો રૂટ VMને next hop બનાવતો નથી. alias IP શ્રેણી ઉમેરો, તેને સર્વરના pool સાથે મેળવો અને ક્લાયન્ટ ચકાસતા પહેલા VPCમાં પરત રૂટ બનાવો.

ક્લાયન્ટ Compute Engine VM પરના OpenVPN સર્વર પર ડાયલ કરે છે, સ્ટેટસ વિન્ડો કહે છે જોડાયેલું, અને VPCની અંદરના હોસ્ટ પરનું ping હજી ક્યાંય પહોંચતું નથી. સ્વાભાવિક વૃત્તિ કહે છે બીજી push લાઇન ઉમેરો, અને તે ક્યારેય સુધારતું નથી. Compute Engine પોતાના રૂટ ટેબલ અને VMના ઇન્ટરફેસ ખરેખર ધરાવતા સરનામાંઓના આધારે પેકેટ ક્યાં જશે તે નક્કી કરે છે, તેથી જે tunnel pool VMની માલિકીનું નથી તે એવું pool છે જ્યાં કોઈ પહોંચાડતું નથી.

કન્ફિગરેશન ફાઇલને બદલે નિષ્ફળ થતા પેકેટને અનુસરો, અને ખૂટતા ભાગો ક્રમમાં દેખાશે.

મૃત પેકેટથી શરૂ કરો

SYN ક્લાયન્ટ છોડે છે, tunnelમાં પ્રવેશે છે અને VPCની અંદરના લક્ષ્ય માટે encapsulated પેકેટ તરીકે VM સુધી પહોંચે છે. OpenVPN તેને decapsulate કરે છે અને eth0 દ્વારા મોકલવાનો પ્રયાસ કરે છે, જ્યાં fabric બાકી બધા પહેલા એક પ્રશ્ન પૂછે છે: શું આ ઇન્સ્ટન્સ લક્ષ્ય સરનામાનું માલિક છે. બીજા કોઈના subnetમાંથી કાપેલું tunnel pool તે પ્રશ્નમાં નિષ્ફળ જાય છે, અને કોઈપણ રૂટ કે firewall નિયમ જોવાતા પહેલા પેકેટ ફેંકી દેવાય છે.

તેથી ક્લાયન્ટથી VPC તરફની દિશામાં બે અલગ જરૂરિયાતો છે, અને એક પણ push સૂચના નથી. VMને tunnel pool આવરી લેતી alias શ્રેણીની જરૂર છે, અને તે જ તેને તે સરનામાંઓનો કાયદેસર માલિક બનાવે છે. VPCને એવા રૂટની જરૂર છે જે દરેક સુરક્ષિત prefix માટે VMને next hop તરીકે નામ આપે. એક પણ ખૂટે તો પેકેટ બીજે મરે છે, જ્યારે ક્લાયન્ટને એ જ શાંતિ દેખાય છે.

નિષ્ફળતા એ જ ક્રમમાં વાંચો, કારણ કે ક્લાયન્ટની બાજુથી બંને શરતો એકસરખી દેખાય છે. જે tunnel જોડાયેલું કહે છે જ્યારે કંઈ જ જવાબ આપતું નથી તે ટોપોલોજી સમસ્યાની નિશાની છે, ખરાબ cipherની નહીં.

શું ઇન્સ્ટન્સ tunnel poolનું માલિક છે

VMને તેના પોતાના subnetની અંદર ગૌણ શ્રેણી આપો, પછી OpenVPN બરાબર તે જ શ્રેણીમાંથી સરનામાં વહેંચે. જે ઇન્સ્ટન્સનું પ્રાથમિક સરનામું 10.156.0.10/20 છે, ત્યાં /28 alias poolને બીજા ઇન્સ્ટન્સ પાસે પહેલેથી રહેલા સરનામાંઓથી અલગ રાખે છે:

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

પછી server સૂચનાએ એ જ બ્લોક વર્ણવવો પડે. તેનું પહેલું સરનામું tunnelનું gateway બને છે, અને બાકીનાં સરનામાં ક્લાયન્ટને આપવામાં આવે છે. અહીં બે સંખ્યા એક બ્લોક વર્ણવે છે, એક નેટવર્ક અને એક netmask, અને આ જ તે pool સિન્ટેક્સ છે જે OpenVPN હજી અપેક્ષા રાખે છે.

server 10.156.1.0 255.255.255.240

ખાતરી કરો કે સરનામું ખરેખર ઇન્ટરફેસ પર પહોંચ્યું છે, ફક્ત OpenVPN કન્ફિગરેશનમાં નહીં. fabric જે NIC રિપોર્ટ કરે છે તે મોકલે છે, daemon જે માને છે તે નહીં. એક આદેશ જ તે નક્કી કરે છે:

ip -4 addr show dev eth0

એવું ગૌણ સરનામું જે ક્યારેય eth0 સુધી પહોંચતું નથી, અથવા બીજા subnet સાથે ઓવરલેપ થતું pool, પછીથી શરૂઆતની ભૂલ તરીકે નહીં પણ વિરામયુક્ત પેકેટ ખોટ તરીકે દેખાય છે. daemon શરૂ થાય છે, ક્લાયન્ટ જોડાય છે, અને ફક્ત કેટલાક લક્ષ્યો ખોટું વર્તન કરે છે. alias શ્રેણી નાની રાખો જેથી રૂટ ટેબલમાં pool સરળતાથી ઓળખાય. બીજું ઇન્સ્ટન્સ પહેલેથી વાપરતું subnet તેમાંથી તેને ક્યારેય ન કાપો.

પરત ટ્રાફિકને next hop આપો

VPCના હોસ્ટ તરફથી જવાબ tunnel poolમાંના ક્લાયન્ટ સરનામાંને મોકલાય છે, જે VPC જાણતું કોઈપણ subnetનું નથી. તે pool માટે રૂટ ન હોય તો જવાબ પહેલા એવા 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

એ જ રૂટ દરેક એવા prefix માટે જરૂરી છે જે VPCની અંદર નહીં પણ ક્લાયન્ટની પાછળ હોય. તે prefixને તે ક્લાયન્ટની ccd ફાઇલમાં iroute એન્ટ્રી પણ જોઈએ. તે એન્ટ્રી સર્વર બાજુની હિસાબી છે: તે સર્વરને કહે છે કયો ક્લાયન્ટ prefixનો માલિક છે, અને ક્લાયન્ટ પર જ કંઈ સ્થાપિત કરતી નથી.

push યાદી વાતચીતની ક્લાયન્ટ બાજુ માટે રાખો, કારણ કે તે ફક્ત જોડાતી મશીન પર રૂટ ઉમેરે છે. VPC subnet માટેની push લાઇન અને pool તરફ પરત VPC રૂટ એક જ માર્ગના બે અડધા છે, અને કોઈપણ એક અડધો એકલો એવું tunnel બનાવે છે જે વિનંતી લઈ જાય પણ જવાબ નહીં.

Firewall, forwarding અને વચ્ચેના hop

VPCનું firewall decapsulated પેકેટનું મૂલ્યાંકન કરે છે, તેથી ingress નિયમે tunnel pool અને તે માર્ગે VM સુધી પહોંચતા કોઈપણ site prefixને મંજૂરી આપવી જોઈએ. default-deny વલણ અહીં શાંતિથી નિષ્ફળ જાય છે: decapsulation પછી પેકેટ ફેંકાય છે, અને OpenVPN લોગ સ્વસ્થ સત્ર દર્શાવે છે.

જે પણ Linux હોસ્ટ terminate કરવાને બદલે forward કરે છે ત્યાં net.ipv4.ip_forward ચાલુ છે કે નહીં તે તપાસો. માલિકીનો નિયમ ત્યાં પણ લાગુ પડે છે: જે મશીન પોતાની પાસે ન હોય તેવા subnet માટે forward કરે છે તે VMની જેમ પેકેટ ફેંકી દે છે. tunnelને દોષ આપતા પહેલા મૂલ્ય વાંચો.

જ્યારે બરાબર એક prefix નિષ્ફળ જાય

આંશિક નિષ્ફળતા વાંચવા માટે સૌથી સરળ કિસ્સો છે, કારણ કે માર્ગ પરનું બાકીનું બધું પહેલેથી સાબિત થઈ ગયું છે. રૂટ યાદીથી શરૂ કરો અને જે એન્ટ્રીએ prefix આવરી લેવો જોઈએ તેની લક્ષ્ય શ્રેણી અને next hop વાંચો, પછી ઇન્સ્ટન્સનું વર્ણન વાંચીને તેની alias શ્રેણી સર્વર વહેંચતા pool સાથે સરખાવો.

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

ખૂટતો રૂટ prefix માટે next hop ન હોવા તરીકે દેખાય છે, જ્યારે ખૂટતું alias ઇન્ટરફેસ પર ફેંકાયેલા પેકેટ તરીકે; ક્લાયન્ટથી બંને સરખા દેખાય છે અને તે બે આઉટપુટમાં સાવ અલગ છે. બંને હાજર હોય તો બાકીનો શંકાસ્પદ તે ક્લાયન્ટનું ccd iroute છે જે prefixનો દાવો કરે છે.

ચાર મૂલ્યો tunnelની બાજુમાં લખો: alias શ્રેણી, સર્વરનું pool, push કરેલા prefix, VPC રૂટ. જૂનું alias poolના દરેક સરનામાને તોડે છે, જૂનો રૂટ એક દિશા તોડે છે, ખૂટતું push ક્લાયન્ટથી prefix છુપાવે છે, અને ખોટું iroute prefixને ખોટા peer પર મોકલે છે. આગળ જે subnet ઉમેરશે તેને ચારેય એક જગ્યાએ જોઈએ, અને તે નોંધ સાંજ કરતાં સસ્તી છે.

સંબંધિત લેખો