AWS Client VPN કનેક્ટ થયેલ છે પણ ઇન્ટરનેટ નથી: રૂટ તપાસ

AWS Client VPN કનેક્ટ થયેલ છે પણ ઇન્ટરનેટ ઍક્સેસ નથી? ક્લાયન્ટ રૂટ, એન્ડપોઇન્ટ ઓથોરાઇઝેશન, સબનેટ એગ્રેસ અને DNS આ ક્રમમાં તપાસો.

તમે AWS Client VPN એન્ડપોઇન્ટ સાથે કનેક્ટ છો, ખાનગી સબનેટ જવાબ આપે છે, અને તેમ છતાં દરેક જાહેર પૃષ્ઠ સમયસીમા પર પૂરું થાય છે. આ સંયોજન સમસ્યાને મેનેજ્ડ બાજુની ત્રણ ઑબ્જેક્ટમાંથી એક સુધી સંકુચિત કરે છે: ક્લાયન્ટ જે રૂટ ઇન્સ્ટોલ કરે છે, એન્ડપોઇન્ટનો રૂટ તેના ઓથોરાઇઝેશન નિયમ સાથે, અથવા સંકળાયેલ સબનેટની આગળની હોપ. હું તેમને એ જ ક્રમમાં તપાસું છું, કારણ કે દરેક નિષ્ફળતા ક્લાયન્ટની બાજુથી અલગ દેખાય છે. આ માર્ગદર્શિકા VPC સાથે સંકળાયેલ મેનેજ્ડ એન્ડપોઇન્ટ આવરે છે, EC2 ઇન્સ્ટન્સ પરના OpenVPN સર્વરને નહીં અને Cloud WAN કે Transit Gateway જોડાણને નહીં.

ક્લાયન્ટ ખરેખર શું રૂટ કરે છે તેનાથી શરૂ કરો

કનેક્ટ થયેલ સ્થિતિ TLS સેશન અને ક્લાયન્ટને CIDR ફાળવણી સાબિત કરે છે, વધુ કંઈ નહીં. ટનલ ચાલુ હોય ત્યારે જાહેર સરનામું ક્યાં જશે તે ઓપરેટિંગ સિસ્ટમને પૂછો. Linux પર ip route get 1.1.1.1 ટનલ ઇન્ટરફેસનું નામ આપવું જોઈએ; macOS પર netstat -rn -f inet | head -5 ડિફૉલ્ટ એન્ટ્રી બતાવે છે; Windows પર Find-NetRoute -RemoteIPAddress 1.1.1.1 પસંદ કરેલ ઇન્ટરફેસ અને આગળની હોપ છાપે છે.

પછી સ્પ્લિટ-ટનલ ફ્લેગ વાંચો, કારણ કે તે નક્કી કરે છે કે એન્ડપોઇન્ટના પ્રકાશિત રૂટ એ જ એકમાત્ર ગંતવ્યો છે જે ક્લાયન્ટ ટનલમાં મોકલે છે:

aws ec2 describe-client-vpn-endpoints \
  --client-vpn-endpoint-ids cvpn-endpoint-0123456789abcdef0 \
  --query 'ClientVpnEndpoints[0].SplitTunnel'

જ્યારે SplitTunnel સાચું હોય, ત્યારે જાહેર ગંતવ્ય ટનલનો ઉપયોગ ફક્ત ત્યારે જ કરે છે જ્યારે એન્ડપોઇન્ટ તેને આવરતો રૂટ પ્રકાશિત કરે, તેથી ગેરહાજર 0.0.0.0/0 તે ટ્રાફિકને સ્થાનિક ઇન્ટરફેસ પર છોડી દે છે. જો તે ખોટું હોય, તો ક્લાયન્ટ ટ્રાફિક પકડે છે, પણ એન્ડપોઇન્ટે તેને હજી રૂટ અને ઓથોરાઇઝ કરવું પડે; નહીં તો પેકેટ ટનલમાં પ્રવેશે અને ત્યાં જ અટકે. બંનેમાંથી કોઈપણ સેટિંગ બદલ્યા પછી ક્લાયન્ટને ફરી કનેક્ટ કરો, કારણ કે રૂટ અને DNS સર્વર કનેક્શન સમયે જ આપવામાં આવે છે અને ચાલુ ક્લાયન્ટ તેનો જૂનો સેટ રાખી શકે છે.

એન્ડપોઇન્ટ રૂટ અને ઓથોરાઇઝેશન નિયમ અલગથી વાંચો

આ બે ઑબ્જેક્ટ છે, અને એક બનાવવાથી બીજું બનતું નથી. એન્ડપોઇન્ટ રૂટની યાદી બનાવો અને એવો ડિફૉલ્ટ રૂટ શોધો જેનું લક્ષ્ય સંકળાયેલ સબનેટ છે:

aws ec2 describe-client-vpn-routes \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0

દરેક રૂટમાં લક્ષ્ય સબનેટ બરાબર એક જ હોય છે, તેથી ત્રણ સંકળાયેલતાઓને દરેક માટે અનુરૂપ ડિફૉલ્ટ રૂટની જરૂર પડે છે. AWS આ આવરણ જરૂરિયાતનું દસ્તાવેજીકરણ કરે છે, અને ખાલીપાના વ્યવહારુ લક્ષણ એ છે કે વપરાશકર્તા એક સબનેટથી કામ કરે છે અને બીજા સબનેટથી અટકી જાય છે, જે ખૂટતા રૂટને બદલે અવારનવાર આવતી ખામી તરીકે વંચાય છે. અધિકૃત Client VPN પરિદૃશ્ય દસ્તાવેજીકરણ આ રૂટ જે જાહેર-સબનેટ ગોઠવણીના છે તેનું વર્ણન કરે છે.

ઓથોરાઇઝેશન બીજું ઑબ્જેક્ટ છે. જ્યારે કોઈ નિયમ જાહેર ગંતવ્યને આવરતો નથી, ટનલ પેકેટ વહન કરે છે અને સેવા તેને કાઢી નાખે છે, તેથી ખાનગી સંસાધનો કામ કરતાં રહે છે જ્યારે ઇન્ટરનેટ કરતું નથી:

aws ec2 describe-client-vpn-authorization-rules \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0

VPC CIDR માટેનો નિયમ 0.0.0.0/0 વિશે કંઈ કહેતો નથી. સંપૂર્ણ ટનલ માટે ખૂટતા ટુકડા ઉમેરવાનો અર્થ છે દરેક સંકળાયેલ સબનેટ માટે એક રૂટ અને પછીથી ઓડિટ કરી શકાય એવો ઓથોરાઇઝેશન નિયમ:

aws ec2 create-client-vpn-route \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0 \
  --destination-cidr-block 0.0.0.0/0 \
  --target-vpc-subnet-id subnet-0a1b2c3d4e5f67890
aws ec2 create-client-vpn-authorization-rule \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0 \
  --destination-cidr-block 0.0.0.0/0 \
  --access-all \
  --description "internet egress for full tunnel"

--access-all એન્ડપોઇન્ટના દરેક ક્લાયન્ટને ગંતવ્ય આપે છે, તેથી તેને ફક્ત ત્યાં સુધી રાખો જ્યાં સુધી ટનલ સંપૂર્ણ હોવાનું છે; જ્યારે બાંધવા માટે ગ્રુપ હોય ત્યારે ડિરેક્ટરી ગ્રુપ સાથે બાંધેલો નિયમ વધુ સારો છે.

પેકેટને સંકળાયેલ સબનેટની બહાર અનુસરો

એન્ડપોઇન્ટ રૂટ નક્કી કરે છે કે AWS પેકેટ તે સબનેટને આપે છે. તે તેની પછીની હોપ નક્કી કરતો નથી, જે સબનેટના પોતાના VPC રૂટ કોષ્ટકમાં રહે છે:

aws ec2 describe-route-tables \
  --filters Name=association.subnet-id,Values=subnet-0a1b2c3d4e5f67890 \
  --query 'RouteTables[].Routes[?DestinationCidrBlock==`0.0.0.0/0`]'

વાપરી શકાય એવો ડિફૉલ્ટ રૂટ જાહેર સબનેટ માટે ઇન્ટરનેટ ગેટવે તરફ અથવા ખાનગી માટે NAT ગેટવે તરફ નિર્દેશ કરે છે, અને સ્થિતિ blackhole નો અર્થ છે કે લક્ષ્ય ડિલીટ થઈ ગયું છે અને માર્ગ હવે શાંતિથી મરી રહ્યો છે. આ એન્ડપોઇન્ટની રૂટ યાદીથી અલગ કોષ્ટકો છે, અને એક સુધારવાથી બીજું સુધરતું નથી.

આ હોપ પર બે ફિલ્ટર બેઠા છે. લક્ષ્ય નેટવર્ક સંકળાયેલતા પર લાગુ કરેલ સિક્યોરિટી ગ્રુપે જાહેર ગંતવ્ય તરફ આઉટબાઉન્ડ ટ્રાફિકને મંજૂરી આપવી જોઈએ, અને લાગુ પડતા કોઈપણ નેટવર્ક ACLએ વિનંતી અને અલ્પજીવી પોર્ટ પરના પરત ટ્રાફિકને મંજૂરી આપવી જોઈએ. પ્રતિબંધક સંકળાયેલતા સિક્યોરિટી ગ્રુપ એ સામાન્ય કારણ છે કે ખાનગી ઍક્સેસ કામ કરે છે અને જાહેર ઍક્સેસ નહીં.

ત્રણેયને એકસાથે બદલવાને બદલે લક્ષણ પરથી પ્રથમ સ્તર પસંદ કરો:

What you observeLayer to check first
No tunnel interface for a public IPClient route or split-tunnel flag
Tunnel interface chosen, request times outEndpoint route and authorization rule
Endpoint route present, still times outSubnet route table, association security group
Named host fails, numeric address worksDNS servers and their own authorization

DNS નિષ્ફળતાને મૃત રૂટથી અલગ કરો

નામ ઉકેલાવવું ફોરવર્ડિંગથી અલગ રીતે નિષ્ફળ જાય છે, અને સંપૂર્ણ ટનલ આ તફાવતને મહત્ત્વનો બનાવે છે કારણ કે દબાણ કરેલ રિઝોલ્વર હવે ટનલ દ્વારા પહોંચે છે. જો એન્ડપોઇન્ટ VPC DNS સર્વર નિર્દિષ્ટ કરે, તો તેમના સરનામાંને અન્ય કોઈપણ ગંતવ્યની જેમ રૂટ આવરણ અને ઓથોરાઇઝેશનની જરૂર છે. તમને કઈ નિષ્ફળતા છે તે જોવા માટે રિઝોલ્વરને સીધું પૂછો: dig +short example.com @10.0.0.2, અથવા nslookup example.com 10.0.0.2 Windows પર.

જ્યારે સંખ્યાત્મક URL જવાબ આપે અને નામવાળું ન આપે, ત્યારે ડિફૉલ્ટ રૂટ સંપાદિત કરવાનું બંધ કરો અને DNS પર કામ કરો. IP સરનામાં પરની વિનંતી નામવાળા વર્ચ્યુઅલ હોસ્ટ અને તેના પ્રમાણપત્ર વિશે કંઈ સાબિત કરતી નથી, તેથી અંતિમ તપાસમાં એક નામવાળી કસોટી રાખો.

સમય મદદ કરે છે. થોડી સેકન્ડમાં જવાબ ન મળતું TCP જોડાણ રૂટિંગ અથવા ફિલ્ટર તરફ સંકેત કરે છે, જ્યારે નામ શોધમાં અટકી પડેલી વિનંતી રિઝોલ્વર તરફ સંકેત કરે છે. રિઝોલ્વર પહોંચની બહાર હોય ત્યારે ડિફૉલ્ટ રૂટ બદલવાથી સામાન્ય રીતે એક નિષ્ફળતા બે થઈ જાય છે.

સ્વચ્છ રીતે પાછું ખેંચો, પછી એગ્રેસ માર્ગ ચકાસો

બંને ઑબ્જેક્ટ ઉમેરાત્મક હતા, તેથી પાછું ખેંચવું એ સમારકામ નહીં પણ ડિલીટ છે:

aws ec2 delete-client-vpn-route \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0 \
  --destination-cidr-block 0.0.0.0/0 \
  --target-vpc-subnet-id subnet-0a1b2c3d4e5f67890
aws ec2 delete-client-vpn-authorization-rule \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0 \
  --destination-cidr-block 0.0.0.0/0 \
  --access-all

ફરી કનેક્ટ કરો અને ખાતરી કરો કે ટ્રાફિક કયા માર્ગે નીકળે છે. જોયેલા જાહેર સરનામાને NAT ગેટવેના ઇલાસ્ટિક IP સરનામા સાથે અથવા તમે વાપરવા માંગતા હતા તે ઇન્ટરનેટ ગેટવે સાથે સરખાવો, અને ચકાસો કે ખાનગી સંસાધન હજી એ જ સત્રમાં જવાબ આપે છે.

ટૂંકી યાદી સાથે પૂરું કરો અને છેલ્લી વસ્તુને દસ્તાવેજીકરણ નહીં પણ ફેરફારનો ભાગ ગણો:

  • દરેક સંકળાયેલ સબનેટ માટે એક 0.0.0.0/0 એન્ડપોઇન્ટ રૂટ.
  • તમે જેમને સેવા આપવા માંગો છો તે ક્લાયન્ટ માટે 0.0.0.0/0 આવરતો ઓથોરાઇઝેશન નિયમ.
  • દરેક સંકળાયેલ સબનેટ પર blackhole ન હોય એવો VPC ડિફૉલ્ટ રૂટ.
  • સંકળાયેલતા સિક્યોરિટી ગ્રુપનું આઉટબાઉન્ડ, ઉપરાંત ACL પરત ટ્રાફિક.
  • રિઝોલ્વર સરનામાં રૂટ અને ઓથોરાઇઝ થયેલ, નામવાળી વિનંતીથી ચકાસાયેલ.
  • રૂટ અને નિયમ માટે નોંધાયેલ રોલબેક.

એક વ્યાપ્તિ નોંધ: આ IPv4 માર્ગ છે. ડ્યુઅલ-સ્ટેક ક્લાયન્ટ પાસે પહેલેથી જે IPv6 કનેક્ટિવિટી છે તે રાખે છે, તેથી IPv6 ડિફૉલ્ટ રૂટ તેની પોતાની ઓથોરાઇઝેશન સાથેનો અલગ નિર્ણય છે, આની આડઅસર નહીં.

સંબંધિત લેખો