OpenBSD VPN ગેટવે પર tun0 દ્વારા LAN નું NAT

એક જ OpenBSD ગેટવે ધરાવતા બે એન્જિનિયરો ઘણી વાર દૂરસ્થ નેટવર્ક સુધી પહોંચવા માટે તમને બે અલગ નિયમ સેટ આપે છે, અને બંનેનો બચાવ થઈ શકે છે. સ્રોત ભાષાંતર અને રિટર્ન રૂટ વચ્ચેની પસંદગી એ કોઈ સિન્ટેક્સ પ્રશ્ન જ નથી. તે એના પર આધાર રાખે છે કે સામેનો છેડો 192.168.88.0/24 વિશે પહેલેથી શું જાણે છે અને તમારે તમારા લોગમાં શું રાખવું છે. ત્યાં ભૂલ કરો તો nat-to લાઇન એકદમ સાચી દેખાશે જ્યારે જવાબો દૂરસ્થ ડિફોલ્ટ ગેટવેમાં અદૃશ્ય થઈ જશે.

રૂટિંગ અને ફરીથી લખવું જુદા જ પ્રશ્નોના જવાબ આપે છે

રૂટિંગ ટેબલ નક્કી કરે છે કે 172.20.0.0/16 tun0 દ્વારા પહોંચી શકાય છે, અને એ નિર્ણય કોઈપણ pf ભાષાંતરની સલાહ લેવાય તે પહેલાં લેવાય છે. સ્રોત ભાષાંતર પછી પેકેટ હેડર બદલે છે જેથી દૂરસ્થ છેડો LAN હોસ્ટને બદલે ગેટવેનું ટનલ સરનામું જુએ. બંનેમાંથી કોઈ પણ મિકેનિઝમ બીજાનું સ્થાન લેતું નથી: nat નિયમ રૂટ ઉત્પન્ન કરી શકતો નથી, અને રૂટ એવા દૂરસ્થ રાઉટરને મનાવી શકતો નથી જેણે તમારા ખાનગી સબનેટ વિશે કદી સાંભળ્યું ન હોય. જ્યારે દૂરસ્થ બાજુ પાસે રિટર્ન પાથ ન હોય, ત્યારે જવાબો છોડી દેવાય છે અથવા તેના ડિફોલ્ટ ગેટવે તરફ મોકલાય છે, અને નિયમોનું કેટલું પણ ટ્યુનિંગ એ સુધારતું નથી.

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

ત્રણ શરતો જે નિર્ણય લે છે

ક્રમમાં ત્રણ પ્રશ્નો પૂછો અને સામાન્ય રીતે ડિઝાઇન જાતે જ પસંદ થઈ જાય છે. શું દૂરસ્થ નેટવર્ક પાસે 192.168.88.0/24 માટે ટનલ સરનામા તરફ ઇશારો કરતો સ્થિર રૂટ છે, અથવા તેનો એડમિનિસ્ટ્રેટર એ માર્ગના રાઉટરો પર નિયંત્રણ ધરાવે છે? જો હા, તો LAN સરનામાને બદલ્યા વિના જવા દો અને ભાષાંતર સંપૂર્ણપણે છોડી દો. શું તમને દૂરની બાજુએ પ્રતિ-ક્લાઇંટ દૃશ્યતા જોઈએ છે, એક્સેસ પોલિસી માટે કે ઓડિટ ટ્રેલ માટે? જો હા, તો સ્રોત જાળવી રાખવો રૂટિંગ કામ લાયક છે. શું ટનલ સરનામું દૂરસ્થ રૂટમાં લખી શકાય તેટલું સ્થિર છે, અથવા ફરી જોડાણ વચ્ચે તે બદલાય છે?

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

ટુકડો એવી રીતે મૂકો કે pf ખરેખર તેનું મૂલ્યાંકન કરે

નીચેનો ટુકડો ધારે છે કે LAN 192.168.88.0/24 છે, દૂરસ્થ નેટવર્ક 172.20.0.0/16 છે અને ટનલ ઇન્ટરફેસ tun0 છે. તેમાં કંઈ પણ આગળો હોપ પસંદ કરતું નથી. તે ફક્ત એ પેકેટો પર સ્રોત ફરીથી લખે છે જે પહેલેથી ટનલ દ્વારા બહાર જઈ રહ્યા છે.

match out on tun0 inet from 192.168.88.0/24 to 172.20.0.0/16 nat-to (tun0)
pass in on em0 inet from 192.168.88.0/24 to any keep state

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

કર્નેલ બાજુ ભૂલશો નહીં. IPv4 ફોર્વર્ડિંગ સક્ષમ હોવું જોઈએ, અને ટનલ તથા LAN માટેના સ્ટેટફુલ pass નિયમો આમાંથી કંઈ પણ અર્થપૂર્ણ થાય તે પહેલાં અસ્તિત્વમાં હોવા જોઈએ. અહીં કીવર્ડ ક્રમ માટે OpenBSD FAQ નો PF NAT વિભાગ યોગ્ય સંદર્ભ છે.

ટ્રાફિક પર ભરોસો કરતાં પહેલાં નિયમ સેટ ચકાસો

પહેલા pfctl -nf /etc/pf.conf વડે સિન્ટેક્સ તપાસો, જે ફાઇલને લોડ કર્યા વિના પાર્સ કરે છે. પછી પોલિસી લોડ કરો અને કર્નેલ ખરેખર શું ધરાવે છે તે વાંચો, કારણ કે સ્વચ્છ રીતે પાર્સ થયેલો નિયમ પણ છાયામાં રહી શકે અથવા ખોટા ઇન્ટરફેસ સાથે જોડાયેલો હોઈ શકે. pfctl -sn ભાષાંતર નિયમોને તેમના લોડ થયેલા સ્વરૂપમાં છાપે છે, અને pfctl -sr ફિલ્ટર નિયમોને મૂલ્યાંકન ક્રમમાં છાપે છે.

આગળે વાયર પર નજર રાખો. ગેટવે પર, tcpdump -ni tun0 'host 172.20.0.10' બતાવે છે કે ટનલમાંથી નીકળતું સ્રોત સરનામું ટનલ સરનામું છે કે LAN હોસ્ટ. ઝડપી netstat -rn -f inet પુષ્ટિ કરે છે કે ગંતવ્ય કયા ઇન્ટરફેસ પર ઉકેલાય છે. ટ્રાફિક વહેવા લાગે એટલે pfctl -ss સ્ટેટ એન્ટ્રીઓની યાદી આપે છે; જો ફ્લોએ કોઈ સ્ટેટ બનાવ્યું ન હોય, તો પેકેટ કદી પણ સ્ટેટ બનાવતા નિયમ સાથે મેળ ખાધું નથી.

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

જ્યારે ભાષાંતર બચાવ કરતાં વધુ ખર્ચ કરે

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

પોર્ટેબલ pf ડેરિવેટિવ્ઝ અલગ ફાંસો છે. જે ઉત્પાદનો પોતાની નિયમ ફાઇલો બનાવે છે તે ધારે છે કે NAT તેમના ઇન્ટરફેસ દ્વારા રૂપરેખાંકિત થાય, અને હાથે સંપાદિત કરેલા ટુકડા આગલી રીલોડ પર ઓવરરાઇટ થઈ જાય છે. match કીવર્ડ અસ્તિત્વમાં આવ્યા પહેલાં લખાયેલા માર્ગદર્શિકાઓમાંથી કોપી કરેલા નિયમ સેટ વર્તમાન કર્નેલ પર લોડ થશે નહીં, તેથી સિન્ટેક્સ પોર્ટ કરો અને અનુમાન કરવાને બદલે ભૂલ વાંચો.

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