அழைப்புகளைத் துண்டிக்காமல் ISP ரவுட்டருக்கு அருகில் தள VPN சேர்க்கவும்

பெரும்பாலான சிறிய தளங்களில் ஏற்கனவே இணையம், DHCP மற்றும் குரல் இணைப்பைச் செய்யும் ஒரு சாதனம் உள்ளது, அது உங்கள் தளத்தின் சுரங்கப்பாதையை இயக்காது. தனிப்பட்ட பாதைக்கு இரண்டாவது கேட்வே சேர்ப்பது, கேபிளைத் தொடும் முன் எந்தப் பாதை யாருடையது என்பதை முடிவு செய்தால் வேலை செய்யும். உண்மையான ஆபத்து சுரங்கப்பாதை அல்ல; தொலைபேசிகள் பதிவில் இருக்க வைக்கும் சாதனத்தை அமைதியாக மாற்றுவதுதான். ஐந்து சோதனைகளையும் வரிசையாகச் செய்து ஒன்று தோல்வியடையும் இடத்தில் நிறுத்துங்கள்.

ஏற்கனவே வேலை செய்யும் பங்குகளை எழுதுங்கள்

இயல்புநிலை கேட்வே, DHCP சேவையகம், பெயர் தீர்வான் மற்றும் வழங்குநரின் குரல் பதிவு உள்ள சாதனத்தைப் பதிவு செய்யுங்கள். இந்த எடுத்துக்காட்டில் ISP ரவுட்டர் 10.50.0.1, புதிய கேட்வே 10.50.0.2 ஆக இருக்கும், தொலை தளம் 10.60.0.0/24. அந்தத் திட்டத்தில் எதுவும் முதல் மூன்று பங்குகளை மாற்றாது, அதுதான் முக்கிய அம்சம். பின்னர் இரண்டாவது சாதனம் சுரங்கப்பாதையை உண்மையில் முடிக்க முடியுமா என்பதை உறுதிப்படுத்துங்கள்: நெறிமுறை, எதிர்பார்க்கப்படும் செயல்திறன் மற்றும் ஃபேர்ம்வேர் அல்லது தொகுப்பு புதுப்பிப்புகள் கிடைக்கின்றனவா என்பதைப் பாருங்கள். VPN சின்னம் உள்ளதும் புதுப்பிப்புப் பாதை இல்லாததுமான சாதனம் கூடுதலல்ல, சுமை.

குரல் சேவை யாருடையது என்று சொல்ல முடியாவிட்டால் நிறுத்துங்கள். பதிவு உள்ள ரவுட்டரை மீள்வழி திட்டம் இல்லாமல் மாற்றுவது VPN திட்டத்தைத் தொலைபேசி தடையாக மாற்றும்.

புதிய கேட்வேக்கு ஒரு முகவரியும் ஒரு பணியும் கொடுங்கள்

அதன் LAN முகவரியை DHCP குளத்திற்கு வெளியே ஒதுக்குங்கள், மறுதொடக்கத்திற்குப் பிறகு அது நகராதிருக்க, மேலும் இணையப் பாதையாக்க விரும்பவில்லை என்றால் அதற்கு சொந்த இயல்புநிலை பாதையைக் கொடுக்காதீர்கள். அதன் பணி சுரங்கப்பாதையை வைத்திருப்பதும் தொலை முன்னொட்டுகளுக்குப் பதிலளிப்பதும். தொலை தளத்தை அடைய வேண்டிய LAN புரவலர்களில் அவை இப்போது எந்தப் பாதையை எடுக்கின்றன, மாற்றத்திற்குப் பிறகு எதை விரும்புகிறீர்கள் என்பதை நிரூபியுங்கள்; அதே இரண்டு கட்டளைகள் முன்னும் பின்னும் மிக மலிவான சான்று.

ip route get 10.60.0.55
ip neigh show 10.50.0.2
traceroute -n 10.60.0.55

தேடல் ISP ரவுட்டரைத் திருப்பித் தந்து traceroute இணையத்தின் விளிம்பில் இறந்தால், புரவலருக்கு இன்னும் தொலை பாதை இல்லை, இது எதிர்பார்க்கப்படுவது. எதிர்பாராத ஒன்று வந்தால், முதலில் அதைத் தீருங்கள், ஏனெனில் அடுத்த ஒவ்வொரு படியும் இந்த அடித்தளத்தைக் கருதுகிறது.

தொலை முன்னொட்டின் பாதை யாருடையது என்பதைத் தேர்ந்தெடுங்கள்

A விருப்பம் ISP ரவுட்டர்: 10.60.0.0/24 க்கு கேட்வே நோக்கி நிலையான பாதையை வைத்திருக்கிறது, ஒவ்வொரு புரவலரும் முன்புபோல் தன் இயல்புநிலை கேட்வேயைப் பின்பற்றுகிறது. B விருப்பம் புரவலர் வாரியாக: தொலை தளம் தேவைப்படும் இயந்திரங்கள் மட்டுமே 10.50.0.2 வழியாக வெளிப்படையான பாதையைப் பெறுகின்றன, மற்ற அனைத்தும் தொடப்படாமல் இருக்கும். A பல புரவலர்களுக்கு தூய்மையானது, ஆனால் பொதுவாக வழங்குநரின் ரவுட்டர் நிலையான பாதையை ஏற்க வேண்டும், சிலர் அதைச் செய்வதில்லை. B க்கு வழங்குநர் ஒத்துழைப்பு தேவையில்லை, ஆனால் புரவலர் அமைப்பின் பராமரிப்பை உங்களிடம் விட்டுவிடுகிறது, எனவே அனுமதிக்கப்பட்ட சிறிய இயந்திரத் தொகுப்புக்கு ஏற்றது.

இரண்டு நிலைகளிலும் திரும்பும் திசை இருக்க வேண்டும். தொலை பதில் கேட்வேக்கு வந்து கேட்வே அதை நேரடியாக LAN புரவலருக்கு அனுப்பினால், போக்குவரத்து ISP ரவுட்டர் வெளிச்செல்லும் பாதையில் வைத்திருந்த ஃபயர்வால் நிலையைத் தவிர்க்கிறது. கேட்வே LAN இன் இயல்புநிலை ரவுட்டர் இல்லையெனில், அந்த சமச்சீரின்மை ஒரு வடிவமைப்பு முடிவு, புறக்கணிக்கக்கூடிய தவறு அல்ல.

ip route add 10.60.0.0/24 via 10.50.0.2 dev eth0
ip route get 10.60.0.55 from 10.50.0.77

பதிவை புரவலரின் அமைப்பு உரிமையாளர் வழியாக நிரந்தரமாக்குங்கள், உள்நுழைவு ஸ்கிரிப்ட் வழியாக அல்ல. யாரோ உள்நுழைந்த பிறகு மட்டுமே இருக்கும் பாதை, இயந்திரம் தொடர்பில்லாத காரணத்தால் மறுதொடக்கம் ஆகும்போது முதல் முறையாகத் தோல்வியடையும்.

அணுகக்கூடிய உள்வரும் முனையை ஏற்பாடு செய்யுங்கள்

கேட்வேக்கு தொலை தளம் அடையக்கூடிய முகவரி தேவை. ISP ரவுட்டருக்குப் பின்னால் அதற்கு போர்ட் மறுவழிப்படுத்தல் அல்லது DMZ பதிவு தேவை, இரண்டும் வழங்குநர் போக்குவரத்தை உண்மையில் வழங்குகிறாரா என்பதைப் பொறுத்தது. உள்ளூர் மறுவழிப்படுத்தல் வழங்குநர் பக்கத்தின் கேரியர் நிலை NAT ஐ வெல்ல முடியாது. வழங்குநர் அணுகக்கூடிய புள்ளியைக் கொடுக்கவில்லை என்றால், திசையைத் திருப்புங்கள்: இரு தளங்களும் நீங்கள் கட்டுப்படுத்தும் மையத்தை நோக்கித் தொடங்கட்டும். இது செல்லுபடியாகும் வடிவமைப்பு, ஆனால் மறுவழிப்படுத்தல், நம்பிக்கை மற்றும் கிடைக்கும் தன்மைக்கு மூன்றாவது சார்பைச் சேர்க்கிறது, மேலும் மாறும் DNS அதை மாற்றாது.

மறுவழிப்படுத்தலை கேட்வேயில் பிடிப்பதன் மூலம் உறுதிப்படுத்துங்கள், போர்ட்டுகளை ஸ்கேன் செய்யும் வலைத்தளத்தால் அல்ல. ஸ்கேனர்கள் கேட்பவர் பிணைக்கப்படும் வரை போர்ட்டை மூடியதாகத் தெரிவிக்கின்றன, ஒருபோதும் போக்குவரத்தை வழங்காத மறுவழிப்படுத்தல் வெளியிலிருந்து மூடிய போர்ட் போலவே தெரிகிறது.

தனிப்பட்ட சேவையையும் குரல் இணைப்பையும் ஒன்றாக ஏற்றுக்கொள்ளுங்கள்

LAN புரவலரிலிருந்து நோக்கமான செயல்பாட்டைச் சோதியுங்கள், தனிப்பட்ட DNS மற்றும் பயன்பாட்டின் சொந்தச் சான்றுகளுடன். வழியமைக்கப்பட்ட சுரங்கப்பாதை தொலை உலாவலை உள்ளூர் ஈதர்நெட் பகுதி போலாக்காது, எனவே கண்டறிதல் மற்றும் பெயர் தீர்வுக்கு தனி ஏற்பாடுகள் தேவை.

curl -sS -o /dev/null -w '%{http_code}\n' https://files.example.net
ping -c 3 10.60.0.55

பின்னர் அதே புரவலரிலிருந்து சாதாரண இணைய அணுகல் இன்னும் வேலை செய்கிறது என்பதையும் தொலைபேசிகள் இன்னும் பதிவில் உள்ளன என்பதையும் உறுதிப்படுத்துங்கள்; அந்த இரண்டு சோதனைகள் இயல்புநிலை பாதையின் தற்செயலான மாற்றத்தைப் பிடிக்கின்றன, இந்தத் திட்டம் தொட விரும்பாத ஒன்றை உடைக்கும் மிகவும் பொதுவான வழி அதுதான். எழுதப்பட்ட மீட்புக் குறிப்புடன் முடியுங்கள்: எந்தச் சாதனம் எந்தப் பங்கை வைத்திருக்கிறது, ஒதுக்கப்பட்ட முகவரிகள், தொலை முன்னொட்டின் பாதையை ஒரே படியில் எப்படி நீக்குவது. தூய்மையாகத் திரும்பப் பெறக்கூடிய தனிப்பட்ட பாதை இன்று மட்டும் வேலை செய்வதை விட மதிப்புமிக்கது.