ASA: એક જાહેર IP પર VPN પોર્ટ અને DMZ સ્ટેટિક PAT
એક જાહેર સરનામું, બે સેવાઓ. VPN લિસનર અને DMZ PAT માટે સરનામું, ટ્રાન્સપોર્ટ અને પોર્ટની યાદી બનાવો, તે પહેલાં કે એક બીજાની એન્ટ્રી પર દાવો કરે.
બે સેવાઓ, એક જાહેર સરનામું અને એક DNS નામ જે પોર્ટ અનામત રાખતું હોય એવું લાગે છે. એવું કરતું નથી. ASA પર VPN એન્ટ્રીની બાજુમાં DMZ સર્વર પ્રકાશિત કરતા પહેલાં એન્ટ્રી ટ્યુપલ લખો અને ક્રમમાં તપાસો; હાલની સેવા સાથે મેળ ખાતું પહેલું ક્ષેત્ર એ જ જગ્યા છે જ્યાં યોજના અટકે છે. નીચેનું બધું ધારે છે કે VPN ઉપકરણ પર જ સમાપ્ત થાય છે, અંદરના સર્વર પર નહીં.
આદેશ લખતા પહેલાં પાંચ ક્ષેત્રો લખો
દરેક જાહેર એન્ટ્રી માટે સરનામા કુટુંબ, જાહેર સરનામું, ટ્રાન્સપોર્ટ, જાહેર પોર્ટ અને માલિક નોંધો. માલિક કાં તો ASA-સ્થાનિક સેવા છે અને કાં અનુવાદિત અંદરનું સર્વર. બે એન્ટ્રી એક સરનામું વહેંચી શકે અને તોપણ જુદા ટ્યુપલ રહી શકે, અને બે એન્ટ્રી ડાયાગ્રામમાં જુદી દેખાય પણ ઉપકરણ પર અથડાય.
અસલી પોર્ટ માટે બીજો સ્તંભ રાખો, જેના પર અંદરનું સર્વર ખરેખર સાંભળે છે. જાહેર પોર્ટ અને અસલી પોર્ટ સ્વતંત્ર પસંદગીઓ છે, અને જે ક્ષણે તમે બંનેને એક સ્તંભમાં ભેગા કરો છો, ત્યારે પછી તમારો પોતાનો અનુવાદ વાંચવાની ક્ષમતા ગુમાવો છો.
| Public entry | Owner | Real side |
|---|---|---|
| TCP 443 on the outside address | ASA VPN listener | Appliance-local, no translation |
| TCP 8443 on the outside address | Static PAT | DMZ server TCP 443 |
| UDP 443 on the outside address | Check the effective listeners | Possibly the VPN data path |
અસલી અને મેપ કરેલી સ્થિતિઓ સાચી રીતે વાંચો
તમે જે સર્વર ઉમેરવા માંગો છો તેનાથી નહીં, પણ જે ટ્યુપલ પહેલેથી તમારી પાસે છે તેનાથી શરૂ કરો. એક દ્રષ્ટાંતરૂપ વિભાજન મંજૂર VPN એન્ટ્રીને જાહેર TCP 443 પર રાખે છે અને જાહેર TCP 8443 પર DMZ HTTPS સર્વર પ્રકાશિત કરે છે, જ્યારે તે સર્વર 443 પર સાંભળવાનું ચાલુ રાખે છે:
Public TCP 443 -> ASA VPN listener
Public TCP 8443 -> DMZ server TCP 443તૈનાત કરેલા આદેશમાં અસલી સેવા અને મેપ કરેલી સેવા નિશ્ચિત સ્થાનો પર બેસે છે, અને તેમને ઉલટાવવાથી તૂટેલી નહીં પણ બીજી મેપિંગ વર્ણવાય છે. ચાલુ અનુવાદ કોયડો બનવાની આ સૌથી સામાન્ય રીત છે: રૂપરેખાંકન માન્ય છે, તે ફક્ત બીજે ક્યાંક ઈશારો કરે છે.
Cisco ની ASA 9.16 NAT માર્ગદર્શિકા સ્ટેટિક PAT, ઇન્ટરફેસ-સરનામાનો ઉપયોગ અને અસલી વિરુદ્ધ મેપ કરેલા પોર્ટના અર્થનું દસ્તાવેજીકરણ કરે છે. તમે ખરેખર ચલાવો છો તે આવૃત્તિનો વિભાગ વાંચો; જૂના પ્લેટફોર્મથી યાદ રહેલો આદેશ સંપૂર્ણ વર્તમાન રૂપરેખાંકન નથી.
ટ્રાન્સપોર્ટને અનામતનો ભાગ ગણો
TCP 443 અને UDP 443 જુદા ટ્યુપલ છે, અને તે તફાવત તમને UDP મફતમાં આપતો નથી. VPN પાસે અલગ TLS અને DTLS લિસનર હોઈ શકે, અને બીજી રૂપરેખાંકિત સેવાઓ તમે ઈચ્છો તે ટ્રાન્સપોર્ટ પહેલેથી રાખી શકે. વેબ પેજ જ આખી VPN એન્ટ્રી છે એમ ધારવાને બદલે પ્રભાવી લિસનર અને એક્સેસ નીતિની યાદી બનાવો.
એ જ સરનામા પર રિઝોલ્વ થતું બીજું હોસ્ટનામ પણ ટ્રાન્સપોર્ટ-સ્તરીય અથડામણ ઉકેલતું નથી. DNS એ નામ-થી-સરનામાની મેપિંગ છે, પોર્ટ બ્રોકર નહીં, અને PAT દ્વારા સર્વર પ્રકાશિત કરવું એ VPN લિસનરને બીજા પોર્ટ પર ખસેડવાની સમાન ક્રિયા નથી.
જો VPN એન્ટ્રી ખરેખર ખસેડવી પડે, તો ચાર વસ્તુઓ સાથે બદલાય છે: ક્લાયન્ટ પ્રોફાઇલ, જાહેર URL, અપસ્ટ્રીમ ફિલ્ટરિંગ અને તૈનાતી વાપરે છે તે દરેક ટ્રાન્સપોર્ટ. એક પછી એકને બદલે એક જ વિન્ડોમાં કરો. જે સેવા દ્વારા તમે ઉપકરણ સુધી પહોંચો છો તેને સ્પર્શ કરતા પહેલાં ઉપકરણ સુધીનો અલગ મેનેજમેન્ટ માર્ગ ખુલ્લો રાખો. બીજા માર્ગ વિના, ખસેડવું એ એવો ફેરફાર છે જેને તમે બહારથી પાછું ફેરવી શકતા નથી.
બહારથી નવા કનેક્શન સાથે ચકાસો
પ્રભાવી એક્સેસ નીતિ હેઠળ ફક્ત ઈચ્છિત DMZ એપ્લિકેશનને મંજૂરી આપો, પછી મેળ ખાતો અનુવાદ ક્રમ, સર્વરનો પરત માર્ગ અને પ્રમાણપત્ર પરનું હોસ્ટનામ તપાસો. PAT નેટવર્ક ગંતવ્ય બદલે છે; તે એપ્લિકેશન એક્સેસ આપતું નથી અને બીજા હોસ્ટનું નામ ધરાવતું પ્રમાણપત્ર સુધારતું નથી.
અધિકૃત બહારના હોસ્ટથી નવા કનેક્શન સાથે બંને સેવાઓ ચકાસો: VPN હજી પણ સ્થપાવું જોઈએ, અને DMZ વિનંતી તેના ઈચ્છિત લિસનર સુધી પહોંચવી જોઈએ. સ્થપાયેલું સત્ર અગાઉની સ્થિતિ રાખી શકે, તેથી એક મિનિટ પહેલાં બદલેલી મેપિંગ વિશે તે કંઈ સાબિત કરતું નથી.
તમે જે તૈનાત કર્યું તેનાથી એન્ટ્રી ઇન્વેન્ટરી અપડેટ કરીને ચક્ર બંધ કરો, જેમાં બનાવ્યા વિના શોધી કાઢેલા દરેક લિસનરનો સમાવેશ થાય. તે સરનામા પર આગળ સેવા પ્રકાશિત કરનાર વ્યક્તિ તમારા ટેબલથી શરૂ કરશે, અને ત્યાંની ખોટી પંક્તિ અહીંના ખોટા આદેશ કરતાં વધુ મોંઘી પડે છે.