VPN қосалқы желісіне портты қайта бағыттауда SNAT қолдану керек пе?

Портты маршрутизатордың өз VPN клиентінің артында тұрған хостқа қайта бағыттау өрт қабырғасының мәселесіне ұқсайтын түрде сәтсіз аяқталады, өйткені сұраныс анық жетеді. Қызмет қосылымды жазады, клиент күтеді және ештеңе қайтпайды. Межелі мекенжайды аудару өз жұмысын атқарды; қайтарылатын пакет — жоғалған бөлік. Маршрутизатордағы бір таңдамалы бастапқы NAT ережесі мұны түзетеді, ал қызықты бөлігі — бұл ереженің қаншалықты тар болуы мүмкін екенін шешу.

Неге жауап басқа жолмен жүреді

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

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

Сенуге жеткілікті тар бастапқы ереже

Маршрутизаторды алыс хост жауап беретін бастапқы көзге айналдырыңыз. Бұл орналасуда WAN мекенжайы 203.0.113.24, LAN 192.168.88.0/24, маршрутизатордың туннель мекенжайы 172.20.5.1, ал қызмет 172.20.5.40:8443 мекенжайында жауап береді. Төмендегі ереже межелі мекенжайды аударғаннан кейінгі пакетке сәйкес келеді, сондықтан жария емес, аударылған мекенжайды атайды. Онда ештеңе клиенттің мекенжайына тәуелді емес, және дәл осы — мәселенің мәні.

iptables -t nat -A POSTROUTING -o tun0 -p tcp -d 172.20.5.40 --dport 8443 -j SNAT --to-source 172.20.5.1

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

Қашан жалпылама маскарад адал таңдау болады

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

Екі нұсқа да әртүрлі сәтсіздікке ұшырайды. Жетпейтін тар ереже бір қызметті бұзады; тым көпке сәйкес келетін кең маскарад бұрыннан жұмыс істеп тұрған трафикті, соның ішінде маршрутизатордың өз шығыс қосылымдарын да, үнсіз қайта жазуы мүмкін.

Жарияламас бұрын есептегіштерді тексеріңіз

Ешқашан сәйкес келмейтін ережелер пакеттерді санағанша жұмыс істейтін ережелерге ұқсайды. Кез келген клиент қосылмас бұрын кестені байт есептегіштерімен қайта оқыңыз, содан кейін LAN емес желіден қосылып, оны қайта оқыңыз. Дәл екі оқу болжамды фактіге айналдырады. Екіншісі қозғалғаннан кейін ғана қайта бағыттауды жариялаңыз.

iptables -t nat -L POSTROUTING -v -n --line-numbers

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