உங்கள் பொது Linux சேவை VPN வழியாக ஏன் பதிலளிக்கிறது

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

தவறான கருத்து: பதில்கள் அவை வந்த இடைமுகத்தைப் பின்பற்றுகின்றன

eth0 இல் வரும் பாக்கெட் eth0 வழியாகவே செல்ல வேண்டும் என்பது தர்க்கரீதியாகத் தோன்றுகிறது. நிலையற்ற பாக்கெட் வடிகட்டிகள் அவ்வாறு எழுதப்படலாம், மேலும் உள்வரும் பக்கத்தில் tcpdump கோரிக்கையை எதிர்பார்க்கும் இடத்திலேயே காட்டுகிறது. ஹோஸ்ட் தானே உருவாக்கும் போக்குவரத்துக்கு வழிநடத்தல் அவ்வாறு இயங்குவதில்லை.

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

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

கர்னல் உண்மையில் எதை வழிநடத்துகிறது: மூல முகவரி

உங்களுக்குத் தேவையான பிடி என்பது சேவை பதில்களுக்குப் பயன்படுத்தும் உள்ளூர் முகவரி. eth0 முகவரி எடுத்துக்காட்டாக 192.0.2.10/24 மற்றும் நுழைவாயில் 192.0.2.1 உள்ள ஹோஸ்ட்டில் அந்த முகவரி இடைமுகத்தில் உள்ளது. கிளவுட் VM இல் பொது முகவரி மேலே மொழிபெயர்க்கப்பட்டு விருந்தினரிடம் இல்லாமல் இருக்கலாம், எனவே ஹோஸ்ட் உண்மையில் வைத்திருக்கும் முகவரியைப் பயன்படுத்துங்கள்.

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

ip -4 addr show dev eth0
ip -4 rule show
ip -4 route show table all

பின்னர் மூலத்தின் அடிப்படையில் அட்டவணையைத் தேர்ந்தெடுங்கள். விதி ஏற்கனவே 192.0.2.10 ஐக் கொண்டுள்ள பதில்களுடன் பொருந்துகிறது, அதாவது நீங்கள் விலக்க விரும்பும் உள்ளூரில் முடிந்த போக்குவரத்து. முன்னனுப்பப்பட்ட போக்குவரத்தும் பிற உள்ளூர் முகவரிகளின் பாக்கெட்டுகளும் பொருந்தாது.

அரை இயல்புநிலை அல்ல, முழுமையான திரும்பு அட்டவணையை உருவாக்குங்கள்

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

ip -4 route add table 100 192.0.2.0/24 dev eth0 src 192.0.2.10
ip -4 route add table 100 default via 192.0.2.1 dev eth0
ip -4 rule add priority 1000 from 192.0.2.10/32 lookup 100

எடுத்துக்காட்டை நகலெடுப்பதற்குப் பதிலாக உண்மையான முன்னொட்டையும் நுழைவாயிலையும் பயன்படுத்துங்கள். on-link நுழைவாயிலுடன் /32 ஆக கட்டமைக்கப்பட்ட கிளவுட் இடைமுகத்திற்கு வேறு இணைக்கப்பட்ட பாதை தேவை, தவறான முன்னொட்டிலிருந்து கட்டப்பட்ட அட்டவணை முதல் தாவலிலேயே தோல்வியடையும். src பண்பு அந்தப் பாதைக்கான விருப்பமான மூலத்தைக் குறிப்பிடுகிறது; அது மூல விதியை மாற்றாது.

வரிசையும் முக்கியம். குறைந்த முன்னுரிமை எண் கொண்ட பரந்த விதி முதலில் மதிப்பிடப்படுகிறது, எனவே இந்தப் போக்குவரத்தை முதன்மை அட்டவணைக்குத் திருப்பி அனுப்பக்கூடிய எந்த விதிக்கும் முன் மூல விதியை அடைய வேண்டும். சேர்த்த பிறகு ip rule show மூலம் முன்னுரிமைகளைச் சரிபார்க்கவும், துவக்கத்தில் மட்டுமல்ல.

மூலத்தால் தகுதிப்படுத்தப்பட்ட தேடலுடன் சரிபார்க்கவும்

சேவை முகவரியிலிருந்து சோதனை இலக்கிற்கு வழிநடத்தக் கர்னலைக் கேளுங்கள். பதிலில் சுரங்கம் அல்ல, eth0 மற்றும் WAN நுழைவாயிலைக் குறிப்பிட வேண்டும்:

ip -4 route get 198.51.100.25 from 192.0.2.10

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

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

இந்த விதிவிலக்கு எங்கு நிற்கிறது

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

ஹோஸ்ட்டின் பொது முகவரியை இடைமுகத்தில் காட்டவும் இது செய்யாது. மேலுள்ள NAT அந்த முகவரியைச் சொந்தமாகக் கொள்ளும்போது, அந்த NAT எதிர்பார்க்கும் பாதை வழியாகவே பதில் வெளியேற வேண்டும், அதனால்தான் WAN அட்டவணை ஊகிக்கப்பட்ட பொது வரம்புக்குப் பதிலாக அசல் நுழைவாயிலையும் முன்னொட்டையும் பிரதிபலிக்க வேண்டும்.

விதிவிலக்கை அதன் அட்டவணை எண், விதி முன்னுரிமை மற்றும் சரியான மூல முகவரியுடன் ஆவணப்படுத்தி வையுங்கள். VPN அல்லது இடைமுகத்தில் அடுத்த மாற்றம் அதை அமைதியாக உடைக்கக்கூடும், மூன்று மதிப்புகளைக் குறிப்பிடும் குறிப்பு வாடிக்கையாளர் அறிக்கையிலிருந்து அறிகுறியை மீண்டும் கண்டுபிடிப்பதை விட வேகமாகச் சரிபார்க்கப்படும்.

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