WireGuard வழியாக மட்டும் இயங்கும் HTTPS சேவைக்கான loopback இல் Dante SOCKS

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

எடுத்துக்காட்டு Dante 1.4.x நம்பகமான Linux பணிநிலையத்தில் தனி, நிர்வகிக்கப்பட்ட நிகழ்வாக நிறுவப்பட்டுள்ளது என்றும், தொகுப்பு வழங்கும் சேவைக் கணக்கும் பதிவு கட்டமைப்பும் அவற்றின் இடத்திலேயே விடப்பட்டுள்ளன என்றும் கருதுகிறது. பணிநிலையம் 10.77.0.2 ஐ அதன் WireGuard இடைமுகத்தில் வைத்திருக்கிறது, அந்தச் சுரங்கத்தின் வழியாக 10.60.0.20:443 ஐ அடைகிறது, சேவையின் சரியான பெயர் app.corp.example ஆகும்.

படி 1: கேட்பியை loopback உடன் மட்டும் பிணைக்கவும்

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

internal: 127.0.0.1 port = 1080
external: 10.77.0.2
external.protocol: ipv4
clientmethod: none
socksmethod: none

client pass {
    from: 127.0.0.1/32 to: 127.0.0.1/32
}

socks pass {
    from: 127.0.0.1/32 to: 10.60.0.20/32 port = 443
    command: connect
    protocol: tcp
}

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

இந்தப் படியின் பின்னடைவு நிகழ்வை நிறுத்துவதாகும்; நீங்கள் அதைத் திருப்பித் தரும்போது கட்டமைப்புக் கோப்பு வட்டில் இருக்கலாம்.

படி 2: ஒன்றல்ல, இரண்டு விதிகளை எழுதுங்கள்

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

இந்தக் கட்டமைப்பு வேண்டுமென்றே செய்யாததைக் கவனியுங்கள்: அது SOCKS கடவுச்சொல்லைக் கேட்கவில்லை. அது நம்பகமான உள்ளூர் ஹோஸ்டுக்குப் பொருந்தும், அது பயனர் அங்கீகாரம் அல்ல. அந்த இயந்திரத்தில் உள்ள வேறு எந்தச் செயல்முறையும் loopback ஐப் பயன்படுத்தலாம். தொலை பயன்பாட்டின் சொந்த அங்கீகாரத்தை அதன் இடத்தில் வைத்திருங்கள், இந்த அங்கீகாரமற்ற வடிவத்தை நம்பமுடியாத உள்ளூர் பயனர்களுக்கோ LAN நோக்கிய கேட்பிக்கோ மீண்டும் பயன்படுத்த வேண்டாம்.

படி 3: சரியான மூலத்திலிருந்து பாதையைச் சரிபார்க்கவும்

external வெளியேறும் மூல முகவரியைத் தேர்ந்தெடுக்கிறது; அது WireGuard பாதையை நிறுவவில்லை. எடுத்துக்காட்டு மூலம் மற்றும் இலக்குக்கான படிப்பு-மட்டும் தேடல்:

ip -4 route get 10.60.0.20 from 10.77.0.2

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

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

படி 4: எண்ணிய அடையாளத்துடன் சோதியுங்கள்

உரிமையாளர் நிறுவப்பட்ட கட்டமைப்பைச் சரிபார்த்து சேவை மேலாளர் வழியாக நிகழ்வைத் தொடங்கிய பிறகு, ஒரு எடுத்துக்காட்டுக் கோரிக்கை இதுவாகும்:

curl --proxy socks5h://127.0.0.1:1080 --noproxy '' https://app.corp.example/

உடன் socks5h, Dante இலக்குத் தீர்வைச் செய்கிறது, ஆனால் Dante இந்தப் பணிநிலையத்தில் இயங்குகிறது, எனவே அமைப்பு தானாகவே DNS ஐ சுரங்கத்தின் தொலை முனைக்கு அனுப்பவில்லை. Dante பயன்படுத்தும் அங்கீகரிக்கப்பட்ட தீர்வான் அந்தப் பெயருக்கு அனுமதிக்கப்பட்ட முகவரியைத் திருப்பித் தர வேண்டும். காலியான no-proxy பட்டியல் மரபுவழி விலக்கு ஒன்று SOCKS ஐ அமைதியாகத் தவிர்ப்பதைத் தடுக்கிறது.

சோதனையில் HTTPS ஹோஸ்ட்பெயர் மற்றும் சான்றிதழ் சரிபார்ப்பைப் பேணுங்கள், பின்னர் உண்மையான கேட்பியை ஆய்வு செய்து ஒப்பந்தத்தின் இரு பகுதிகளையும் உறுதிசெய்யுங்கள்: அனுமதிக்கப்பட்ட கோரிக்கை வெற்றிபெறுகிறது, விலக்கப்பட்ட இலக்கு தோல்வியடைகிறது. ஆதரவில்லாத அனுப்பும் கட்டளைகள் மறுக்கப்பட்டே இருக்கின்றன என்பதையும் சரிபாருங்கள், ஏனெனில் இந்தத் துண்டு TCP மீது SOCKS CONNECT கட்டளைக்கு மட்டுமே அனுமதி தருகிறது, பொதுவான UDP அல்லது முழு சாதனச் சுரங்கம் போன்ற எதற்கும் அல்ல.

படி 5: சுரங்கம் விழும்போது என்ன நடக்கும் என்பதை முடிவு செய்யுங்கள்

இதை உற்பத்தி என்று அழைப்பதற்கு முன் சுரங்க-இழப்பு மற்றும் நிகழ்வு மறுதொடக்கத்தைச் சோதியுங்கள். WireGuard க்குப் பிறகு Dante ஐத் தொடங்கும் மேற்பார்வையாளர் fail-closed வழிசெலுத்தலையும் fail-closed DNS ஐயும் உருவாக்குவதில்லை; இரண்டும் வலைப்பின்னல் உரிமையாளர் வழியாக நடைமுறைப்படுத்தப்பட வேண்டும். சுரங்கம் செயலிழந்திருக்கும்போது பயன்பாடு என்ன செய்கிறது என்பதைக் கவனியுங்கள்: தெளிவான பிழை நல்ல முடிவு, பொது தீர்வானுக்கு அமைதியாக வீழ்வது அல்ல.

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