VPN પ્રવાહમાં ક્લાયન્ટનું સ્રોત પોર્ટ વિરુદ્ધ સર્વરનું લિસનર
એક ટનલમાં બે પોર્ટ નંબરની સરખામણી કરો: સર્વરનું સ્થિર લિસનર અને ક્લાયન્ટનું અલ્પજીવી સ્રોત, અને વચ્ચે રાઉટરનું અનુવાદ કેવી રીતે બેસે છે.
એક જ વાતચીતમાં બે નંબર દેખાય છે, અને બંનેમાંથી કોઈ ખોટો નથી. સર્વરનો લોગ સેવા આપતું લિસનર બતાવે છે, લેપટોપ ડેટાગ્રામ મોકલનારું સોકેટ બતાવે છે, અને વચ્ચેનું રાઉટર બહાર જતાં બીજાને ફરી લખી શકે છે. અંકોની સરખામણી કરવા કરતાં વાતચીતના બે છેડાની સરખામણી વધુ ઉપયોગી છે. નીચેની સરખામણી લિસનર, ક્લાયન્ટ સોકેટ અને અનુવાદિત સ્રોતને અલગ રાખે છે, કારણ કે તેઓ જુદા જુદા પ્રશ્નોના જવાબ આપે છે.
વિરોધી છેડા વર્ણવતા બે નંબર
સર્વરનું ગોઠવેલું પોર્ટ એ ગંતવ્ય છે જ્યાં ક્લાયન્ટ ડાયલ કરે છે. તે નીતિથી નિશ્ચિત છે, પ્રોફાઇલમાં દેખાય છે અને સર્વરની બાજુએ ખુલ્લું હોવું જોઈએ. ક્લાયન્ટનું સ્રોત પોર્ટ સ્થાનિક રીતે પસંદ થાય છે, સામાન્ય રીતે અલ્પજીવી શ્રેણીમાંથી, અને તે એટલા માટે હોય છે કે જવાબને ઉતરવાની જગ્યા મળે. તે દરેક ફરી-જોડાણમાં બદલાઈ શકે છે, અને ડિઝાઇનમાં કંઈ પણ તેના સ્થિર રહેવા પર આધારિત નથી.
વચ્ચેનું રાઉટર તે સ્રોતને પોતાના 'NAT' મેપિંગમાં ફરી લખી શકે છે. તેથી સર્વર પર જોવા મળતા નંબરનો લેપટોપે પસંદ કરેલા નંબર સાથે ઘણી વાર કોઈ સંબંધ હોતો નથી.
બહાર જતાં સ્રોત નંબર ક્યાં બદલાય છે
IPv4નું કાલ્પનિક ઉદાહરણ લો: અનુવાદ કરતા રાઉટર પાછળનું ક્લાયન્ટ, એક 'UDP' લિસનરવાળું સર્વર, અને બંનેને પાર કરતું એક જ ડેટાગ્રામ. કોષ્ટક ત્રણ અવલોકન બિંદુઓ પર પેકેટ ફરી ચલાવવાને બદલે દરેક છેડાનું અને તેની સાથે શું થાય છે તેનું નામ આપે છે.
| Endpoint | What stays fixed | What changes on reconnect | Who owns it |
|---|---|---|---|
| Server listener | The service port and the address the profile names | Nothing; the listener does not follow the client | The server operator |
| Client socket | The destination it dials | The local source port, chosen per socket | The client, or its operating system |
| Translated source | Usually the public address of the router | The port, and sometimes the address after a network switch | The NAT device or the upstream carrier |
ગંતવ્ય દરેક હરોળમાં અચળ છે, અને ફક્ત સ્રોતની ઓળખ બદલાય છે. UDP NATની આવશ્યકતાઓ આંતરિક સરનામું અને પોર્ટને બાહ્ય મેપિંગથી અલગ પાડે છે, અને તે જ બીજી અને ત્રીજી હરોળ વચ્ચેનો તફાવત છે. રાઉટર ક્લાયન્ટનું સ્રોત પોર્ટ જાળવી રાખી શકે છે અથવા બીજું પસંદ કરી શકે છે; જાળવી રાખવું એવું નથી જે એપ્લિકેશન ધારી લે.
ત્રણેય છેડા હોસ્ટ પરથી જ વાંચો
નીચેની યાદીઓ ત્રણ જુદા મશીનોમાંથી આવે છે અને સાથે મળીને આખી વાતચીત દર્શાવે છે. પહેલી સર્વર પર, બીજી ક્લાયન્ટ પર અને ત્રીજી જ્યાં મેપિંગ છે ત્યાં ચલાવો. એક લોગ લીટી કદી ત્રણેય દર્શાવતી નથી.
ss -lunp 'sport = :1194'
ss -unp | grep 1194
conntrack -L -p udp | grep 1194પહેલી યાદી સાબિત કરે છે કે સર્વર સેવા પોર્ટ સાથે બંધાયેલું છે અને કઈ પ્રક્રિયા તેની ધરાવ છે તે બતાવે છે. બીજી ક્લાયન્ટનું સ્થાનિક સોકેટ અને તેણે ડાયલ કરેલું ગંતવ્ય બતાવે છે. ત્રીજી રાઉટરે બનાવેલું મેપિંગ બતાવે છે, અને અનુવાદિત સ્રોત ફક્ત ત્યાં જ દેખાય છે. આ ક્રમમાં વાંચો અને બે નંબર વિરોધાભાસી લાગવાનું બંધ કરે છે.
ફરી-જોડાણ શું બદલે છે અને શું નહીં
કેટલાક રાઉટર ક્લાયન્ટનું સ્રોત પોર્ટ ખાલી હોય ત્યારે જાળવી રાખે છે, અને કેટલાક દરેક વખતે અલગ ફાળવે છે. બંને વર્તન સામાન્ય છે, અને પહેલાની માગ કરતી એપ્લિકેશન બીજા પર તૂટી પડશે. ફરી-જોડાણ કે નેટવર્ક બદલાવ પછી મેપિંગ બદલાવું સર્વરની ખામી નથી: ક્લાયન્ટ નવું સોકેટ ખોલે છે, રાઉટર પાસે જે છે તે ફાળવે છે, અને સર્વર એ જ લિસનર પર નવો સ્રોત જુએ છે. ખામી એ ગણાય કે સર્વર મનસ્વી ક્લાયન્ટ પોર્ટને સંબોધિત ટ્રાફિક સ્વીકારશે એવી અપેક્ષા રાખવી.
સમુદાયના OpenVPN ક્લાયન્ટ આ વર્તન nobind દ્વારા મેળવે છે, જે ઓપરેટિંગ સિસ્ટમને સ્થાનિક પોર્ટ પસંદ કરવા દે છે; દૂરનું પોર્ટ હજી પ્રોફાઇલમાંથી જ આવે છે. સ્પષ્ટ રીતે બાંધવું એ સભાન નિર્ણય છે, પ્રોટોકોલની આવશ્યકતા નહીં. સર્વર એક જ છેડો આપતું રહે છે જ્યારે ક્લાયન્ટ પોતાની સ્થાનિક ઓળખ પસંદ કરે છે.
રેકોર્ડમાં સ્તરોને અલગ રીતે લેબલ કરો
ટનલની અંદર પોતાના પોર્ટ સાથે બીજી વાતચીત છે. ટનલ વહન કરતી HTTPS વિનંતીનું ગંતવ્ય TCP 443 છે, જ્યારે બાહ્ય એન્ક્રિપ્ટેડ જોડાણ UDP 1194 વાપરે છે, તેથી બાહ્ય સ્રોત પોર્ટ બદલવાથી અંદરની સેવામાં કંઈ બદલાતું નથી.
બાહ્ય સ્તરે પણ પ્રોટોકોલ મહત્વનો છે. UDP 1194 અને TCP 1194 જુદા છેડા છે, અને 'TCP' લિસનર કદી UDP ડેટાગ્રામ મેળવશે નહીં કારણ કે નંબર મળે છે. જ્યારે ડિપ્લોયમેન્ટનું દસ્તાવેજીકરણ કરો, ત્યારે સર્વર લિસનર, ક્લાયન્ટ સોકેટ અને અનુવાદિત સ્રોતને ત્રણ અલગ વસ્તુ તરીકે લેબલ કરો, અને દરેકમાં ટ્રાન્સપોર્ટ ઉમેરો.
પછી નીતિને ભૂમિકાઓ અનુસરવા દો. સર્વર તેના લિસનર પર ઇચ્છિત ટ્રાન્સપોર્ટ ખોલે છે અને હજી પીઅરને પ્રમાણિત કરે છે; ક્લાયન્ટનો ફાયરવોલ ઇનબાઉન્ડ સેવા પ્રકાશિત કર્યા વિના તેના પોતાના આઉટબાઉન્ડ વિનિમયના જવાબો સ્વીકારે છે. સ્ટેટલેસ ફિલ્ટરને પરત દિશા સ્પષ્ટ લખેલી જરૂરી છે, અને સુઘડ આકૃતિઓથી આગળ આ તફાવત મહત્વનો હોવાનું વ્યવહારુ કારણ એ જ છે.