SoftEther SecureNAT: DHCP અને NAT બે અલગ નિર્ણયો છે

SecureNAT એ એક ચેકબોક્સ છે જે બે સેવાઓ ચાલુ કરે છે, અને તેના વિશેની મોટાભાગની ગૂંચવણ ત્યાંથી જ આવે છે. વર્ચ્યુઅલ DHCP સર્વર ક્લાયંટને સરનામું, માસ્ક, ગેટવે અને ઘણી વાર રિઝોલ્વર આપે છે. વર્ચ્યુઅલ NAT સર્વર હોસ્ટની પોતાની નેટવર્ક સ્ટેક વાપરીને તે ગેટવેની પાર પેકેટ મોકલે છે. કન્ફિગરેશનમાં બંને સાથે બાજુમાં બેસે છે અને સ્વતંત્ર રીતે નિષ્ફળ થાય છે: ક્લાયંટ પાસે સંપૂર્ણ લીઝ હોય અને કોઈ કાર્યકારી માર્ગ ન હોય, અથવા કાર્યકારી માર્ગ હોય પણ સેટિંગ્સ ખોટા રિઝોલ્વર તરફ ઈશારો કરે. તેમને બે નિર્ણયો તરીકે ચકાસો, અને નિદાન ટૂંકું થઈ જાય છે.

એક ચેકબોક્સ પાછળ બે સેવાઓ

વર્ચ્યુઅલ DHCP બાજુ કન્ફિગરેશન પ્રશ્નનો જવાબ આપે છે: આ ક્લાયંટ આ વર્ચ્યુઅલ હબની અંદર કઈ સેટિંગ્સ મેળવે છે. વર્ચ્યુઅલ NAT બાજુ ફોરવર્ડિંગ પ્રશ્નનો જવાબ આપે છે: ક્લાયંટ હબની બહારના સરનામે પેકેટ મોકલે ત્યારે સર્વર તેનું ભાષાંતર કરીને મોકલે છે કે નહીં. પહેલું હબ માટે સ્થાનિક છે અને તેને ઉપરનું નેટવર્ક જરૂરી નથી. બીજું સંપૂર્ણપણે હોસ્ટ પર આધાર રાખે છે.

વર્ચ્યુઅલ હોસ્ટ ઇન્ટરફેસ પહેલા નિર્ણયનો ભાગ છે, બીજાનો નહીં. તેનું સરનામું, ઘણી વાર ડિફોલ્ટ રૂપે 192.168.30.1 જેવું કંઈક, એ DHCP સેવા જે ગેટવે આપે છે તે જ છે. આ સર્વરનું જાહેર સાંભળવાનું સરનામું નથી, અને બંનેને ભેળવી દેવાથી એવી મશીન તરફ ફાયરવોલ નિયમો અને ક્લાયંટ સેટિંગ્સ બને છે જે તે નેટવર્કમાં અસ્તિત્વમાં નથી.

નિર્ણય 1: સરનામું કોણ આપે છે

જો વર્ચ્યુઅલ DHCP ચાલુ હોય, તો ક્લાયંટને તમે કન્ફિગર કરેલા પૂલમાં લીઝ મળવી જોઈએ, ગેટવે તરીકે વર્ચ્યુઅલ હોસ્ટ ઇન્ટરફેસ અને રિઝોલ્વર તરીકે તમે આપેલું. ક્લાયંટનું સ્ટેટસ લખાણ નહીં, લીઝ તપાસો, કારણ કે «કનેક્ટેડ» ટનલ વર્ણવે છે, સરનામાની ફાળવણી નહીં:

vpncmd localhost /SERVER /CMD SecureNatStatusGet
vpncmd localhost /SERVER /CMD DhcpGet
ip -4 addr show
ip route

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

ઓવરલેપ થતા પૂલ પણ અહીં આવે છે. જો વર્ચ્યુઅલ DHCP પૂલ હોસ્ટના LAN સબનેટ અથવા બીજા હબના પૂલ સાથે ઓવરલેપ થાય, તો ક્લાયંટને એવું સરનામું મળે છે જે અસ્પષ્ટ રીતે રૂટ થાય છે, અને પછીની દરેક કસોટી અનિર્ણાયક બની જાય છે.

નિર્ણય 2: વર્ચ્યુઅલ ગેટવેની પાર કોણ મોકલે છે

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

બીજો નિર્ણય એવી વસ્તુથી ચકાસો જેને હબ છોડવું જ પડે, હબની અંદરની કોઈ વસ્તુથી નહીં. વર્ચ્યુઅલ ગેટવેને પિંગ કરવું ફક્ત પહેલી કડી સાબિત કરે છે, તેથી વધુ કંઈ નહીં:

vpncmd localhost /SERVER /CMD NatGet
vpncmd localhost /SERVER /CMD NatTable
dig +short example.com
ip route get 203.0.113.10

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

SecureNATનું ફોરવર્ડિંગ સર્વર પ્રોસેસ અમલમાં મૂકે છે, તમે બ્રિજ સાથે વાપરતા કર્નલ ફોરવર્ડિંગ માર્ગ દ્વારા નહીં. તે અનુકૂળ છે અને બ્રિજિંગ કરતાં ધીમું છે, અને તેનો અર્થ એ પણ છે કે હોસ્ટના પોતાના ફાયરવોલ નિયમો અને રૂટિંગ નિર્ણયો ભાષાંતરિત ટ્રાફિક પર હજુ પણ લાગુ પડે છે. વર્ચ્યુઅલ NAT હોસ્ટની નીતિને ટાળતું નથી; તે તેનો ઉપયોગ કરે છે.

હોસ્ટનો પોતાનો માર્ગ ત્રીજી વસ્તુ છે

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

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

સરનામા કુટુંબોને પોતાની ચકાસણી જોઈએ. કાર્યકારી IPv4 DHCP ઉદાહરણ સાબિત કરતું નથી કે તમારા બિલ્ડમાં દરેક IPv6 ક્ષમતા છે, તેથી ડ્યુઅલ સ્ટેક વર્તનનું વચન આપતા પહેલાં તમે ખરેખર ચલાવો છો તે આવૃત્તિનું મેન્યુઅલ વાંચો. મેન્યુઅલનો SecureNAT વિભાગ વર્તમાન પ્રકાશન માટે વર્ચ્યુઅલ NAT અને DHCP કાર્યો આવરી લે છે.

દરેક નિર્ણય પોતાની કસોટીથી ચકાસો

પહેલો નિર્ણય લીઝ ચકાસણીથી સ્વીકારો: પૂલમાં સરનામું, ગેટવે વર્ચ્યુઅલ હોસ્ટ ઇન્ટરફેસ જેટલું, રિઝોલ્વર તમે કન્ફિગર કરેલું. બીજો ક્લાયંટ તરફથી બહાર જતી વિનંતી અને સર્વર પરની NAT ટેબલ પર એક નજર સાથે સ્વીકારો, કારણ કે વધતી સત્ર સંખ્યા એ જ એકમાત્ર સીધો પુરાવો છે કે ભાષાંતર થઈ રહ્યું છે, ફક્ત ચાલુ હોવાનું નહીં.

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

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