strongSwan માં સંપૂર્ણ ટનલ માટે બંને બાજુ 0.0.0.0/0 જરૂરી છે

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

પહેલા ક્લાયન્ટનું સિલેક્ટર તપાસો

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

children {
    net {
        local_ts  = dynamic
        remote_ts = 0.0.0.0/0
    }
}

આ ટુકડો સંપૂર્ણ કનેક્શન ફાઇલ નથી, અને આ એવું ધારે છે કે પ્રમાણીકરણ, ઓળખ અને વર્ચ્યુઅલ સરનામાંનો સમૂહ પહેલેથી ગોઠવાયેલા છે. ક્લાયન્ટનું સ્રોત સિલેક્ટર અને સર્વર ફાળવે છે તે સરનામું હજી પણ મેળ ખાવું જોઈએ, નહીં તો child SA એવા વ્યાપ સાથે આવશે જે કોઈ પણ પક્ષે ધાર્યો ન હતો. તેને swanctl --load-all વડે લોડ કરો અને સફળતા ધારવા પહેલા આઉટપુટ વાંચો. પાર્સ થતી ફાઇલ પણ એવા સિલેક્ટરને કારણે નકારી શકાય છે જે બીજા પક્ષના પ્રસ્તાવ સાથે ઓવરલેપ થતું નથી.

ગેટવેનું સિલેક્ટર તેની પોતાની બાજુ તપાસો

ગેટવે એ જ વિભાવના વિરુદ્ધ દિશામાંથી વાંચે છે. ઇન્ટરનેટ ગંતવ્યો ગેટવે માટે સ્થાનિક છે, તેથી તેનું local_ts પહોળું છે અને remote_ts ક્લાયન્ટ સમૂહનું વર્ણન કરે છે. આ ઉલટાવ સંપૂર્ણ-ટનલ ગોઠવણીમાં સૌથી સામાન્ય ભૂલ છે, અને તે સમીક્ષામાંથી પસાર થાય છે કારણ કે બંને લાઇનો અલગ રીતે વિશ્વાસપાત્ર લાગે છે.

children {
    rw {
        local_ts  = 0.0.0.0/0
        remote_ts = 10.77.0.0/24
    }
}

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

જૂનું ipsec.conf જુદી જુદી કી સાથે ડાબી અને જમણી ભૂમિકાઓ વાપરે છે, અને rightsubnet લાઇન swanctl મૂલ્યનો સીધો વિકલ્પ નથી. બંને સિન્ટેક્સને અલગ ફાઇલોમાં રાખો, એકને બીજામાં પેસ્ટ કરવાને બદલે. બંનેને એક ડિરેક્ટરીમાં ભેળવવું એ છે કે કેવી રીતે કાર્યરત કનેક્શન રીબૂટ પછી ચૂપચાપ પાછું જતું રહે છે.

ફાઇલ નહીં, વાટાઘાટ કરેલ child SA તપાસો

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

swanctl --list-conns
swanctl --list-sas
ip xfrm policy list

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

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

ફોરવર્ડિંગ અને પરત માર્ગ તપાસો

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

sysctl net.ipv4.ip_forward
iptables -t nat -S | grep -i masq
ip route get 1.1.1.1

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

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

ટનલ હજી શું આવરી લેતી નથી તે તપાસો

સિલેક્ટર જોડી IPv4 આવરી લે છે અને બીજું કંઈ નહીં. IPv6, DNS અને કોઈ પણ એપ્લિકેશન-સ્તરીય નીતિ અલગ નિર્ણયો છે જેને પહોળું IPv4 સિલેક્ટર ચૂપચાપ અવગણે છે. દરેક IPv4 પેકેટ વહન કરતી ટનલ હજી પણ દરેક નામ-શોધ લીક કરી શકે છે.

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

resolvectl query intranet.example.internal
traceroute -n 1.1.1.1

ઉપરની યાદીમાંથી વાટાઘાટ કરેલા સિલેક્ટર સાથે તે બે આદેશોથી સાંકળની પુષ્ટિ કરો. જો traceroute સ્થાનિક રાઉટરને પહેલા હોપ તરીકે દર્શાવે, તો સિલેક્ટર ગમે તે દાવો કરે, ટ્રાફિક ટનલ વાપરતો નથી. ઇન્ટરનેટ ઍક્સેસ ત્યારે જ સંપૂર્ણ છે જ્યારે પસંદ કરેલો ટ્રાફિક રચાયેલા ગેટવે દ્વારા સ્વીકારાય, ફોરવર્ડ થાય અને પાછો ફેરવાય. પ્રોફાઇલમાં 0.0.0.0/0 શોધવું એ તે સાંકળની શરૂઆત છે, તેનો પુરાવો નહીં.