மற்றொரு NAT சேர்ப்பதற்கு முன் தனியார் LAN-களுக்கு இடையே வழிமாற்றம் செய்யுங்கள்
ஒன்றோடொன்று மேலெழும் முகவரி இடம், இல்லாத திரும்பு வழி அல்லது நம்பமுடியாத டிரான்சிட் ஆகியவை வழிமாற்றம், NAT மற்றும் சுரங்கப்பாதைக்கு இடையிலான தேர்வை தீர்மானிக்கின்றன. ஃபயர்வாலைத் திருத்தும் முன் இந்த மூன்றையும் சரிபார்க்கவும்.
இரண்டு உள் ஃபயர்வால்கள், ஒரு தனியார் டிரான்சிட் பிரிவு, ஒவ்வொரு LAN-இல் உள்ள சில ஹோஸ்ட்கள் மற்றதுடன் பேச அனுமதிக்கும் கோரிக்கை. வழக்கமான எதிர்வினை VPN-ஐ எழுப்புவது அல்லது இரண்டாவது NAT அடுக்கைச் சேர்ப்பது, இரண்டு எதிர்வினைகளும் பிரச்சினைக்கு தகுதியானதை விட அதிக செலவாகும். சாதாரண வழிமாற்றம் போதுமானது மூன்று நிபந்தனைகள் நிறைவேறும்போது: முகவரி வரம்புகள் மேலெழுவதில்லை, இரு பக்கங்களும் மற்ற LAN-க்கு டிராஃபிக்கைத் திருப்பி அனுப்ப முடியும், டிரான்சிட் பிரிவு தரவுக்கு ஏற்கனவே போதுமான நம்பகத்தன்மை வாய்ந்தது. எதையும் வடிவமைக்கும் முன் இந்த மூன்றையும் சரிபார்க்கவும், ஏனெனில் ஒவ்வொன்றும் பதிலை மாற்றுகிறது.
வடிவமைப்பைத் தீர்மானிக்கும் மூன்று நிபந்தனைகள்
முதல் நிபந்தனை முகவரி இடம். இரண்டு LAN-களும் ஒரே RFC 1918 தொகுதியைப் பயன்படுத்தினால், வழிமாற்றம் அவற்றை வேறுபடுத்த முடியாது, மொழிபெயர்ப்பு விருப்பமல்லாமல் தவிர்க்க முடியாததாகிறது. இரண்டாவது திரும்பு பாதை: A-வில் இருந்து B-க்கான வழி, B-க்கும் A-வின் LAN-ஐ அடைவது எப்படி என்று தெரியாவிட்டால் பயனற்றது, அசமச்சீர் அறிவே வழிமாற்ற வடிவமைப்பு பதில்களை அமைதியாக விட்டுவிடுவதற்கான பொதுவான காரணம்.
மூன்றாவது நம்பிக்கை. வழிமாற்றம் பாக்கெட்டுகளை நகர்த்துகிறது; அவற்றைப் பாதுகாக்கவில்லை. ஒரே கட்டிடத்துக்குள் உள்ள தனியார் டிரான்சிட் பிரிவு, ஒரு வழங்குநரிடம் ஒப்படைப்பதிலிருந்தும் அல்லது பகிரப்பட்ட வளாக முதுகெலும்பைக் கடக்கும் இணைப்பிலிருந்தும் வேறுபட்டது. பிரிவு நம்பகமானதல்ல என்றால், பதில் இரண்டு ஃபயர்வால்களுக்கு இடையேயான சுரங்கப்பாதை, கீழேயுள்ள வழிமாற்ற திட்டம் அதன் உள்ளேயும் பொருந்தும்.
மூன்றும் ஒரே திசையில் சுட்டினால் மட்டுமே எளிய வடிவமைப்பு வெல்லும். அவற்றில் ஒன்று தோல்வியடைந்தால், மொழிபெயர்ப்பால் மறைக்காமல் அந்த நிபந்தனையை வெளிப்படையாகச் சரிசெய்யுங்கள், ஏனெனில் NAT தோல்வியை மறைக்கிறது, தீர்க்கவில்லை.
டிரான்சிட் வலையமைப்பில் வழித் திட்டத்தை உருவாக்குங்கள்
ஒவ்வொரு ஃபயர்வாலுக்கும் பகிரப்பட்ட பிரிவில் ஒரு முகவரி கொடுத்து ஒவ்வொரு தொலைதூர LAN-க்கும் ஒரு குறிப்பிட்ட வழியைச் சேர்க்கவும். ஏற்கனவே உள்ள கட்டமைப்பில் வேறு எதையும் நகர்த்த வேண்டியதில்லை, குறிப்பாக இணைய இயல்புநிலை வழி இருக்கும் இடத்திலேயே இருக்க வேண்டும். இயல்புநிலை வழியை சக ஃபயர்வாலால் மாற்றினால் தொடர்பற்ற ஒவ்வொரு இலக்கும் டிரான்சிட் வழியாகச் செல்லும், அது கோரப்பட்ட மாற்றத்தை விட மிகப் பெரியது. pfSense-இன் நிலையான வழிமாற்ற ஆவணம் அந்த தளத்திற்கு அதே வழி-கூடுதல்-நுழைவாயில் மாதிரியை விவரிக்கிறது, நீங்கள் உண்மையில் இயக்கும் எந்த ஃபயர்வாலிலும் அதற்கு இணையான கட்டுப்பாடு உள்ளது.
| Firewall | Remote LAN | Next hop on the transit |
|---|---|---|
| A | 10.40.0.0/24 | 192.0.2.20 |
| B | 10.30.0.0/24 | 192.0.2.10 |
ஃபயர்வால் A 10.30.0.0/24-ஐ சேவை செய்கிறது, ஃபயர்வால் B 10.40.0.0/24-ஐ, இரண்டு டிரான்சிட் முகவரிகளும் 192.0.2.0/24-இல் உள்ளன. ஒவ்வொரு LAN ஹோஸ்டும் தனது உள்ளூர் ஃபயர்வாலை நுழைவாயிலாக வைத்திருக்கிறது, எனவே புதிய நிலை ஒவ்வொரு பக்கத்திலும் ஒரு வழி மட்டுமே. Linux அடிப்படையிலான ஃபயர்வாலில் அதே திட்டம் இப்படித் தெரிகிறது, மேலும் முன்னனுப்பல் இயக்கப்பட்டிருக்க வேண்டும், இல்லையேல் வழி தீர்க்கப்படும் ஆனால் பாக்கெட் நிராகரிக்கப்படும்.
sysctl -w net.ipv4.ip_forward=1 ip route add 10.40.0.0/24 via 192.0.2.20 dev eth1 ip route get 10.40.0.15 traceroute -n 10.40.0.15
வடிகட்டலை மொழிபெயர்ப்பிலிருந்து தனியாக வைத்திருங்கள்
வழிமாற்றமும் கொள்கையும் வெவ்வேறு கட்டுப்பாடுகள், இரண்டாவதில்தான் பெரும்பாலான வழிமாற்ற வடிவமைப்புகள் உண்மையில் தோல்வியடைகின்றன. பாக்கெட்டுகள் உண்மையில் கடக்கும் நுழைவு எல்லையில் குறிப்பிட்ட மூலங்கள், இலக்குகள் மற்றும் சேவைகளை அனுமதிக்கவும், WAN போன்ற இடைமுக லேபிள் ஒரு பெயர் மட்டுமே, நம்பிக்கை பற்றிய அறிக்கை அல்ல என்பதை நினைவில் கொள்ளுங்கள். தனியார் டிராஃபிக்கை எடுத்துச் செல்லும் டிரான்சிட் துறைமுகத்தில் தனியார் முகவரி தடுப்பு இன்னும் இயல்பாக இயக்கப்பட்டிருக்கலாம்.
பின்னர் NAT நடக்கவில்லை என்று முடிவெடுக்கும் முன் வெளிச்செல்லும் மொழிபெயர்ப்பைப் பாருங்கள். தானியங்கி வெளிச்செல்லும் விதிகள் ஒருபோதும் மொழிபெயர்ப்புக்கு உத்தேசிக்காத டிராஃபிக்கை மீண்டும் எழுதக்கூடும், அது மறுபக்கத்திற்கு அதன் சொந்தக் கொள்கை மற்றும் பதிவுகளுக்குத் தேவையான மூல முகவரிகளை அழிக்கிறது. தேர்ந்தெடுத்த ஓட்டங்கள் அவற்றின் அசல் முகவரிகளைத் தக்கவைப்பதை உறுதிசெய்யுங்கள், இன்னும் தேவைப்படும் டிராஃபிக்கிற்கு இணைய மொழிபெயர்ப்பு விதிகளை அப்படியே விடுங்கள்.
iptables -t nat -S POSTROUTING iptables -t nat -L POSTROUTING -n -v tcpdump -ni eth1 -c 5 host 10.40.0.15
NAT நேர்மையான பதிலாக இருக்கும்போது
முகவரி வரம்புகள் உண்மையில் மேலெழும்போது மற்றும் மறுஎண்ணிடல் கிடைக்காதபோது, அல்லது ஒரு பக்கம் துணைவலையமைப்புக்குப் பதிலாக ஒரே முகவரியைப் பார்க்க வேண்டும் என்று கொள்கை கோரும்போது மொழிபெயர்ப்பு அதன் இடத்தைப் பெறுகிறது. அத்தகைய சந்தர்ப்பங்களில் வேண்டுமென்றே செய்யப்படும் ஒன்றுக்கு-ஒன்று அல்லது துறைமுகம்-வரம்புடைய மேப்பிங் அறியப்பட்ட விளைவுகளைக் கொண்ட வடிவமைப்பு முடிவு, வேலையை நடத்துவதற்கான வழி அல்ல.
உரக்கச் சொல்ல வேண்டிய விளைவு என்னவென்றால், மறுபக்கத்தால் இனி தனிப்பட்ட மூலங்களைப் பார்க்கவோ வடிகட்டவோ முடியாது. பதிவுகள் மொழிபெயர்க்கும் முகவரியில் சுருங்குகின்றன, ஒவ்வொரு ஹோஸ்டுக்குமான கொள்கை வேலை செய்வதை நிறுத்துகிறது, சிக்கல் தீர்த்தல் என்பது ஒரு குறிப்பிட்ட தருணத்தில் எந்த உள் ஹோஸ்ட் ஒரு ஓட்டத்தைக் கொண்டிருந்தது என்பதைத் தேடுவதாக மாறுகிறது. கேள்விக்குரிய டிராஃபிக்கிற்கு இவற்றில் எதுவும் முக்கியமில்லை என்றால், NAT சரி.
டிரான்சிட் தானே தவறான அனுமானமாக இருக்கும்போது
பகிரப்பட்ட பிரிவு ஒரு வழங்குநர், பகிரப்பட்ட சுவிட்ச் துணி அல்லது மற்றொரு தரப்பு டிராஃபிக்கைப் படிக்கக்கூடிய எந்தப் பாதையையும் கடந்தால், வழிமாற்றம் மட்டும் முழுமையான பதில் அல்ல. இரண்டு ஃபயர்வால்களுக்கு இடையேயான சுரங்கப்பாதை உங்களுக்கு இரகசியத்தன்மையையும் சக உறுதிப்படுத்தலையும் தருகிறது, அதன் உள்ளேயுள்ள வழி அட்டவணை நீங்கள் டிரான்சிட்டில் எழுதியிருக்கும் அதே அட்டவணை.
இதை முதல் பகுதியின் நம்பிக்கைக் கேள்வியிலிருந்து தீர்மானியுங்கள், VPN மிகவும் பாதுகாப்பானவை என்ற பழக்கத்திலிருந்து அல்ல. ஏற்கனவே தனியாரான பிரிவின் மேல் ஒரு சுரங்கப்பாதை எந்தப் பயனும் இல்லாமல் இயக்கச் செலவையும் மற்றொரு தோல்வி முறையையும் சேர்க்கிறது, நம்பமுடியாத பிரிவின் மேல் வழிமாற்றம் இரகசியத்தன்மையை நீங்கள் தாங்க முடியாத எளிமைக்கு மாற்றுகிறது. மூன்று நிபந்தனைகளில் எது தேர்வை வழிநடத்தியது என்று எழுதி வைக்கவும், அடுத்த பொறியாளர் அதை மீண்டும் விவாதிக்க வேண்டியதில்லை.