Mac VPN સેટિંગ્સ સર્વર શરૂ કરતી નથી: ગેટવે ક્યાં રહે છે

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

ક્લાયંટ એન્ટ્રી લક્ષ્યનું નામ આપે છે, લિસનરનું નહીં

macOS Ventura અને તે પછીના વર્ઝનમાં સિસ્ટમ સેટિંગ્સ > નેટવર્ક > VPN માં, જૂના રિલીઝ નેટવર્ક પ્રેફરન્સ હેઠળ રાખતા ફીલ્ડ્સ વર્ણવે છે કે બીજાના એન્ડપોઇન્ટ સુધી કેવી રીતે પહોંચવું: સર્વર સરનામું, રિમોટ ID, એકાઉન્ટ કે સર્ટિફિકેટ, અને વૈકલ્પિક કનેક્ટ-ઓન-ડિમાન્ડ નિયમો. તે એન્ટ્રી સેવ કરવાથી તમારા Mac ના નેટવર્ક કન્ફિગરેશનમાં કનેક્શન સંગ્રહાય છે. પ્રક્રિયામાં કંઈ પણ પોર્ટ બાઇન્ડ કરતું નથી, લિસનર ખોલતું નથી કે રિમોટ વપરાશકર્તાને નોંધતું નથી.

તમે આ શેલમાંથી ચકાસી શકો છો. જે Mac સર્વિંગ કરતું હોય તેવી શંકા હોય તેના પર sudo lsof -nP -iUDP ચલાવો અને તમારો પ્રોટોકોલ વાપરતા પોર્ટ જુઓ: IKEv2 માટે 500 અને 4500, OpenVPN ના ડિફોલ્ટ માટે 1194, WireGuard માટે 51820. ફક્ત ક્લાયંટ ધરાવતું મશીન રિમોટ સરનામા અને પોર્ટ સાથે જોડાયેલા સોકેટ બતાવે છે, એવું વાઇલ્ડકાર્ડ બાઇન્ડ નહીં જે ઇન્ટરનેટ પરનું કોઈ પણ સુધી પહોંચી શકે. Network Extension ની અંદર ચાલતી ટનલ lsof થી છુપાઈ શકે છે, તેથી એપનું સ્ટેટસ પેનલ પણ ચકાસો; જે તમને નહીં મળે તે છે એવી Apple પ્રેફરન્સ જે આ Mac ને ગેટવે બનાવે.

ત્રણ પ્રશ્નો બે ભૂમિકાઓને અલગ પાડે છે

ક્રમમાં તેમને ઉકેલો. પહેલો સામાન્ય રીતે બાકીનું નક્કી કરે છે, અને ત્રીજો એ છે જ્યાં Mac-વિશિષ્ટ આયોજન સૌથી વધુ ખોટું જાય છે.

1. વાતચીત કોણ શરૂ કરે છે? જો તમારો Mac બહાર જોડાય અને બીજી બાજુ જવાબ આપે, તો તમારે ક્લાયંટ જોઈએ. જો ઇન્ટરનેટ પરના ઉપકરણોએ તમારા નેટવર્ક સુધી પહોંચવા અંદર જોડાવું પડે, તો તમારે જાહેર પ્રવેશબિંદુ ધરાવતું ગેટવે જોઈએ, અને Mac તે ગેટવેનું ક્લાયંટ રહી શકે.

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

3. સ્વીકારતું છેડું કયું OS રિલીઝ ચલાવે છે? Mac માટે તે પ્રશ્નનો કઠોર જવાબ છે. Apple એ VPN ને macOS Server 5.7.1 માંથી દૂર થયેલું ગણાવે છે, અને macOS Server એપ પોતે 21 એપ્રિલ 2022 ના રોજ બંધ કરવામાં આવી; સેવા ઇતિહાસની સૂચના એ પેજ છે જે જૂનું ટ્યુટોરિયલ તમને VPN સેવાના ચેકબોક્સમાંથી પસાર કરે જે હવે અસ્તિત્વમાં નથી ત્યારે વાંચવું જોઈએ.

જ્યારે પહેલો જવાબ “બહારનું કોઈ શરૂ કરે છે” હોય, ત્યારે Mac ના ક્લાયંટ પેનલમાં સ્વિચ શોધવાનું બંધ કરો અને એવો હોસ્ટ પસંદ કરો જે ટનલ સમાપ્ત કરશે.

ગેટવે તેના બદલે ક્યાં રહી શકે

ચાર ગોઠવણીઓ મોટાભાગના ઘર અને નાના ઓફિસના કેસો આવરી લે છે. અસલી સર્વર મોડ ધરાવતો રાઉટર, અલગ લેબલવાળા ક્લાયંટ મોડથી વિપરીત, ટનલને ધાર પર સમાપ્ત કરે છે અને હોસ્ટની સંખ્યા ઓછી રાખે છે, પણ તે ફર્મવેરના પ્રોટોકોલ સપોર્ટ સાથે બંધાયેલો રહે છે. NAS કે હંમેશા ચાલુ રહેતો મિની PC વેન્ડરનું સર્વર પેકેજ ચલાવે છે અને તમને વાંચી શકાય તેવા લોગ આપે છે. નાનું ક્લાઉડ VM તમને તમારા નિયંત્રણ હેઠળનું જાહેર સરનામું આપે છે અને બીજી ટનલ દ્વારા ઘર સુધી પહોંચે છે. WireGuard પર બનેલું મેશ ઓવરલે, અથવા પીઅર્સ વચ્ચે રિલે કરતી મેનેજ્ડ સેવા, બંને છેડાને બહાર જોડાવા દઈને આવનારા પોર્ટ-ફોર્વર્ડિંગને ટાળે છે.

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

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

પ્રોફાઇલ આપતા પહેલાં ભૂમિકા ખાતરી કરો

ઉમેદવાર ગેટવે પર, ઇન્સ્ટોલરે એક બનાવ્યું છે તેવું માનવાને બદલે લિસનર અસ્તિત્વમાં છે તે સાબિત કરો. macOS પર તેનો અર્થ છે ઉપરના પોર્ટ સુધી ફિલ્ટર કરેલું sudo lsof -nP -iUDP, અને જો પેકેટ ફિલ્ટર નિયમો ડિઝાઇનનો ભાગ હોય તો sudo pfctl -s nat પણ. Linux પર, ss -lunp એ જ હકીકતો સ્પષ્ટપણે દર્શાવે છે.

પછી નેટવર્કની બહારથી, પ્રોટોકોલનો ઉપયોગ કરીને પરીક્ષણ કરો. Ping થોડું જ સાબિત કરે છે: ICMP સામાન્ય રીતે ફિલ્ટર થાય છે અને UDP 51820 વિશે કંઈ કહેતું નથી. વિગતવાર લોગિંગ સાથેનું ક્લાયંટ હેન્ડશેક, સેલ્યુલર ડેટા પરના ફોનથી ચલાવેલું, સૌથી સસ્તું સાચું પરીક્ષણ છે કારણ કે તે એ જ માર્ગ પસાર કરે છે જે રિમોટ સહકર્મી પસાર કરશે.

તે પછી જ તમે ક્લાયંટ પ્રોફાઇલને સ્પર્શો. Mac પર, scutil --nc list સિસ્ટમને જાણ હોય તેવી VPN સેવાઓ છાપે છે; જો તમે હમણાં બનાવેલું ગેટવે તેમાં ન હોય, તો તમે પરીક્ષણ કરેલા મશીન કરતાં અલગ મશીન ગોઠવી રહ્યા છો. જો હેન્ડશેક LAN પર સફળ થાય પણ બહારથી નિષ્ફળ જાય, તો દોષ આવનારા માર્ગમાં છે: NAT નિયમ, પ્રોવાઇડર CGNAT, કે ગેટવે પરનું ફાયરવોલ, તે ક્રમમાં.

કંઈ પણ બનાવતા પહેલાં, ચાર મુદ્દા નક્કી કરો:

• કનેક્શન કઈ બાજુ શરૂ કરે છે, તમારો Mac કે રિમોટ ઉપકરણ.
• સ્વીકારતા હોસ્ટનું OS રિલીઝ અને ઉત્પાદન ખરેખર સર્વર ભૂમિકા ટેકો આપે છે કે નહીં.
• તમારો ISP તમને પહોંચી શકાય તેવું જાહેર સરનામું આપે છે કે નહીં.
• ગેટવે કયો એક પોર્ટ અને પ્રોટોકોલ સ્વીકારશે, અને તેની પાછળ કઈ સેવા જવાબ આપે છે.

આગળનું પગલું ઠોસ છે: ગેટવે હોસ્ટ પસંદ કરો, બહારથી તેનું લિસનર ખાતરી કરો, અને પછી જ Mac પર તે તરફ નિર્દેશ કરતી ક્લાયંટ એન્ટ્રી બનાવો.