સાઇટ-થી-સાઇટ VPN માં બીજું સબનેટ ઉમેરવું: બે માર્ગ
પોલિસી-આધારિત ટનલને બંને બાજુ મેળ ખાતા સિલેક્ટરની જરૂર પડે; રૂટ-આધારિતને રૂટની. યોગ્ય માર્ગ પસંદ કરો અને પહેલાં પરત રૂટ સુધારો.
કાર્યરત સાઇટ-થી-સાઇટ ટનલમાં બીજું સબનેટ ઉમેરવામાં એક ડિઝાઇનમાં પાંચ મિનિટ લાગે છે અને બીજીમાં લગભગ આખી બપોર. જ્યારે ટનલ તમે નામ આપેલા પ્રિફિક્સ માટે રૂટ ઇન્સ્ટોલ કરે છે ત્યારે તમે રૂટ ઉમેરો છો અને ટ્રાફિક તેને અનુસરે છે. જ્યારે તે એક નિશ્ચિત સિલેક્ટર જોડી પર વાટાઘાટ કરે છે, નવું પ્રિફિક્સ બંને બાજુ મેળ ખાતી જોડી પર સંમત થાય ત્યાં સુધી અસુરક્ષિત રહે છે. ત્રણ બાબતો નક્કી કરે છે: દરેક બાજુનું કન્ફિગરેશન ખરેખર શું વર્ણવે છે, વાટાઘાટ કરેલો ટ્રાફિક નાનામાં નાની મેળ ખાતી જોડી સુધી સંકોચાય છે કે નહીં, અને નવી શ્રેણીનો પરત માર્ગ કોની પાસે છે.
સ્થિતિ લેબલ નહીં, કર્નલ વાંચો
જોડાણની જાણ કરતી ટનલે ઓછામાં ઓછું એક ચાઇલ્ડ એસોસિએશન ઇન્સ્ટોલ કર્યું છે, પણ જરૂરી નથી કે તમે ધારો છો તે. Linux માં કર્નલ બતાવે છે કે શું લાગુ થાય છે: ip xfrm policy સિલેક્ટર જોડીઓની યાદી આપે છે અને swanctl --list-sas (કે જૂનું ipsec statusall) બતાવે છે કે બાજુઓએ શું વાટાઘાટ કરી, દરેક દિશામાં ટ્રાફિક સિલેક્ટર સહિત. નવું પ્રિફિક્સ બંનેમાં ન હોય તો કન્ફિગ ફાઇલ શું કહે તે ગમે તે, તે અસુરક્ષિત છે.
આને રૂટ ટેબલ સાથે સરખાવો. રૂટ-આધારિત ગોઠવણમાં ટનલ ઉપકરણ સુરક્ષિત પ્રિફિક્સ માટે આગળનું હોપ છે. પોલિસી-આધારિત ગોઠવણમાં ઘણી વાર દૂરના સબનેટ માટે ચોક્કસ રૂટ હોતો નથી, ફક્ત ડિફોલ્ટ રૂટ, કારણ કે ટેબલ નહીં પોલિસી ટ્રાફિક પસંદ કરે છે.
પોલિસી-આધારિત ટનલ: બંને બાજુ નવું પ્રિફિક્સ હોવું જોઈએ
strongSwan ની શબ્દાવલીમાં સિલેક્ટર ચાઇલ્ડ કન્ફિગ હેઠળ local_ts અને remote_ts માં રહે છે, જે leftsubnet અને rightsubnet ના અનુગામી છે. નવું પ્રિફિક્સ બંને બાજુ અરીસાની જેમ દેખાવું જોઈએ: સાઇટ A જેને સ્થાનિક કહે છે તેને સાઇટ B દૂર કહે છે. અસમાનતા ભાગ્યે જ સ્વચ્છ ભૂલ આપે છે. બાજુઓ છેદ સુધી સંકોચાય છે, જૂનું પ્રિફિક્સ ચાલુ રહે છે અને ફક્ત નવું શાંતિથી નિષ્ફળ જાય છે.
swanctl --load-conns
swanctl --initiate --child <child-name>
swanctl --list-sas
ip xfrm policypfSense કે OPNsense માં એનો અર્થ છે નવા સ્થાનિક સબનેટને નવા દૂરના સબનેટ સાથે જોડતી બીજી Phase 2 એન્ટ્રી અને પછી લાગુ કરવું. જૂની એન્ટ્રી રાખો; બદલવાથી મૂળ સબનેટ ઉમેરાવાને બદલે ખસે છે. જો હાલની Phase 2 પહેલેથી 0.0.0.0/0 જેવા સુપરનેટ કે સારાંશ શ્રેણીને આવરી લે છે, તો તેની બાજુમાં સાંકડી એન્ટ્રી ઉમેરશો નહીં: અતિક્રમણ કરતા સિલેક્ટર સ્પર્ધાત્મક પોલિસી મૂકે છે અને મૂલ્યાંકનનો ક્રમ નક્કી કરે છે કે કોણ જીતે.
IKEv1 દરેક સબનેટ જોડીને પોતાની Phase 2 બનાવે છે અને દરેક આદાનપ્રદાનમાં એક જોડી લેતી બાજુ બાકીની કાઢી નાખે છે. IKEv2 એક ચાઇલ્ડમાં અનેક સિલેક્ટર જોડીઓ લઈ જઈ શકે છે, પણ ફક્ત જો બંને અમલીકરણ સ્વીકારે. swanctl --list-sas ની યાદી સત્ય છે; તમે લખ્યું તે વિનંતી છે.
રૂટ-આધારિત ટનલ: રૂટ જ પોલિસી છે
XFRM ઇન્ટરફેસ કે VTI ઉપકરણ રૂટ ટેબલ મુજબ ટ્રાફિક લઈ જાય છે. તમે નવું પ્રિફિક્સ બંને સાઇટ પર ઉપકરણ તરફ નિર્દેશિત કરો છો અને ઇન્ટરફેસના રૂપાંતર સાથે બંધાયેલી સ્થિતિ લાગુ થાય છે. સમન્વય કરવા જેવી સિલેક્ટર જોડી નથી, તેથી સબનેટ વધતાં આ ડિઝાઇન સારી રીતે સ્કેલ થાય છે. strongSwan ફોરવર્ડિંગ માર્ગદર્શિકા કર્નલ બાજુ વિગતે સમજાવે છે.
ip route add 192.168.60.0/24 dev xfrm0
ip route get 192.168.60.10WireGuard આ વિચારને આગળ લઈ જાય છે. AllowedIPs એક જ સમયે ક્રિપ્ટો પરવાનગી યાદી છે અને wg-quick દ્વારા રૂટ ટેબલ એન્ટ્રી પણ. ફક્ત એક બાજુ પ્રિફિક્સ ઉમેરો તો હેન્ડશેક, બહાર જતા પેકેટ અને સન્નાટો મળશે, કારણ કે દૂરની બાજુ એવા પેકેટ કાઢી નાખે છે જેનો સ્રોત તેની યાદીમાં નથી. wg set સ્વરૂપ આખી યાદી બદલે છે, તેથી પહેલેથી ચાલતાં પ્રિફિક્સ ફરી લખો, નહીં તો તે કપાઈ જશે:
wg set wg0 peer <PUBKEY> allowed-ips 192.168.10.0/24,192.168.60.0/24
ip route add 192.168.60.0/24 dev wg0wg-quick ને બદલે wg set વાપર્યું હોય તો એ બીજો આદેશ વૈકલ્પિક નથી. કર્નલ નવી પરવાનગી યાદી તરત સ્વીકારે છે, પણ કોઈ તેના માટે રૂટ ઉમેરતું નથી, તેથી સ્થાનિક રીતે બનેલો ટ્રાફિક હજી ડિફોલ્ટ ગેટવેમાંથી જ નીકળે છે. નવું WireGuard સબનેટ ટનલ હોસ્ટથી ચાલે અને લેપટોપથી ન ચાલે તેનું આ સૌથી સામાન્ય કારણ છે.
પરત માર્ગ ટનલ કરતાં વધુ વાર નિષ્ફળ જાય છે
નવા દૂરના સબનેટના હોસ્ટે જવાબ VPN ગેટવે દ્વારા પાછા મોકલવા પડે. જ્યારે એ ગેટવે તેમનો ડિફોલ્ટ રાઉટર ન હોય ત્યારે જવાબ LAN રાઉટર પાસે જાય છે, જે તેને કાં કાઢી નાખે છે કાં ખાનગી સ્રોત સરનામા સાથે ઇન્ટરનેટ પર મોકલે છે. ગેટવેથી નહીં, દૂરની બાજુના હોસ્ટથી પરીક્ષણ કરો: Linux માં ip route get 10.30.20.15 કે PowerShell માં Find-NetRoute -RemoteIPAddress 10.30.20.15 બતાવે છે કે હોસ્ટ ખરેખર કયું આગળનું હોપ વાપરશે. જવાબ ટનલનું અંતિમ બિંદુ ન હોય તો ત્યાં નવા પ્રિફિક્સ માટે સ્થિર રૂટ ઉમેરો.
પરત રૂટ ન હોય તેવી સાઇટ પર સ્રોત NAT કાયદેસર વિકલ્પ છે અને ઘણી hub-and-spoke ગોઠવણો દરેક સર્વરને અડ્યા વિના આ રીતે કામ કરે છે. ગંતવ્ય બાજુના ગેટવે પર પણ નવા પ્રિફિક્સ પર તેને લાગુ કરો:
iptables -t nat -A POSTROUTING -s 10.30.20.0/24 -d 192.168.60.0/24 -j MASQUERADEખર્ચ વાસ્તવિક છે. દૂરના લોગ વ્યક્તિગત સ્રોત સરનામાં બતાવવાનું બંધ કરે છે અને મૂળ સબનેટ પર આધારિત ફાયરવોલ નિયમો ગેટવે માટે એક જ નિયમમાં સંકોચાય છે. રૂટ ન હોવાના કારણે નહીં, જાણી જોઈને આ પસંદ કરો.
ફાયરવોલ પરત માર્ગનો બીજો અડધો ભાગ છે. ઝોન-આધારિત ઉપકરણો હાલના ટનલ ઇન્ટરફેસનો ઝોન નવા સબનેટ સુધી આપોઆપ લંબાવતા નથી અને જૂના પ્રિફિક્સ માટે લખાયેલો નિયમ મેળ ખાશે નહીં. IPsec ને દોષ આપતા પહેલાં નવું સબનેટ ઝોનમાં કે બંને દિશાના નિયમ જોડીમાં ઉમેરો.
ત્રણ પ્રશ્નોથી નક્કી કરો, પછી ટ્રાફિકથી ચકાસો
ટૂંકું સ્વરૂપ: બાજુનું કન્ફિગરેશન પ્રિફિક્સના નામ આપે છે (પોલિસી-આધારિત), કે ટ્રાફિક ઇન્ટરફેસમાં રૂટ થાય છે (રૂટ-આધારિત)? બંને છેડા નવું પ્રિફિક્સ યાદીમાં લે છે? નવા સબનેટથી મૂળ સ્રોત શ્રેણી સુધી પાછા જવાનો માર્ગ છે?
| Tunnel style | Where the prefix goes | What breaks if you skip it |
|---|---|---|
| Policy-based IPsec | Selector pair on both peers | Old subnets work, the new one fails with no clear error |
| Route-based XFRM or VTI | Route into the device on both sites | Packets routed but not transformed, or the state never matches |
| WireGuard | AllowedIPs on both peers plus a route | Handshake succeeds, replies are dropped |
| Overlapping supernet | Adjust the existing entry instead | A shadowed policy wins or loses by evaluation order |
ચકાસણી એ જગ્યા છે જ્યાં મોટા ભાગના ફેરફારો ઘણા વહેલા બંધ થાય છે. ગેટવેથી પિંગ થોડું પુરવાર કરે છે, કારણ કે ગેટવે પોતાનાથી સ્રોત લે છે અને ઘણી વાર હોસ્ટ કરતાં અલગ પોલિસી સાથે મેળ ખાય છે. નવા સબનેટના હોસ્ટથી પિંગ કરો, પછી ફેરફારનું કારણ બનેલી એપ્લિકેશન ચલાવો અને સ્થિતિ ચિહ્નને બદલે કાઉન્ટર જુઓ.
tcpdump -ni any host 192.168.60.10 and (esp or udp port 4500)
ip xfrm state
wg showપોલિસી-આધારિત ટનલમાં ip xfrm state ના કાઉન્ટર બંને દિશામાં વધવા જોઈએ; સપાટ કાઉન્ટર એટલે પેકેટ રૂટ થાય છે પણ પસંદ નથી થતું. WireGuard માં wg show દરેક બાજુનું સ્થાનાંતરણ બતાવે છે અને શૂન્ય મળેલા બાઇટવાળો હેન્ડશેક દૂરની બાજુની યાદી કે તેના પરત રૂટ તરફ ઇશારો કરે છે.
પ્રિફિક્સ, બાજુનું સિલેક્ટર કે રૂટ, પરત માર્ગનો નિર્ણય અને ફાયરવોલ એન્ટ્રી બાકીની ટનલ યાદી સાથે નોંધીને પૂર્ણ કરો. પછી એક ગેટવે રીબૂટ કરીને ફરી ચકાસો: હાથે ઉમેરેલો રૂટ અદૃશ્ય થાય છે અને આગલી વ્યક્તિએ તે ફરી શોધવો ન જોઈએ.