NAT પાછળનો OpenVPN ક્લાયન્ટ કેવી રીતે ઇન્ટરનેટ એક્ઝિટ બને છે
એક્ઝિટ પોતે બહાર ડાયલ કરે છે, તેથી તેના રાઉટરને કોઈ ઇનબાઉન્ડ પોર્ટની જરૂર નથી. હબ શું રૂટ કરે છે, એક્ઝિટ શું ફોરવર્ડ કરે છે અને રિટર્ન પાથ ક્યાંથી આવે છે તે અનુસરો.
ત્રણ Linux હોસ્ટ, એક ડિઝાઇન: જાહેરમાં પહોંચી શકાય તેવું OpenVPN હબ, એક લેપટોપ અને સામાન્ય હોમ રાઉટર પાછળ બેઠેલી એક એક્ઝિટ મશીન, જે અંદર કંઈ પણ ફોરવર્ડ કરતી નથી. એક્ઝિટ પોતે હબને ડાયલ કરે છે. પછી ગ્રાહકનું ઇન્ટરનેટ ટ્રાફિક લેપટોપ પર ટનલમાં પ્રવેશે છે અને એક્ઝિટના પોતાના અપલિંક દ્વારા બહાર નીકળે છે. આ ગોઠવણમાં આશ્ચર્યજનક બધું એક વિગતમાંથી આવે છે: કનેક્શન એક્ઝિટે શરૂ કર્યું, તેથી અંદરનો રસ્તો પહેલેથી જ છે અને તેને બનાવવા માટે પોર્ટ ફોરવર્ડિંગની જરૂર નથી.
નીચેનું કન્ફિગરેશન ક્રમને નહીં, પેકેટના રસ્તાને અનુસરે છે, કારણ કે કયો ઘટક કયો નિર્ણય લે છે તે જાણ્યા પછી જ કન્ફિગરેશનનો અર્થ થાય છે. દરેક સ્તર બરાબર એક નિર્ણય લે છે, અને ભૂલો ત્યાં ભેગી થાય છે જ્યાં બે સ્તરને એક ગણવામાં આવે છે.
બે ટ્રાન્સપોર્ટ સેશન, એક આંતરિક માર્ગ
દરેક હોસ્ટ હબ સાથે પોતાનું બાહ્ય કનેક્શન રાખે છે, અને એમાંથી કોઈ પણ બીજા વિશે જાણતું નથી. ગ્રાહકનું ઇન્ટરનેટ તરફનું ટ્રાફિક એક અલગ આંતરિક પ્રવાહ છે, જે ગ્રાહકની ટનલમાં વહે છે અને પછી એક્ઝિટની ટનલમાંથી ફરી બહાર નીકળે છે. હબે એ પ્રવાહ જ રૂટ કરવો પડે છે, અને એક્ઝિટે એ જ ફોરવર્ડ કરવો પડે છે.
outer: consumer --TLS--> hub
outer: exit --TLS--> hub
inner: consumer --tun--> hub --internal--> exit --tun--> uplink
બંને બાહ્ય કનેક્શન ક્લાયન્ટની બાજુથી બહાર જતાં હોવાથી, એક્ઝિટનું રાઉટર ક્યારેય ઇનબાઉન્ડ SYN જોતું નથી અને તેને ક્યારેય ડેસ્ટિનેશન NAT નિયમની જરૂર પડતી નથી. તેને ફક્ત સ્થાપિત ટ્રાન્સપોર્ટ જીવંત રાખવો પડે છે, જે તે કોઈપણ લાંબા કનેક્શન માટે પહેલેથી કરે છે. જાહેર ઇન્ટરનેટ પર કંઈ પણ પહેલા એક્ઝિટ સુધી પહોંચવાની જરૂર નથી, તેથી તે અપલિંક પર ડાયનેમિક સરનામું સમસ્યા નથી. રાઉટરે હજી પણ આઉટબાઉન્ડ સેશનને મંજૂરી આપવી પડે છે, પણ તે બ્રાઉઝર પહેલેથી વાપરતી પરવાનગી જ છે.
iroute ખરેખર સર્વરની અંદર શું ઇન્સ્ટોલ કરે છે
હબ એ જ એકમાત્ર ઉપકરણ છે જે નક્કી કરે છે કે કયો પીઅર કયા ગંતવ્યનો માલિક છે, અને એ નિર્ણય તે પોતાના યુઝરસ્પેસ રૂટિંગ ટેબલમાં લે છે, કર્નલના ટેબલમાં નહીં. એક્ઝિટ માટે exit-node નામની client-config-dir એન્ટ્રી ત્યાં ડિફોલ્ટ પ્રીફિક્સનો દાવો કરી શકે છે:
# /etc/openvpn/server/ccd/exit-node
iroute 0.0.0.0 0.0.0.0
એ લીટી સર્વર પ્રોસેસને કહે છે "કોઈપણ ગંતવ્ય સાથેના આંતરિક પેકેટ આ ક્લાયન્ટના છે". તે હબના ઓપરેટિંગ સિસ્ટમમાં ડિફોલ્ટ રૂટ ઉમેરતું નથી અને હબને ઇન્ટરનેટ ગેટવે પણ બનાવતું નથી. OpenVPN 2.6 સંદર્ભ ક્લાયન્ટ-વિશિષ્ટ આંતરિક રૂટિંગ અને કર્નલ રૂટિંગને અલગ મિકેનિઝમ તરીકે રાખે છે, અને એ જ વિભાજન એ કારણ છે કે આ ડિઝાઇન હબના ડિફોલ્ટ રૂટને અડ્યા વિના કામ કરે છે.
ગ્રાહકને વિરુદ્ધ સૂચના જોઈએ, push તરીકે પહોંચાડાયેલી, જેથી તેનું ટ્રાફિક સ્થાનિક ગેટવે દ્વારા બહાર જવાને બદલે ટનલમાં પ્રવેશે. સબનેટ ટોપોલોજીમાં પૂલ એક્ઝિટના tun ઉપકરણ પર જોડાયેલ રૂટ છે, તેથી પરત દિશાને વધારાની pushની જરૂર નથી; એક્ઝિટને જે મળવું ન જોઈએ તે નીચેનું રીડાયરેક્શન છે, જે તેના અપલિંક ટ્રાફિકને જે ટનલ વાપરવા માંગે છે તેમાં પાછો મોકલશે. તેને ફક્ત ગ્રાહકને મોકલો અને CCD ફાઇલ પસંદ થઈ છે એવું માનવાને બદલે ક્લાયન્ટ પર લાગુ રૂટ વાંચો.
# /etc/openvpn/server/ccd/consumer-01
push "redirect-gateway def1"
ફોરવર્ડિંગ એક્ઝિટનું કર્નલ કરે છે
એક્ઝિટની અંદર ગ્રાહકનું પેકેટ tun ઇન્ટરફેસ પર કોઈ ઇન્ટરનેટ હોસ્ટને સંબોધીને આવે છે. કર્નલ તેનું રૂટિંગ ટેબલ જુએ છે, શ્રેષ્ઠ મેળ તરીકે સાચું અપલિંક શોધે છે અને પછી બે સ્વતંત્ર નીતિઓ લાગુ કરે છે: આ પેકેટ બિલકુલ ફોરવર્ડ થઈ શકે છે કે નહીં, અને તે એ ઇન્ટરફેસ દ્વારા એ સ્રોત સરનામા સાથે બહાર જઈ શકે છે કે નહીં. ફોરવર્ડિંગ એક sysctl છે, અને ઘણા ડિસ્ટ્રિબ્યુશનમાં તે ડિફોલ્ટમાં બંધ હોય છે.
તેથી એક્ઝિટને કાયમી ધોરણે ચાલુ IPv4 ફોરવર્ડિંગ, ગ્રાહકના ટનલ સ્રોતોને અપલિંક તરફ સ્વીકારતો નિયમ અને tun દ્વારા પરત જવાનો જવાબ માર્ગ જોઈએ. આખા હોસ્ટ માટે ફોરવર્ડિંગ ચાલુ કરવાથી તેની બાજુમાંથી રૂટ થતી બીજી દરેક વસ્તુનું વર્તન પણ બદલાય છે, તેથી નિયમે બધું સ્વીકારવાને બદલે સ્રોત અને ઇન્ટરફેસના નામ આપવા જોઈએ.
પરત માર્ગ સ્રોત ભાષાંતર ખરીદે છે
ઇન્ટરનેટ હોસ્ટ પાસે 10.90.0.x સરનામા તરફ કોઈ રૂટ નથી, તેથી જવાબો એક્ઝિટ સુધી પહોંચે તે પહેલાં જ કાઢી નાખવામાં આવ્યા હોત. પેકેટ અપલિંક છોડે ત્યારે સ્રોત ફરીથી લખવાથી તે ઉકેલાય છે, અને કનેક્શન ટ્રેકિંગ પરત જતી વખતે ફરીથી લખવાનું ઉલટાવે છે.
sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s 10.90.0.0/24 -o enp1s0 -j MASQUERADE
ip -4 route get 10.90.0.9 # run on the exit: must point at the tun
ઉપરનો નિયમ એક અપલિંક ઇન્ટરફેસ માટે શરૂઆતનું બિંદુ છે, ફાયરવોલ નીતિ નથી. સ્રોતને તમે ખરેખર અધિકૃત કરેલા સોંપણીઓ સુધી મર્યાદિત કરો, અને એક્ઝિટની પોતાની ઇનપુટ નીતિ અલગ રાખો જેથી ટનલ ટ્રાફિક માટેનું માસ્કરેડિંગ સ્થાનિક સેવાઓને ચુપચાપ ખુલ્લી ન કરે. ડાયનેમિક અપલિંક સરનામાવાળા હોસ્ટ પર માસ્કરેડ તમને સરનામું હાથે ટ્રેક કરવાથી પણ બચાવે છે.
હબ ક્યાં લાગુ કરી શકે છે અને ક્યાં નહીં
client-to-client અને પરંપરાગત યુઝરસ્પેસ ડેટા પાથ સાથે હબ સર્વર પ્રોસેસની અંદર પીઅર્સ વચ્ચે આંતરિક પેકેટ સોંપે છે. તે ક્યારેય હબના કર્નલ FORWARD ચેઇનમાંથી પસાર થતા નથી, તેથી ત્યાંનો કર્નલ નિયમ ગમે તેટલો સાવધાનીથી લખાયો હોય, પીઅર-ટુ-પીઅર ટ્રાન્ઝિટ મર્યાદિત કરી શકતો નથી. અમલ સર્વરની પોતાની નીતિમાં જ રહેવો જોઈએ: કોને કનેક્ટ થવાની પરવાનગી છે, તેને કઈ CCD ફાઇલ મળે છે અને એક્ઝિટની ડિફોલ્ટ માલિકી બિલકુલ આપવામાં આવે છે કે નહીં.
તેથી જ ડિફોલ્ટ iroute વિશાળ વિશ્વાસનો નિર્ણય છે. એક્ઝિટે મનસ્વી ઇન્ટરનેટ સરનામાંઓથી પરત ટ્રાફિક કાયદેસર રીતે સ્વીકારવો પડે છે, અને તે એવી મશીન હોવી જોઈએ જે તમે નિયંત્રિત કરો, પેચ કરો અને દેખરેખ રાખો. એ જ માલિકી એવા પીઅરને આપવી, જેને તમે રાઉટર ન સોંપો એ જ ભૂલ છે જે આ ડિઝાઇન આમંત્રે છે.
સભ્યપદ એ જ સાચું નિયંત્રણ છે. પોતાના રૂટ ગોઠવી શકતો કોઈપણ ક્લાયન્ટ એક્ઝિટ વાપરવાનો પ્રયાસ કરી શકે છે, તેથી કોને કનેક્ટ થવાની પરવાનગી છે અથવા એક્ઝિટ કયા પીઅર્સની સેવા કરશે તે મર્યાદિત કરવું ડિઝાઇનનો ભાગ છે, પછીનો વિચાર નહીં.
એક્ઝિટ અદૃશ્ય થાય ત્યારે સુરક્ષિત રીતે નિષ્ફળ થવું
એક્ઝિટ ઑફલાઇન કરો અને આંતરિક ડિફોલ્ટ માલિકી તેના સેશન સાથે અદૃશ્ય થઈ જાય છે. જે ન બનવું જોઈએ તે એ છે કે હબ ચુપચાપ બદલી એક્ઝિટ બની જાય: VPN પૂલથી હબના અપલિંક સુધી કોઈ ડિફોલ્ટ રૂટ નહીં, અને હબ પર કોઈ વિશાળ માસ્કરેડ નિયમ નહીં જે એ જ ટ્રાફિક ખુશીથી ફોરવર્ડ કરે. એ નિષ્ફળતા જાણી જોઈને પરખો, પછી પહેલેથી ખુલ્લા પૃષ્ઠને બદલે નવા પ્રવાહ સાથે પુનઃપ્રાપ્તિ પરખો.
# on the consumer, with the exit up and then down
ip -4 route get 1.1.1.1
curl -sS -o /dev/null -w '%{http_code}\n' https://example.com
એક્ઝિટ ગયા પછી પણ ગ્રાહકનું ટ્રાફિક ઇન્ટરનેટ સુધી પહોંચે છે, તો બીજું કંઈક તેને વહેવડાવે છે અને તમે ધારેલી સીમા અસ્તિત્વમાં નથી. DNS અને IPv6ને પણ અલગ નિર્ણય તરીકે ગણો: IPv4 રૂટ અને માસ્કરેડ AAAA ટ્રાફિક વિશે કંઈ કહેતા નથી, અને હબ દ્વારા ધકેલાયેલો રિઝોલ્વર ક્વેરી ખરેખર જ્યાંથી નીકળે ત્યાંથી જ જવાબ આપશે.