પોર્ટ ફોરવર્ડિંગ વિના NAT પાછળની વર્કસ્ટેશન સુધી પહોંચો
ઇનબાઉન્ડ પોર્ટ ન હોય તેવી વર્કસ્ટેશન પણ હબ, રિલે કે એપ બ્રોકર દ્વારા પહોંચી શકાય છે. એક પસંદ કરતા પહેલાં દરેક ડિઝાઇન શું ખાતરી આપે છે તેની સરખામણી કરો.
કેરિયર NAT અને લૉક થયેલા ઑફિસ રાઉટર પાછળના બે એન્ડપોઇન્ટ ફોરવર્ડ કરવા માટે કોઈ ઇનબાઉન્ડ પોર્ટ છોડતા નથી, અને પ્રતિક્રિયા તો તેમ છતાં એક માંગવાની જ હોય છે. વધુ સારો પ્રશ્ન એ છે કે કઈ બાજુ બહાર ડાયલ કરી શકે છે અને કઈ પહોંચી શકાય તેવી સેવાને ટ્રાફિક વહન કરવાની મંજૂરી છે. ચાર ડિઝાઇન આ પ્રશ્નનો અલગ રીતે જવાબ આપે છે, અને માર્ગ અવરોધાય ત્યારે તેઓ અલગ રીતે નિષ્ફળ જાય છે. તેમની વચ્ચે પસંદગી કરવી એ પ્રોટોકોલ નામોની નહીં, ગેરંટીની સરખામણી છે.
ચાર ડિઝાઇન, ચાર અલગ વચનો
નીચેનું કોષ્ટક ટૂંકી આવૃત્તિ છે. મધ્યમ કોલમને એ વચન તરીકે વાંચો જે તમે ચકાસી શકો, અને જમણી કોલમને એ વચન તરીકે જે કોઈએ આપ્યું નથી.
| Design | Who initiates | Promise you get | Promise you do not get |
|---|---|---|---|
| Routed VPN hub | Both ends, outbound to the hub | A routed path to permitted prefixes | Access to services no policy allows |
| Peer traversal with ICE | Both peers to a rendezvous service | A path tested between the two peers | A direct path through every NAT |
| TURN relay | Client outbound to a relay | Transport that survives symmetric NAT | Peer discovery or a usable directory |
| Application broker | Workstation outbound to a broker | One audited application session | Subnet-wide reachability |
કઈ પંક્તિ લાગુ પડે તે પસંદગી પર નહીં, કાર્ય પર આધાર રાખે છે. એક રિમોટ ડેસ્કટોપ સેશન, એક વહીવટી શેલ અને આખા ખાનગી સબનેટ સુધીની ઍક્સેસ એ ત્રણ જરૂરિયાતો છે જેમને એક જ પ્રવેશબિંદુની જરૂર નથી, ભલે તેઓ સંજોગવશાત્ એક જ મશીન સાથે સંબંધિત હોય.
હબ બદલે છે કોણ બહાર ડાયલ કરે છે, શું મંજૂર છે તે નહીં
રાઉટેડ હબ ડિઝાઇનમાં દૂરનું લેપટોપ અને વર્કસ્ટેશન, અથવા તેની સામેનું સાઇટ ગેટવે, દરેક એવી સેવા સુધી બહાર જતી ટનલ ખોલે છે જ્યાં બંને પહોંચી શકે. વર્કસ્ટેશનના રાઉટર પર કંઈ પણ વિનંતી વગરનું જોડાણ સ્વીકારતું નથી, અને એટલે જ આ ડિઝાઇન NATમાં ટકી રહે છે અને સાઇટ પાસે સ્થિર સરનામું ન હોય ત્યારે પણ કામ કરે છે. પછી હબ પોતાની નીતિ મુજબ બે આંતરિક સરનામાંઓ વચ્ચે ટ્રાફિક રાઉટ કરે છે.
કિંમત એ છે કે હબ અસ્તિત્વમાં હોવું જોઈએ, બંને બાજુથી પહોંચી શકાય તેવું હોવું જોઈએ અને કોઈએ તેને ચલાવવું જોઈએ. આઉટબાઉન્ડ ફિલ્ટરિંગે ટ્રાન્સપોર્ટને મંજૂરી આપવી પડે, અને જે નેટવર્ક તેને અવરોધે છે તે પોર્ટ ફોરવર્ડિંગની જરૂર ન હોવા છતાં ડિઝાઇનને નિષ્ફળ કરશે.
સૂક્ષ્મ ભાગ એ છે કે પહોંચ અને અધિકૃતિ અલગ જગ્યાએ લેવાતા અલગ નિર્ણયો છે. પ્રીફિક્સમાં જતો માર્ગ એ નથી કહેતો કે વર્કસ્ટેશન પરની કઈ સેવાનો ઓળખ ઉપયોગ કરી શકે, અને ટનલને મંજૂરી આપતો ફાયરવોલ નિયમ એ નથી કહેતો કે એકાઉન્ટ લૉગિન કરી શકે કે નહીં. બંને ગોઠવો, બંને ચકાસો, અને અધિકૃતિનો નિર્ણય રાઉટિંગ કોષ્ટક પાસે નહીં, સંસાધનનો માલિક એવી સિસ્ટમ પાસે રાખો.
ટ્રાવર્સલ ત્યારે જ કામ કરે છે જ્યારે બંને સ્ટેક તેને અમલમાં મૂકે
પીઅર ટ્રાવર્સલ ચોક્કસ સિસ્ટમની ક્ષમતા છે, VPN સુધારતું સેટિંગ નહીં. Interactive Connectivity Establishment ઘણાં ઉમેદવાર સરનામાં એકત્ર કરે છે અને એક કામ ન કરે ત્યાં સુધી જોડીઓ ચકાસે છે: સ્થાનિક ઇન્ટરફેસ પર હોસ્ટ ઉમેદવારો, NAT જે પ્રગટ કરે તેમાંથી બનેલા સર્વર-રિફ્લેક્સિવ ઉમેદવારો, અને રિલે પર ફાળવાયેલા રિલે ઉમેદવારો. ફક્ત ખાનગી સરનામું માર્ગ નથી, કારણ કે બીજી બાજુ ત્યાં રાઉટ કરી શકતી નથી.
રિલે થયેલા કિસ્સાને ફગાવતા પહેલાં સમજવો યોગ્ય છે. RFC 8656 TURNને એવા પ્રોટોકોલ તરીકે વર્ણવે છે જેમાં ક્લાયન્ટ સર્વર પાસે રિલે થયેલું ટ્રાન્સપોર્ટ સરનામું માંગે છે અને સર્વર તે ક્લાયન્ટ અને તેના પીઅર્સ વચ્ચે ટ્રાફિક મોકલે છે. તેથી રિલે ડેટા વહન કરે છે, જે ફક્ત એન્ડપોઇન્ટને મળવામાં મદદ કરતી ડિરેક્ટરીથી સ્પષ્ટ રીતે અલગ છે. પીઅર સાથે રિલે સરનામું બદલવું એ સમન્વયનું પગલું છે જે એપ્લિકેશને કરવું પડે.
જે તમે વચન આપી શકતા નથી તે સીધો માર્ગ છે. સિમેટ્રિક NAT અને કેટલાક એન્ટરપ્રાઇઝ ફાયરવોલ છિદ્ર-છેદનને નિષ્ફળ કરે છે, અને જ્યારે એમ થાય ત્યારે સિસ્ટમ કાં તો રિલે પર પાછી ફરે છે અથવા નિષ્ફળ જાય છે. તમે એ પણ તારણ ન કાઢી શકો કે બે અનુવાદિત એન્ડપોઇન્ટ ક્યારેય વાત કરી શકતા નથી; રિલે ફૉલબેક સાથેનો સમર્થિત સ્ટેક એટલા માટે જ છે કારણ કે તેઓ ઘણી વાર કરી શકે છે. નક્કી કરો કે ઉપલબ્ધતા વધુ અગત્યની છે કે સીધાપણું, પછી સુખદ કિસ્સો ધારવાને બદલે તૈનાતી ખરેખર કયો માર્ગ પસંદ કર્યો તે ચકાસો.
બ્રોકર નેટવર્ક કરતાં સાંકડો છે
જ્યારે જરૂરિયાત એક એપ્લિકેશનની હોય, ત્યારે એપ બ્રોકર અથવા વર્કસ્ટેશન દ્વારા શરૂ કરાયેલું રિવર્સ કનેક્શન સૌથી નાનો જવાબ હોઈ શકે. વર્કસ્ટેશન બ્રોકર તરફ બહાર ડાયલ કરે છે, બ્રોકર દૂરના વપરાશકર્તાને પ્રમાણિત કરે છે, અને ફક્ત તે એપ્લિકેશન સેશન વહન થાય છે. વર્કસ્ટેશનના સબનેટ સુધી કોઈ માર્ગ બનતો નથી, તેથી દૂરના સેશનની છેતરપિંડી તેની બાજુના દરેક ઉપકરણ સુધીનો માર્ગ વારસામાં મેળવતી નથી.
આ સાંકડાઈની કિંમત છે: દરેક વધારાની એપ્લિકેશનને પોતાનું એકીકરણ જોઈએ, અને એપ્લિકેશન સ્થાનિક નેટવર્ક વિશે જે ધારે છે, જેમ કે નજીકના સર્વર પર ખોલાતું ફાઇલ શેર, તે પહોંચી શકાય તેવું ન પણ હોય. બ્રોકર નીતિ અને લોગિંગને એક જગ્યાએ કેન્દ્રિત કરે છે, જે ત્યાં સુધી ઉપયોગી છે જ્યાં સુધી એ જગ્યા જ વિક્ષેપ ન બને.
વિશ્વાસની સીમાઓની સરખામણી કરો, પછી માર્ગ ચકાસો
ટનલ સમાપ્ત કરતો હબ પોતે રાઉટ કરતો ટ્રાફિક વાંચી શકે છે. જ્યારે એપ્લિકેશન એન્ડ-ટુ-એન્ડ એન્ક્રિપ્ટ કરે ત્યારે રિલે સ્વતંત્ર રીતે સુરક્ષિત આદાનપ્રદાન વહન કરી શકે છે, અને બ્રોકર સામાન્ય રીતે પોતે રજૂ કરતું સેશન સમાપ્ત કરે છે. બંને એન્ક્રિપ્ટેડ છે એટલે બે ડિઝાઇન સમાન છે તેવો નિર્ણય લેતા પહેલાં નક્કી કરો કે સુરક્ષા ખરેખર ક્યાં પૂરી થાય છે.
પછી વર્કસ્ટેશન બહારની દિશામાં ખરેખર ક્યાં પહોંચે છે તે તપાસો, કારણ કે ઉપરની દરેક ડિઝાઇન તેના પર આધારિત છે. આ વર્કસ્ટેશન પર ચલાવો, અને તમે વાપરવા માગતું હોસ્ટનામ બદલો.
ss -lntup
nc -vz hub.example.com 443
curl -sS -o /dev/null -w "%{http_code}\n" https://hub.example.comડિઝાઇન ત્યારે જ સ્વીકારો જ્યારે મંજૂર ઓળખ હેઠળ ઇચ્છિત દૂરની કામગીરી સફળ થાય, બિનમંજૂર ઓળખ નકારવામાં આવે, અને સીધો કે રિલે માર્ગ ઉપલબ્ધ ન હોય ત્યારનું વર્તન જાણીતું અને દસ્તાવેજીકૃત હોય. ફરી જોડાણ અને વર્કસ્ટેશનનો સામાન્ય સ્ટાર્ટઅપ સંદર્ભ સામેલ કરો, કારણ કે ઑફિસમાં LAN દ્વારા શરૂ થયેલું સેશન દૂરની ઍક્સેસ જેના પર આધારિત છે તેમાંથી કંઈ પણ ચકાસતું નથી.