Hairpin NAT: VPN соңғы нүктесі неге іштен жұмыс істемейді

Ұялы желіден жауап беретін, бірақ диваннан істемейтін VPN сервері әдетте сертификат мәселесі емес. LAN ішіндегі клиент маршрутизатордан баратын жері маршрутизатордың өз қоғамдық мекенжайы болып табылатын пакетті түрлендіруді сұрайды, яғни пакет сыртқа шығып, дереу қайта кіруі керек. Бұл тәсіл hairpinning деп аталады, және көптеген маршрутизатор оны не мүлде іске асырмайды, не тек белгі қойылған ұяшық болғанда ғана жасайды. Сырттан жасалған тесттің өтуі шатастырады, өйткені ол тыңдаушы мен қайта бағыттау ережесінің дұрыс екенін дәлелдейді.

Пакет сыртқа шығып, қайта кіреді

Пакетті қадағалаңыз. Клиент қоғамдық атты шешеді, қоғамдық мекенжайға қосылады, ал маршрутизатордың баратын жер NAT-ы баратын жерді ішкі серверге қайта жазады. Сервердің жауабы клиенттің LAN мекенжайына адрестелген, сондықтан ол көзді кері түрлендіретін NAT ережесінен еш өтпей, маршрутизатордың LAN интерфейсі арқылы қайтады.

Енді клиент ешқашан ештеңе жібермеген мекенжайдан пакет алады және оны тастайды. Осы асимметрия — бүкіл ақау.

RFC 4787 осы жағдайда NAT-тан күтілетін мінез-құлықты сипаттайды, және қысқа нұсқасы — бұл теорияда белгіленген жерде де тәжірибеде міндетті емес. Кейбір маршрутизатор бұл параметрді NAT loopback деп атайды, басқалары hairpin NAT немесе NAT reflection дейді, ал кейбіреулері ештеңе көрсетпейді. Бұл функциясы жоқ маршрутизатор қате конфигурацияланбаған; ол әдеттегі істі істеп тұр, ал түзету басқа жерге тиесілі. Жергілікті тесттің сәтсіздігіне қарап қоғамдық қайта бағыттау ережесін қате деп шешпеңіз.

Тексеру 1: екі жолды бөлек тексеріңіз

LAN сыртынан нақты пайдаланушы қолданатын профильмен қосылып, сессияның орнағанын растаңыз. Іштен сол профильмен қоғамдық мекенжайға қосылып, нақты қатені және уақытты жазыңыз.

Нақты жергілікті тест хост атын сақтап, тек мекенжайды алмастырады: curl -v --resolve vpn.example.com:443:203.0.113.10 https://vpn.example.com/ сұранысты қоғамдық мекенжайға жібереді, сонымен бірге дұрыс сервер атын көрсетеді. Бұл атты шешу мәселесін түрлендіру мәселесінен ажыратады, ал олар бір ат дәмханадан жұмыс істегенде оңай шатасады. Клиент TCP қосылысында ма, әлде кейінірек TLS-те сәтсіздікке ұшырай ма, соны белгілеңіз, өйткені біріншісі түрлендіруге, екіншісі сәйкестікке нұсқайды.

Тексеру 2: сервер нені көретінін оқыңыз

Ең пайдалы бақылау — сервердің көзқарасы. VPN хостта клиенттің LAN мекенжайы мен маршрутизатордың LAN мекенжайы бойынша сүзілген түсірілімді іске қосып, кейін жергілікті әрекетті қайталаңыз. Ештеңе келмесе, пакет түрлендіруден өтпеді.

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

Тексеру 3: сыртқы жолды ұстамай түзетіңіз

Үш қолдау көрсетілетін нысан бар, әсер радиусының өсу ретімен. Ең тар — бөлінген DNS: ішкі жазбаны жариялаңыз, сол сервер аты LAN-дағы клиенттер үшін ішкі мекенжайға шешілсін, бұл қоғамдық жолды мүлде айналып өтеді. Келесісі — маршрутизатордың құжатталған loopback немесе reflection опциясын қосу, егер ол болса, және оны тек осы қызметке қолдану. Ең кең — маршрутизатордағы source-NAT ережесі, ол LAN-нан келетін трафикті серверге қайта жазады, сонда жауап маршрутизатор арқылы қайтады; Linux маршрутизаторында бұл сервердің мекенжайы мен портына сәйкес келетін MASQUERADE ережесі POSTROUTING ішінде болады. Үшеуі де сыртқы жолды тиіспеген күйде қалдырады, ал сақталуы тиіс қасиет — осы.

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

Бөлінген DNS-тің атап өтуге тұрарлық бір тұзағы бар. Хост атын ерікті IP-мен алмастыру клиенттің нені тексеретінін өзгертеді, сондықтан ішкі жазба сертификаттағы атқа сай болуы керек.

Тексеру 4: кейін екі жолды да тексеріңіз

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

Жазбаны қысқа ұстаңыз: қай клиент қай мекенжайды қолданды, сервер нені көрді және үш түзетудің қайсысы қолданылды. RFC 4787-дегі hairpinning талаптары осында NAT-тан күтілетін нәрсенің сілтемесі, және бұл функциясыз маршрутизатордың неге қалыпты әрекет ететінін түсіндіреді. Сыртқы әлем қайталай алмайтын жергілікті сәтсіздік — керісінше дәлелденбейінше түрлендіру мәселесі, сондықтан оны солай тексеріңіз.