தளத்திலிருந்து தளம் VPN-இன் பதில் சுரங்கப்பாதை வழியாகச் செல்லவில்லை
சுரங்கப்பாதையைத் தவிர்க்கும் பதில் தொலைப் பக்கத்தின் வழித்தட முடிவு. புரவலன் அட்டவணை, தேர்விகள் மற்றும் rp_filter சரிபார்த்து, பின்னர் வழித்தடம் அல்லது NAT தேர்ந்தெடுக்கவும்.
ஒரு காலையை நான் செலவழித்தது, தூய்மையாக எழுந்து போக்குவரத்தை சரியாக ஒரு திசையில் மட்டும் நகர்த்திய ஒரு சுரங்கப்பாதையுடன்தான்: கிளை தலைமையகத்தின் கோப்பு சேவையகத்தை அடைய முடிந்தது, தலைமையகத்திலிருந்து கிளைக்குத் திறக்கப்படும் ஒவ்வொரு இணைப்பும் முதல் SYN-இலேயே இறந்தது. SA-க்கள் செயலில் இருந்தன, சுரங்கப்பாதையின் கணக்குகள் உயர்ந்தன, கைக்குலுக்கல் ஒருபோதும் பிரச்சினையாக இருந்ததில்லை. பதில் சுரங்கப்பாதை மூடாத இடத்திற்குத் திசைவிக்கப்பட்டது, அந்தத் தேர்வு தொலைப் பக்கத்திற்கு உரியது. தளத்திலிருந்து தளம் VPN, புரவலன் நுழைவாயிலுக்கு அளிக்கும் பொதிகளை மட்டுமே எடுத்துச் செல்கிறது, ஒவ்வொரு புரவலனும் அந்தத் தேர்வைத் தனித்தனியாக, ஒவ்வொரு திசையிலும், தன் சொந்த வழித்தட அட்டவணையிலிருந்து செய்கிறது.
இரு திசைகளும் தனித்தனியாகத் திசைவிக்கப்படுகின்றன
IP உரையாடலின் திசையை நினைவில் வைத்துக்கொள்ளாது. பொதியை அனுப்பும் ஒவ்வொரு புரவலனும் தன் சொந்த நீளமான முன்னொட்டுத் தேடலை இயக்கி, ஒரு அடுத்த தாவலைத் தேர்ந்தெடுத்து முடிவை மறந்துவிடுகிறது. கோரிக்கையும் பதிலும் ஒரே இணைப்பைச் சேர்ந்தவையாக தற்செயலாக அமைந்த இரண்டு தொடர்பற்ற பொதிகள், சுரங்கப்பாதை என்பது அவற்றில் எதுவும் பயன்படுத்தக்கூடிய அல்லது பயன்படுத்தாத ஒரு தாவல். IKE பரிமாற்றத்தில் எதுவும் தொலைச் சேவையகத்திற்கு உங்கள் துணைப்பிணையத்தை அடையும் வழியைக் கற்பிக்கவில்லை; பேச்சுவார்த்தை எந்த முன்னொட்டுகளை மறையாக்கலாம் என்பதில் மட்டுமே ஒப்புக்கொள்கிறது.
அந்த ஒப்பந்தமே இரண்டாவது வாயில். strongSwan-இல் போக்குவரத்துத் தேர்விகள் leftsubnet மற்றும் rightsubnet, ஒப்புக்கொள்ளப்பட்ட இணையின் வெளியே மூலமோ இலக்கோ விழும் பொதி மறையாக்கப்படாது, வழித்தட அட்டவணை எதைச் சொன்னாலும். சுரங்கப்பாதைக்குத் திசைவிக்கப்பட்டு ஆனால் தேர்விகளில் இல்லாத முன்னொட்டு ஒரு அமைதியான ஒருதிசைத் தோல்வி: வழித்தடம் சரியாகத் தெரிகிறது, பொதி இன்னும் வெளிப்படையாகவே வெளியேறுகிறது அல்லது தூக்கி எறியப்படுகிறது, charon பதிவு மட்டுமே புகார் செய்கிறது.
தொலைப் புரவலனுக்கு உங்கள் சுரங்கப்பாதை பற்றி எதுவும் தெரியாது
தொலை LAN-க்குள் பதில் உங்கள் வாடிக்கையாளருக்கு அனுப்பப்பட்ட சாதாரண பொதி. இலக்குப் புரவலனுக்கு எந்த IPsec தலைப்பும் தெரியாது, VPN நுழைவாயிலுக்கு முன்னுரிமை அளிக்க எந்தக் காரணமும் இல்லை; உங்கள் முன்னொட்டைத் தேடி, தன் இயல்புநிலை வழித்தடத்தை விட குறிப்பான எதையும் காணாமல் அதையே பின்பற்றுகிறது. இயல்புநிலை ஒரு முதன்மை நெருப்புச் சுவரை நோக்கினால், அந்தச் சுவருக்கு சுரங்கப்பாதைக்குத் திரும்பும் வழித்தடம் உண்டு அல்லது இல்லை. இல்லாவிட்டால் அமைதியான வீழ்ச்சி, ICMP unreachable, அல்லது இணையம் நோக்கிய இடைமுகத்திலிருந்து வெளியேறி இறக்கும் பதில் கிடைக்கும்.
வழித்தடம் இருந்தாலும் இரண்டாவது இடைமுகம் இதை உடைக்கப் போதும். மற்ற VLAN-இல் நிர்வாக இணைப்பு உள்ள NAS, காப்பு uplink உள்ள சேவையகம், ஒரு மூல வரம்பை இரண்டாவது அட்டவணைக்கு அனுப்பும் கொள்கை விதி: இவற்றில் எதுவும் பதிலைப் பிடிக்கலாம். Linux-இல், ip rule show மற்றும் ip route show table all இயல்புநிலைப் பட்டியல் மறைக்கும் விதிகளையும் அட்டவணைகளையும் காட்டுகின்றன.
பதிலை அனுப்பும் இயந்திரத்திலேயே முடிவைப் படியுங்கள்
எதையும் மாற்றும் முன் கர்னலிடம் கேளுங்கள், மூல முகவரியைக் கொடுங்கள், ஏனெனில் மூலத்தைச் சார்ந்த விதிகள் பதிலை மாற்றுகின்றன.
ip route get 10.10.5.10 from 10.20.30.15
ip rule show
ip route show table all
ss -tn state established "( sport = :445 )"வெளியீடு வெளியேறும் இடைமுகத்தையும் அடுத்த தாவலையும் குறிப்பிடுகிறது. இடைமுகம் VPN நுழைவாயிலை நோக்கியது இல்லையென்றால், குறையைக் கண்டுபிடித்தீர்கள், மீதமுள்ள வேலை வழித்தடம் எங்கே இருக்க வேண்டும் என்பதைத் தேர்ந்தெடுப்பதுதான். நுழைவாயிலிலிருந்து செய்யும் ping இங்கே குறைவாகவே நிரூபிக்கிறது: தொலைப் புரவலன் வைக்கக்கூடிய முகவரியுடன் பதிலளிக்கிறது, உங்கள் மடிக்கணினியின் முகவரியுடன் அல்ல.
Windows-இல் சமமானவை முடிவுக்கு Find-NetRoute -RemoteIPAddress 10.10.5.10, அட்டவணைக்கு Get-NetRoute. இயல்புநிலையை விட அதிக அளவீடு கொண்ட New-NetRoute மூலம் சேர்க்கப்பட்ட வழித்தடம் அமைதியாகத் தோற்கிறது, எனவே அளவீட்டு நிரலைப் படியுங்கள், உள்ளீட்டை அல்ல. பிறகு பொதிகளால் உறுதிப்படுத்துங்கள்: தொலை LAN இடைமுகத்தில் tcpdump -ni any "host 10.10.5.10 and tcp port 445" கோரிக்கையைக் காட்டுகிறது, சுரங்கப்பாதைப் பக்கத்தில் அதே வடிகட்டி பதில் திரும்பியதா என்பதைக் காட்டுகிறது. கோரிக்கை தெரிகிறது ஆனால் பதில் இல்லை என்பது பதில் வேறெங்கோ திசைவிக்கப்பட்டது அல்லது தூக்கி எறியப்பட்டது என்பதாகும்; தவறான இடைமுகத்தில் வரும் பதில் வழித்தடத்தைத் தொடும் முன்பே குற்றவாளியைத் தரும்.
சேவையகத்தின் நுழைவாயில் VPN முனைப்புள்ளியாக இல்லாதபோது
பல தளங்கள் சேவையகங்களுக்கும் ஒருங்கிணைப்புக் கருவிக்கும் இடையே நெருப்புச் சுவர் வைக்கின்றன. அந்தச் சுவர் பதிலை முன்னோக்கி அனுப்புகிறது, எனவே உங்கள் வாடிக்கையாளர் முன்னொட்டுக்கு VPN நுழைவாயிலை நோக்கிய வழித்தடமும், இரு திசைகளிலும் அனுப்பும் கொள்கையும் அதற்குத் தேவை. நிலை வைத்திருக்கும் கருவிகள் இதை மோசமாக்குகின்றன: கோரிக்கை தான் அனுமதித்த LAN புரவலனிடமிருந்து நெருப்புச் சுவரைக் கடந்தது, பதில் இப்போது வேறு திசையிலிருந்து வருகிறது, இணைப்புக் கண்காணிப்பு உள்ளீடு இனி பொருந்தவில்லை, எனவே பொதி மறுக்கப்படுவதற்குப் பதிலாக செல்லாததாகத் தூக்கி எறியப்படுகிறது. போக்குவரத்து மறையும்போது கொள்கைப் பதிவு காலியாகத் தெரிவதற்குக் காரணம் இதுவே.
நுழைவாயிலுக்கு அதன் சொந்த இரண்டாவது வடிகட்டி உண்டு. Linux-இன் தலைகீழ் பாதை வடிகட்டல், அவை வந்த இடைமுகம் வழியாக மூலத்தை அடைய முடியாத பொதிகளைத் தூக்கி எறிகிறது, அது சட்டபூர்வமான சமச்சீரற்ற திரும்பும் பாதையின் சரியான வடிவம். strongSwan-இன் அனுப்புதல் வழிகாட்டி அதே காரணத்திற்காகவே net.ipv4.ip_forward மற்றும் தளர்த்தப்பட்ட net.ipv4.conf.all.rp_filter கோருகிறது. எந்த நுழைவாயிலிலும் கடுமையான மதிப்பு 1 சரியான வழித்தடத்தை அமைதியாக உடைக்கிறது, எங்கே பார்ப்பது என்று தெரிந்தால் nstat -az வீழ்ச்சிகளைக் காட்டுகிறது.
| Symptom | Where the reply is most likely lost |
|---|---|
| Gateway ping works, LAN host silent | Source address the far host cannot place in its table |
| SYN arrives, no SYN-ACK, tunnel counters flat | No route to the client prefix on the far host or its gateway |
| Reply counted on the internet-facing interface | Default route or policy rule on the far host |
| Firewall reports invalid state | Asymmetric path through a stateful device |
| Worked until a link failed over | New path is asymmetric, or rp_filter now rejects it |
வழித்தடப்படுத்துங்கள் அல்லது மொழிபெயர்க்கவும், பின்னர் இரு திசைகளிலும் சரிபார்க்கவும்
இரண்டு பழுதுகளும் சமமானவை அல்ல. வழித்தடம் சேர்ப்பது வாடிக்கையாளர் முகவரியைத் தொடாமல் வைக்கிறது, எனவே மூல அடிப்படையிலான விதிகள், தணிக்கைப் பதிவுகள், அழைப்பவரைப் பதிவு செய்யும் பயன்பாடுகள் தொடர்ந்து வேலை செய்கின்றன; விலை என்னவென்றால் முடிவெடுக்கும் ஒவ்வொரு தாவலுக்கும் வழித்தடம் தேவை, அதாவது தவறு செய்ய இன்னும் அதிக இடங்கள். தொலை நுழைவாயிலில் மறைப்பு திரும்பும் பாதையை ஒரு தாவலாகச் சுருக்குகிறது, ஏனெனில் பதில் இப்போது நுழைவாயிலையே நோக்கி அனுப்பப்படுகிறது, எந்த வாடிக்கையாளர் என்ன செய்தார் என்பதை மறைக்கிறது.
iptables -t nat -A POSTROUTING -o eth1 -s 10.20.30.0/24 -j MASQUERADEஅதை வேண்டுமென்றே தேர்ந்தெடுங்கள்: வாடிக்கையாளர்கள் நுழைவாயிலின் முகவரியாகத் தெரியத் தொடங்கியதும், மூல அடிப்படையிலான ACL அவர்களை வேறுபடுத்துவதை நிறுத்துகின்றன, பதில் சுரங்கப்பாதைக்குத் திரும்ப எழுதப்பட conntrack வரைபடத்தை வைத்திருக்க வேண்டும். தேர்விகள் இன்னும் வாடிக்கையாளர் முன்னொட்டை விலக்கினால், கோரிக்கை ஒருபோதும் சுரங்கப்பாதைக்குள் நுழையாததால் NAT எதையும் மாற்றாது.
இதைச் சரிசெய்யப்பட்டதாகச் சொல்வதற்கு முன் நான்கு விஷயங்களை வரிசையாக உறுதிப்படுத்துங்கள்: பதிலை அனுப்பும் புரவலனின் வழித்தடம், அதை முன்னோக்கி அனுப்பும் ஒவ்வொரு தாவலின் வழித்தடம், இரு முன்னொட்டுகளையும் மூடும் தேர்விகள், மற்றும் நீங்கள் எதிர்பார்க்கும் மூலத்துடன் பதில் சுரங்கப்பாதைக்குள் நுழைவதைக் காட்டும் பதிவு. பின்னர் மற்ற தளத்திலிருந்து சோதனையை மீண்டும் செய்யுங்கள். ஒரு திசை கடப்பது அரை-திறந்த வடிவமைப்பு, இரண்டாவது திசை பொதுவாக நீங்கள் இப்போது சரிசெய்ததை விட வேறு காரணத்தால் தோல்வியடைகிறது.