NAT VPN સર્વર પર કે રાઉટર પર? બંને કામ કરી શકે છે

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

મિથ: ક્લાઇન્ટ રૂટ જ આઉટલેટ બનાવે છે

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

એ જ અસંગતિ એ સમગ્ર સમસ્યા છે જે આ લેખનો બાકીનો ભાગ હલ કરે છે. કંઈક એવું જોઈએ જે ક્લાઇન્ટના ખાનગી સરનામાને પરત કરી શકાય તેવું બનાવે, અને પસંદગી એ છે કે ક્યાં.

પહેલા જવાબનો માર્ગ દોરો

કોઈપણ સેટિંગને સ્પર્શ કરતા પહેલા માર્ગને વાસ્તવિક સરનામાંઓ સાથે લખો, અને તેના પર બે સંભવિત અનુવાદ બિંદુઓ ચિહ્નિત કરો. આ લેબ 10.70.0.0/24 નો VPN પૂલ વાપરે છે જેમાં એક ક્લાઇન્ટ 10.70.0.37 પર, સર્વરનું LAN સરનામું 172.16.40.10, રાઉટર 172.16.40.1 પર અને જાહેર આઉટલેટ 203.0.113.40 પર છે.

client 10.70.0.37 -- tunnel --> RRAS 172.16.40.10 -- LAN --> router 172.16.40.1 --> 203.0.113.40
                                  (translate here?)                             (or here?)

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

વિકલ્પ A: VPN સર્વર પર અનુવાદ

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

Get-RemoteAccess | Select-Object VpnS2SInterface, RoutingDomain
Get-NetNat | Select-Object Name, InternalIPInterfaceAddressPrefix

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

વિકલ્પ B: પૂલને રાઉટર પર લઈ જવો

બીજી ગોઠવણમાં સર્વર ક્લાઇન્ટનું સાચું સ્રોત સરનામું ફોરવર્ડ કરે છે, અને રાઉટર તેનું અનુવાદ કરે છે. તે કિનારે ક્લાઇન્ટ પૂલ દૃશ્યમાન રાખે છે, જે મદદ કરે છે જો રાઉટર એ જગ્યા હોય જ્યાં ટ્રાફિક નીતિ, લોગિંગ કે નિરીક્ષણ રહે છે. તેનો અર્થ એ પણ છે કે રાઉટરને 10.70.0.0/24 માટે 172.16.40.10 તરફ નિર્દેશ કરતા પરત રૂટની જરૂર છે, ઉપરાંત એક ઇન્ટરનેટ નીતિ જે ખરેખર તે પ્રીફિક્સ સમાવે છે; LAN સબનેટ માટે લખાયેલો નિયમ શાંતિથી પૂલ સુધી વિસ્તરતો નથી.

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

DNS, IPv6 અને સ્વીકૃતિ સ્પષ્ટ કરો

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

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

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