Неге сіздің LAN VPN клиентіндегі қызметке жете алмайды

VPN клиенті LAN аша алмайтын қызметті орналастыра алады. Әдетте жетіспейтіні — қайтару жолы: бір маршрут, DNAT жұбы немесе ешкім қоспайтын SNAT жолы.

Туннеліңіз көтерілген, қызмет тыңдап тұр, ал кеңсе LAN-ы әлі де ештеңе қайтарып алмайды. Ешкім VPN-ді бұзбаған. LAN жағынан ноутбуктің туннель мекенжайы, әлдекім LAN-ға оған қалай жетуді айтпайынша, жоқ, және жауап сұраныс шыққан жолмен қайтуы керек. Мен адамдардың қайтару жолына ешкім қарамай тұрып, толық сау туннельді үш рет қайта салғанын көрдім.

Бұзылған туннель емес

Екі ұш та жеке диапазондарда отыр, бұл қалыпты жағдай, қате конфигурация емес. 10.8.0.6 сияқты мекенжай туннель ішінде нақты және басқа жерде жоқ, сондықтан LAN-ның оған бірдеңе жіберуге себебі жоқ. Маршруттауға тиіспес бұрын қызметтің туннель ішінде жалпы қолжетімді екенін растаңыз: клиентте ss -ltn тыңдаушының 127.0.0.1, LAN интерфейсіне әлде туннель мекенжайына байланғанын көрсетеді. Тек loopback-қа байланған демон өзінен басқа ешкімге жауап бермейді, және оны ешбір маршрут, DNAT немесе портты қайта бағыттау өзгертпейді.

80 немесе 443 портындағы прокси — басқа көрінуі бар басқа құрал. Ол пакеттерді емес, сұраныстарды жылжытады, сондықтан шикі дерекқор қосылымы үшін дұрыс қабат емес, және оған жүгіну — бұл мәселенің біреу бірдеңе өлшеуінен бұрын үш құрал тереңдігіне жету жолы.

Маршрут пішімі: LAN-ға пулдың қайда екенін айтыңыз

LAN шлюзіндегі статикалық маршрут — LAN мен туннель пулы қабаттаспағанда ең таза жауап. Пулды туннельді аяқтайтын машинаға бағыттаңыз:

ip route add 10.8.0.0/24 via 192.168.1.12
route add -p 10.8.0.0 mask 255.255.255.0 192.168.1.12   # Windows, persistent

Бұл тек бір бағытты түзейді, сондықтан бұл өзгерістің жартылай нұсқалары ілгерілеу болып көрінеді. Туннель жағына сәйкес жартысы керек, әйтпесе жауап клиентті өзінің әдепкі маршрутымен тастап, жолда өледі:

push "route 192.168.1.0 255.255.255.0"

Сервердің артында емес, бір клиенттің артында тұрған қосалқы желі үшін серверге жүйелік маршрут та, сол клиенттің файлында iroute жазбасы да керек, ол файл client-config-dir астында болады. iroute жоқ болса, OpenVPN префикстің бар екенін біледі, бірақ оны қай клиент иемденетінін білмейді: пакеттер келеді, ал демонның оларды сәйкестендіретін ештеңесі жоқ.

Міне, атауға тұрарлық аңыз. Маршрут мекенжайды қолжетімді етеді; ол қарсы жақты жауап беруге дайын етпейді. Сайттан сайтқа серіктестер үстіне тағы бір қабат қосады, өйткені қашықтағы шлюз тек өз саясатында тізілген префикстердің ішіндегі көздерді қабылдайды, ал үй пулынан келген ноутбук олардың ішінде емес.

NAT пішімі: ішке DNAT, және бәрі өткізіп жіберетін SNAT жолы

LAN шлюзіне тие алмағанда немесе дәл бір портты жариялағыңыз келгенде, VPN хосттағы аударма LAN-да ешбір маршрутсыз жұмыс істейді. Портты жариялаңыз, оны қайта бағыттаңыз, және көзді туннельге кіретін жолда аударыңыз:

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 8080 -j DNAT --to-destination 10.8.0.6:3000
iptables -A FORWARD -i eth0 -o tun0 -p tcp -d 10.8.0.6 --dport 3000 -j ACCEPT
iptables -t nat -A POSTROUTING -o tun0 -d 10.8.0.6 -p tcp --dport 3000 -j SNAT --to-source 10.8.0.1

Үшінші жол — жоғалатын жол. Оны өткізіп жіберсеңіз, клиент бастапқы LAN мекенжайын көз ретінде көреді, өзінің әдепкі маршрутымен жауап береді, және бұл жауап LAN-ға қайтудың орнына туннельге кетеді. Байланыс аман қала ма, ол сіз ешқашан жоспарламаған маршруттауға байланысты болады. SNAT-пен клиент сервердің туннель мекенжайын көреді, сондықтан жауап туннельмен кері аударманы жоя алатын жалғыз хостқа дейін барады.

Тұтынушылық firmware өзінің шынжыр атауларын пайдаланады және бұл аударманы сіз үшін жасамайды. Tomato-да кіріс ережесі WANPREROUTING ішіне, содан кейін wanin тәрізді сүзгі шынжырына түседі, және толық көрінетін ережелер жинағы әлі де қолмен жазылған POSTROUTING жолын қажет етеді. Бұл firmware қатесі емес; бұл тек кіріс трафигі үшін жазылған ережелер жинағы.

Неге дұрыс көрінетін ереже пакетті бәрібір тастайды

Бұл сәтсіздіктердің көбі сіз қарап тұрған ережеде емес. Осы ретпен төрт нәрсені тексеріңіз, және орындалмайтын біріншісінде тоқтаңыз:

  • Шынжырлар реті. iptables -I жоғарыға кірістіреді, ал -A соңына қосады, сондықтан бұрынғы рұқсат ететін немесе блоктайтын ереже бірінші шешеді.
  • Қате шынжыр. Роутердің өзіне адрестелген трафик INPUT арқылы өтеді, ал қайта бағытталған трафик оған ешқашан тимейді. Бір қызметті жариялау екеуінде де ережелерді талап етуі мүмкін.
  • Бағыт жалаулары. -i tun0 клиенттерден келетін трафикке сәйкес келеді, ал -o tun0 оларға қарай кететін трафикке. Қате жалаумен REJECT сіз ойламаған нәрсені бөгейді.
  • Көз шектеуі. Бір клиент мекенжайын қабылдайтын қайта бағыттау сол клиенттен жұмыс істейді және кез келген басқа көзді бір сөз айтпай тастайды.

Пакет санағышы нөл болатын ереже жолда мүлдем жоқ, және санағыштарды оқу қате шынжыр мәселесін қате ереже мәселесінен ажыратудың ең жылдам жолы.

Жергілікті қайта бағыттау, LAN-да ештеңе өзгертуге болмағанда

SSH жергілікті қайта бағыттауы бүкіл сұрақты айналып өтеді. Оған LAN-да маршрут та, клиенттің firewall-ының ынтымақтастығы да, бір жерде жарияланған порт та қажет емес:

ssh -N -f -L 3000:10.8.0.6:3000 user@vpn-host

Содан кейін қызмет туннельді ұстап тұрған машинаның localhost:3000 мекенжайында шығады, және басқа жерде емес. Бұл — шек: бір жұмыс станциясы, бір порт, және бірдеңе оны қайта іске қоспаса, қайта бағыттау сеанспен бірге өледі. Сынақ дерекқорын тексеретін әкімші үшін бұл дұрыс құрал. Басқа адамдар жетуі тиіс камера немесе сканер үшін олай емес, өйткені әр пайдаланушыға өзінің қайта бағыттауы керек болар еді.

Тағы бір ереже қоспас бұрын екі бағытты да тексеріңіз

Аударма із қалдырады, және оларды оқу болжаудан артық. VPN хостта conntrack -L аударманың жалпы болғанын, iptables -t nat -L -n -v санағыштардың жылжығанын, ал tcpdump -ni any port 3000 қай көз мекенжайының шын мәнінде келгенін көрсетеді. Клиентте ss -ltn тыңдаушының туннель жете алатын мекенжайда екенін растайды.

Содан кейін сақтайтын пішіміңізді таңдаңыз. Бір жарияланған порт, бүкіл пулға арналған маршрут және бір әкімшіге арналған қайта бағыттау — үш түрлі міндеттеме, және оларды араластыру жұмыс істеп тұрған конфигурацияны алты айдан кейін ешкім түсіндіре алмайтын конфигурацияға айналдыратын жол. Қай мекенжай қайдан қолжетімді екенін жазып қойыңыз, және мұны жөндейтін келесі адам туннельден емес, жауаптан бастайды.

Қатысты мақалалар