kubectl OpenVPN દ્વારા ખાનગી ક્લસ્ટરનું API ઉકેલી શકતું નથી

kubectl નામ શોધમાં નિષ્ફળ જાય છે જ્યારે ટનલ ચાલુ છે અને APIનું ખાનગી સરનામું હજી pingનો જવાબ આપે છે. માર્ગ ઠીક છે; ક્લાયન્ટ એવા રિઝોલ્વરને પૂછે છે જેણે ક્લસ્ટરના ખાનગી ઝોન વિશે કદી સાંભળ્યું નથી. બે સુધારા સૌથી વધુ વપરાય છે: વર્ચ્યુઅલ નેટવર્કનું રિઝોલ્વર દરેક VPN ક્લાયન્ટને મોકલવું, અથવા નામને સ્થાનિક રીતે hosts એન્ટ્રી અથવા શરતી ફોરવર્ડર સાથે પિન કરવું. બંને એ જ લક્ષણને અલગ જવાબદારી સાથે ઉકેલે છે, અને તેમને ભેગા કરવાથી જ ટીમો દર વખતે એન્ડપોઇન્ટ ફરી બને ત્યારે hosts ફાઇલો સંપાદિત કરે છે.

ઉકેલ અને પહોંચ જુદા સ્તરે નિષ્ફળ જાય છે

કંઈપણ બદલતા પહેલા શોધ જાતે ચલાવો. Linux પર getent hosts અથવા Windows પર nslookup કહે છે કે ક્લાયન્ટને જવાબ મળે છે કે નહીં; સમય સમાપ્તિ અથવા NXDOMAIN રિઝોલ્વર તરફ ઇશારો કરે છે, જ્યારે ખોટા સરનામાનો જવાબ જૂના રેકોર્ડ અથવા જાહેર માર્ગ તરફ ઇશારો કરે છે.

પછી ખાતરી કરો કે kubectl ખરેખર કયા સર્વર સાથે જોડાય છે. kubeconfig સંદર્ભ URL સંગ્રહે છે, અને VPN માર્ગ તેને ફરી લખતો નથી: જો સંદર્ભ જાહેર એન્ડપોઇન્ટ કહે, તો DNS સંપૂર્ણ હોઈ શકે અને આદેશ તોપણ નિષ્ફળ જાય.

getent hosts api.internal.example
kubectl config view --minify -o jsonpath='{.clusters[0].cluster.server}'
kubectl -v=8 get nodes 2>&1 | head -40

ત્રીજો સંકેત શોધ પછીની નિષ્ફળતાનો આકાર છે. જે નામ ખાનગી સરનામે ઉકેલાય અને પછી TCP સમય સમાપ્તિ પામે તે ફાયરવોલ અથવા અધિકૃત નેટવર્કની સમસ્યા છે. જે નામ જાહેર સરનામે ઉકેલાય તેનો અર્થ છે કે ક્વેરી ખાનગી ઝોનમાંથી નીકળી ગઈ. આ ત્રણ પરિણામ અલગ રાખો; દરેક તમને જુદા જવાબદાર સુધી લઈ જાય છે.

વિકલ્પ A: વર્ચ્યુઅલ નેટવર્કનું રિઝોલ્વર ટનલમાં મોકલો

જ્યારે VPN સર્વર વર્ચ્યુઅલ નેટવર્કની અંદર ચાલે છે, ત્યારે ક્લાયન્ટ સર્વર હોસ્ટ જેવું જ રિઝોલ્વર વાપરી શકે છે. OpenVPN Communityમાં સર્વર DNS વિકલ્પ મોકલે છે; Access Server એ જ સેટિંગ એડમિન ઇન્ટરફેસમાં દર્શાવે છે, અને ક્લાયન્ટે પ્રોફાઇલ ફરી ડાઉનલોડ કરવી પડે છે કારણ કે DNS સૂચના તેની અંદર મુસાફરી કરે છે.

# server.conf
push "dhcp-option DNS 10.0.0.4"
push "route 10.0.0.4 255.255.255.255"

રૂટ લાઇન split tunnel પ્રોફાઇલમાં મહત્વની છે. રિઝોલ્વરનું સરનામું મોકલવું તેને પહોંચપાત્ર બનાવવા સમાન નથી: જો ટનલમાંથી ફક્ત ક્લસ્ટરનું સબનેટ પસાર થાય, તો 10.0.0.4ની ક્વેરી સ્થાનિક LAN દ્વારા નીકળીને મરી જાય છે. રિઝોલ્વર માટે હોસ્ટ રૂટ મોકલો, અથવા તેનું સબનેટ ટનલમાં સમાવો.

સ્વીકારનાર પક્ષની પણ નીતિ હોય છે. ક્લાયન્ટના સરનામા શ્રેણીમાંથી પહોંચપાત્ર રિઝોલ્વર ત્યાંથી આવતી ક્વેરી તોપણ નકારી શકે છે, અને વર્ચ્યુઅલ નેટવર્ક સાથે જોડાયેલ ખાનગી ઝોન ફક્ત તે ક્લાયન્ટને જવાબ આપે છે જે તે નેટવર્કના DNS માર્ગે આવે છે. જો મોકલ્યા પછી શોધ સમય સમાપ્ત થાય, તો ક્લાયન્ટને ફરી સ્પર્શ કરતા પહેલા રિઝોલ્વરની પોતાની લોગ જુઓ.

ક્લાયન્ટ પર ચકાસો કે શું લાગુ થયું: systemd-resolved Linux પર resolvectl status, macOS પર scutil --dns, Windows પર ipconfig /all. મોકલાયેલ DNS સર્વર જે ક્યારેય દેખાય નહીં તેનો અર્થ છે કે પ્રોફાઇલ ફરી લોડ થઈ નથી.

વિકલ્પ B: hosts એન્ટ્રીઓ અને શરતી ફોરવર્ડિંગ

hosts એન્ટ્રી સૌથી નાનો શક્ય સુધારો અને સૌથી નાજુક છે. તે એક નામને એક મશીન પર એક સરનામા સાથે જોડે છે, તેથી ડેમો માટે કામ કરે છે અને ખાનગી એન્ડપોઇન્ટ અથવા તેનું IP ફરી બને ત્યારે તૂટે છે. તે વાસ્તવિક અંતરને બાકીની ટીમથી છુપાવે પણ છે.

શરતી ફોરવર્ડર દરેક ક્લાયન્ટને DNS મોકલ્યા વિના વધુ સારી રીતે સ્કેલ થાય છે. dnsmasq એક ઝોન VNet રિઝોલ્વરને મોકલી શકે છે અને બાકીનું બધું શાંત રાખી શકે છે: server=/cluster.internal/10.0.0.4. Windows DNSમાં શરતી ફોરવર્ડર છે, અને Windows ક્લાયન્ટ એ જ વિભાજન માટે NRPT નિયમ વાપરી શકે છે. ફોરવર્ડરને હજી પણ VNet રિઝોલ્વર સુધી રૂટ જોઈએ.

ફોરવર્ડિંગ સામાન્ય બ્રાઉઝિંગને સ્થાનિક રાખે છે, જે split tunnelમાં મહત્વનું છે. તે તમને ખાનગી ઝોનની ક્વેરી લોગ કરવા એક જગ્યા અને ફોરવર્ડર હોસ્ટ ખસે ત્યારે તૂટતી એક જગ્યા આપે છે.

જવાબદારી પ્રમાણે પસંદ કરો, સુવિધા પ્રમાણે નહીં

રિઝોલ્વર ત્યારે મોકલો જ્યારે તમે VPN પ્રોફાઇલ નિયંત્રિત કરો છો અને ઇચ્છો છો કે દરેક ખાનગી નામ કામ કરે, ફક્ત API નહીં. ફોરવર્ડર ત્યારે પસંદ કરો જ્યારે ક્લાયન્ટે બાકીનું બધું માટે પોતાનું સ્થાનિક DNS રાખવું પડે, અથવા જ્યારે VPN ક્લસ્ટરથી અલગ ટીમ સંભાળે.

hosts એન્ટ્રીઓ નિદાન છે, જમાવટ નહીં. એક વાપરો એ સાબિત કરવા કે API પહોંચપાત્ર છે, પછી તેને દૂર કરો અને રિઝોલ્વરનો માર્ગ સુધારો; તેને રહેવા દેવું પછી રૂટિંગના પ્રશ્નને ખજાનાની શોધમાં ફેરવે છે. કયો વિકલ્પ પસંદ કરો, ઝોન, રિઝોલ્વરનું સરનામું અને ક્વેરી વહન કરતો માર્ગ લખી રાખો.

API એન્ડપોઇન્ટ ચકાસો, ફક્ત નામ નહીં

શોધ સફળ થાય પછી, ક્લસ્ટર CA સાથે APIનું આવૃત્તિ એન્ડપોઇન્ટ મેળવો. curl --cacert ca.crt https://api.internal.example:6443/version TLS અને અધિકૃતિની નિષ્ફળતાઓને DNSથી અલગ કરે છે. 403નો અર્થ છે કે નામ અને જોડાણ કામ કરે છે અને ઓળખ નહીં.

એ પણ ચકાસો કે ક્લાયન્ટની સરનામા શ્રેણી ક્લસ્ટરના અધિકૃત નેટવર્ક અથવા ફાયરવોલ દ્વારા મંજૂર છે કે નહીં. ખાનગી ક્લસ્ટર ઘણી વાર API ટ્રાફિક ફક્ત VNet અથવા peered શ્રેણીઓમાંથી સ્વીકારે છે, તેથી બીજા પૂલમાંથી સરનામાં આપતી ટનલ નેટવર્ક સ્તરે જોડાય છે અને API પર છોડી દેવાય છે.

એસ્કેલેટ કરતી વખતે ચાર તથ્યો લખો: ક્લાયન્ટે વાપરેલું રિઝોલ્વર, તેણે પરત કરેલું સરનામું, પસંદ કરેલા kubeconfig સંદર્ભમાં સર્વર URL, અને પ્રથમ નિષ્ફળ થયેલી ક્રિયા. તે રેકોર્ડ આગલા એન્જિનિયરને કહે છે કે DNS, રૂટિંગ કે ફાયરવોલ નીતિ બદલવી છે કે નહીં, અને આગલું hosts ફાઇલ સંપાદન અટકાવે છે.

શોધથી શરૂ કરો, ઝોનના માલિક સાથે મેળ ખાતો રિઝોલ્વર માર્ગ પસંદ કરો, પછી એન્ડપોઇન્ટ ચકાસો. જો ત્રણેય પાસ થાય, તો બાકી સમસ્યા અધિકૃતિ છે, નામ ઉકેલ નહીં.