VPN туннелінің мекенжайы кіріс портын неге ашпайды
Туннель мекенжайы клиентіңізді оған маршруттай алатын әріптестерге танытады және ешқашан тыңдаушы жасамайды. Байланыстыруды, қайтару маршрутын, содан кейін саясатты тексеріңіз.
Кеңсе VPN-іне қосылыңыз, 8443 портында шағын қызметті іске қосыңыз, туннель мекенжайын әріптесіңізге жіберіңіз және клиент әлі де қосылғанын хабарлап тұрғанда байланыстың сәтсіз аяқталғанын бақылаңыз. Туннельде ештеңе бұзылмаған: мекенжай берілген, сессия белсенді, ал жауапты таситын пакеттер жай ғана ешқашан жіберілмейді. Төмендегі үш тексеруді ретімен орындаңыз және сәтсіз аяқталғанына тоқтаңыз, өйткені әрқайсысының түзетуі басқа және олардың тек біреуі ғана VPN-ге қатысты.
Сокеттің шын мәнінде қайда байланғанынан бастаңыз
Бірдеңе маршрутталудан бұрын, қоңырау шалушы жете алатын мекенжайды бірдеңе тыңдауы керек. Әзірлеу серверлері әдеттегі кінәлі, өйткені олардың көбі әдепкі бойынша loopback-ке байланып, тек сол машинадан шыққан қосылыстарды қабылдайды. Туннель мекенжайы бұл байланыстыруды өзгертпейді, және операциялық жүйе VPN араласпай тұрып байланысты қабылдамайды.
ss -ltnp | grep 8443
netstat -ano | findstr 8443Күйді емес, жергілікті мекенжай бағанын оқыңыз. 127.0.0.1:8443 тек loopback дегенді білдіреді, ал түзету 0.0.0.0 немесе туннель мекенжайының өзіне байланыстыру. 0.0.0.0:8443 барлық интерфейстерде қабылдайды, бұл машинаның жария мекенжайы болған кезде көпшілік ойлағаннан кеңірек; 10.64.7.15:8443 тек әріптес жете алатын жерде тыңдайтын тар нұсқа. Сол шығыстағы процестің атына да назар аударыңыз, өйткені бұрынғы сынақтан қалған артық дана порттың ашық көрінуінің және дұрыс емес мазмұнмен жауап беруінің кәдімгі себебі.
Содан кейін сол мекенжайға бірдеңе маршруттай ала ма деп сұраңыз
Туннель мекенжайының мағынасы тек сол префиксті туннельге жіберуге конфигурацияланған әріптестер үшін бар. Әріптесіңіздің машинасының өз кестесі бар, және туннель ішкі желісіне маршрут болмаса, пакет әдепкі шлюзге кетеді және мекенжайдың бар екенін білмейтін жерде өледі. Бұл қоңырау шалушы жағындағы маршруттау мәселесі, сіздің жағыңыздағы рұқсат емес.
| Symptom from the caller | What it usually means | Where to look next |
|---|---|---|
| Connection refused immediately | Nothing is listening on the address the packet reached | The bind address and the process owning the port |
| Connection times out with no reply | A policy dropped the packet, or no route returns | Server forwarding, host firewall, cloud security group |
| Works from the same machine only | Listener is on loopback, or no route reaches the tunnel address | Bind address, then the caller's route to that prefix |
Екі клиенттің арасындағы сервер де соншалықты маңызды. Әдеттегі қашықтан қатынау дизайнында әр клиент шлюзге шығыс қосылыс ашады және шлюз сол ағындардың күйін сақтайды, сондықтан жауаптар өзі бұрыннан білетін жолмен қайтады. Бір клиенттен екіншісіне қосылыс — шлюз қабылдап, әрі қарай жіберуі керек жаңа ағын, және көптеген орналастырулар клиенттерді бір-бірінен оқшау ұстау үшін мұны әдейі өшіреді. Тұтынушылық VPN қызметтері әдетте әдепкі бойынша оқшаулайды; корпоративтік шлюздер кейде топ бойынша рұқсат етеді.
Хостта бірдеңе өзгертуден бұрын бағытты тексеріңіз. Егер туннель мекенжайы шлюздің өзінен жауап беріп, әріптестен бермесе, айырмашылық шлюздің клиенттен клиентке параметрі, және жергілікті брандмауэрді өңдеудің ешқандай мөлшері оны алмастыра алмайды.
Соңында, ағынды рұқсат ететін саясатты табыңыз
Маршрутталған пакет пен жауап беретін қызметтің арасында үш саясат қабаты тұр: VPN серверінің жіберу шешімі, хост брандмауэры және дананың алдындағы кез келген бұлттық қауіпсіздік тобы. Үшеуі де келісуі керек, және олар әртүрлі жолдармен сәтсіз аяқталады, сондықтан жоғарыдағы кестедегі симптом браузердегі қате хабарламасынан гөрі пайдалырақ.
Хост брандмауэры — сәтті байланыстырудан кейін адамдар ұмытып кететін қабат, өйткені LAN интерфейсінде портқа рұқсат беретін ереже оны туннель интерфейсінде автоматты түрде рұқсат етпейді. Интерфейспен шектелген ережелер дұрыс дизайн және сонымен бірге кеңседен жұмыс істеп, үйден жұмыс істемейтін қызметтің әдеттегі себебі. Ереженің порт нөмірін емес, ауқымын оқыңыз.
Күйге негізделген сүзу кері жағдайды түсіндіреді. Ноутбугіңізден шыққан қосылыс күй жасайды, және оған жауаптар кіріс ережесінсіз жіберіледі. Әріптестің қосылысы артында күйі жоқ мүлдем жаңа ағын, сондықтан оған айқын рұқсат қажет. Бұл асимметрия — өз машинаңызда жұмыс істейтін браузер сессиясының қызметтің сырттан қолжетімділігі туралы ештеңе айтпауының бүкіл себебі.
Бір тексеру сәтсіз болса, туннельді емес, дизайнды өзгертіңіз
Егер талап әріптесіңіздің жергілікті қызметіңізді ашуы болса, адал жауап әдетте кіріс қатынау үшін жасалған механизм. Кері SSH туннелі ең кішісі: машинаңыз әріптес бұрыннан жете алатын хостқа шығыс қосылыс орнатады, ал тыңдаушы сол хостта болады.
ssh -N -R 8443:127.0.0.1:8443 [email protected]Ретранслятор өзінің SSH сервер конфигурациясында GatewayPorts clientspecified қажет етеді, әйтпесе жіберілген тыңдаушы ретрансляторда loopback-ке байланып, әріптес бұрынғыдай қабылдамауға тап болады. Бір түстен кейін ұзаққа созылатын кез келген нәрсе үшін денсаулық тексерісі мен жарияланған атауға арналған сертификаты бар жүктеме теңгерушісі немесе ingress жақсырақ құрал, ал екі желі шынымен сөйлесуі керек болғанда екі ішкі желіге де маршруттары бар сайттан сайтқа туннель дұрыс жауап.
Осы дизайндардың әрқайсысы әсерді айқын етеді, және мәселенің мәні осында. VPN пакеттерді сіз бұрыннан пайдалануға рұқсатыңыз бар желілер арасында жылжытады; ол қызметті жарияламайды және ноутбукті интернетке қараған хостқа айналдырмайды. Үш қабаттың қайсысын өзгертуді шешу — міндет, ал туннель олардың ішінде сирек болады.