એક OpenVPN પોર્ટ, ત્રણ સેવાઓ: આંતરિક પોર્ટ કેમ મહત્ત્વના છે

એક SSH સત્ર, એક વેબ એપ અને એક નામ શોધ પોર્ટ માટે લડ્યા વિના એક જ VPN કનેક્શન વહેંચી શકે છે. ક્લાયંટ ગેટવે તરફ એક એન્ક્રિપ્ટેડ પ્રવાહ બનાવે છે, અને દરેક એપ્લિકેશન વાતચીત તેની અંદર મુસાફરી કરે છે. બહાર ફક્ત ટનલનું પોતાનું પરિવહન અને પોર્ટ દેખાય છે. અંદર દરેક સેવા પોતાનું પોર્ટ રાખે છે અને હજુ પણ પોતાની પરવાનગી જરૂરી છે.

બાહ્ય પ્રવાહ શું વહન કરે છે અને શું છુપાવે છે

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

તેથી WAN ઇન્ટરફેસ પરનું કેપ્ચર એક વાતચીત બતાવે છે, ત્રણ નહીં. આંતરિક પોર્ટ ફક્ત ડિકેપ્સ્યુલેશન પછી દેખાય છે. એટલે જ એક જ ફાયરવોલ છિદ્ર SSH, HTTPS અને DNS એકસાથે વહન કરી શકે છે.

# WAN side: one outer tuple, whatever the inner services are
tcpdump -ni wan0 'udp port 443'
# tunnel side: the inner tuples appear after decapsulation
tcpdump -ni tun0

TUN/TAP દસ્તાવેજીકરણ તે હસ્તાંતરણને આવરી લે છે જેમાં રૂટ કરેલું TUN ઉપકરણ કર્નલ અને વપરાશકર્તા-અવકાશ પ્રક્રિયા વચ્ચે IP પેકેટ પસાર કરે છે. આ હસ્તાંતરણ જ ગેટવેના રૂટિંગ અને ફાયરવોલ કોડ માટે આંતરિક હેડર દૃશ્યમાન બનાવે છે. તે એ પણ સમજાવે છે કે બાહ્ય પોર્ટ કઈ સેવાઓ માન્ય છે તે વિશે કંઈ કેમ કહેતું નથી.

NAT ફોરવર્ડ સાંભળનારનું છે, એપ્લિકેશનોનું નહીં

IPv4 NAT પાછળનું સ્વ-હોસ્ટ કરેલું ગેટવે એક ઇનબાઉન્ડ અનુવાદ માગે છે: જાહેર સરનામું અને પોર્ટ VPN સાંભળનાર પર મેપ થાય છે. ફક્ત ટનલ વપરાશકર્તાઓ તેમને પહોંચે છે એટલા માટે SSH, HTTPS કે DNS માટે કોઈ નિયમ જરૂરી નથી. તે પોર્ટ પ્રકાશિત કરવાથી એવી સેવાઓ ખુલ્લી થશે જે ટનલ પહેલેથી સુરક્ષિત કરે છે. ફોરવર્ડિંગ નિયમ સાંભળનારની પહોંચ વર્ણવે છે, અંદરની કોઈ વસ્તુની પરવાનગી નહીં.

ઊલટું પણ સાચું છે. ટનલનું પોર્ટ ખોલવાથી બીજું કંઈ ખુલ્લું થતું નથી, તેથી ફક્ત ટનલ દ્વારા પહોંચી શકાય તેવી સેવા તેની જાહેર સપાટી બંધ રાખે છે. આ વિભાજન સામાન્ય રીતે સેવાને શરૂઆતથી ખાનગી રાખવાનું કારણ છે.

આંતરિક નીતિ એ છે જ્યાં પ્રવેશ ખરેખર નક્કી થાય છે

એન્ક્રિપ્શન માર્ગનું રક્ષણ કરે છે; તે ગંતવ્યને અધિકૃત કરતું નથી. ક્લાયંટ રૂટ પસંદ કરે છે કયા પ્રીફિક્સ ટનલમાં પ્રવેશે, ગેટવેની ફોરવર્ડિંગ નીતિ નક્કી કરે છે કે પેકેટ તેને છોડી શકે છે કે નહીં, અને ગંતવ્યનો ફાયરવોલ તથા લોગિન નક્કી કરે છે કે સેવા જવાબ આપે છે કે નહીં. DNS સૌથી સ્પષ્ટ કિસ્સો છે: ક્વેરી વહન કરવાથી રિઝોલ્વર તમારા ક્લાયંટ પૂલમાંથી તેમને સ્વીકારે એવું થતું નથી. દરેક સ્તર સ્વતંત્ર રીતે ના કહી શકે છે.

ટનલ દ્વારા દરેક સેવાને અલગથી ચકાસો. સફળ શોધ વેબ પોર્ટ વિશે કંઈ કહેતી નથી, અને સફળ વેબ વિનંતી SSH વિશે કંઈ કહેતી નથી.

dig @10.40.0.53 app.corp.example
nc -vz 10.40.0.10 8443
ssh -p 2222 [email protected]

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

WireGuard એ જ રેખા દોરે છે

WireGuard તેના બાહ્ય સાંભળનારને ListenPort થી નામ આપે છે, અને આંતરિક એપ્લિકેશન હજુ પણ જરૂરી સેવા પોર્ટ વાપરે છે. AllowedIPs રૂટ કરેલા પ્રીફિક્સનો સમૂહ છે, માન્ય સેવા પોર્ટની યાદી નહીં. તેને પોર્ટ પરવાનગી યાદી તરીકે વાંચવાથી એવા નિયમો બને છે જે ટનલ જે કરે છે તેનાથી મળતા નથી. નામકરણ અલગ છે; સ્તરીકરણ નહીં.

સેવાને સ્થાનિક-ઇનપુટ નીતિમાં મંજૂરી આપો જ્યારે તે એન્ડપોઇન્ટ પર જ ચાલે, અથવા ફોરવર્ડિંગ નીતિમાં જ્યારે તે તે એન્ડપોઇન્ટની પાછળ હોય. આ તફાવત નક્કી કરે છે કે કયો નિયમ-સમૂહ પેકેટ જુએ છે.

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