VPN өзгерісінен кейін маршрутизатор әкімшілігі неге жауап бермей қояды

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

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

Туннель ешқашан басқару жолы болған емес

Жіберу мен кіру — бөлек жұмыстар. «Клиент туннель арқылы NAS-қа жете ала ма?» — маршрутизатордан өтетін пакеттер туралы жіберу сұрағы. «Маршрутизатордың SSH портын аша аламын ба?» — маршрутизатордың өзіне арналған пакеттер туралы кіру сұрағы. Жіберілетін трафик үшін жазылған рұқсат ережесі екінші сұраққа ештеңе жасамайды, және трафикті мінсіз таситын туннельдің де әкімшілік сессияңыздан бас тартуының ең жиі себебі осы.

Кері қате — интерфейс атына сену. Туннель серіктеске шифрланады, оның артындағы әрбір қызметке емес, ал интерфейс белгісіндегі VPN сөзі қай көздерге кіруге рұқсат берілуі керектігі туралы ештеңе айтпайды.

Бірінші деңгей: маршрутизатордың өз мекенжайына маршрут бар ма?

Клиенттен бастап ядродан пакет қайда кететінін сұраңыз. Linux-та ip route get 10.6.0.1 таңдалған маршрутты, шығыс интерфейсін және бастау мекенжайын шығарады. Егер ол провайдеріңізге қарай әдепкі маршрутты көрсетсе, пакет туннельге ешқашан кірмейді, ал маршрутизатордағы ешбір ереже оны құтқара алмайды.

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

Саясатты жөндеуге кіріспес бұрын жетуге ниеттенген нақты мекенжайды растаңыз. Ескірген DNS жазбасы немесе өзгеріске дейінгі кэштегі көрші жазбасы сізді маршрутизаторда ешқашан болмаған мекенжайға жібереді.

Екінші деңгей: кіру саясаты, жіберу саясаты емес

Брандмауэрлер ережелерді пакет келетін интерфейсте бағалайды. pfSense мен OPNsense-те интерфейс қойындысы мен ереже реті брандмауэрдің өз қызметтеріне трафиктің рұқсат етілгенін шешеді; LAN клиенттерін интернетке шығаратын ереже туннель серіктесіне веб-интерфейсті ашуға рұқсат беретін ереже емес. firewall4-пен OpenWrt-те әр аймақ кіру саясатын ұстайды, option input 'ACCEPT' немесе 'REJECT', ал кіруі REJECT аймақтағы туннель интерфейсі басқару қосылымдарынан бас тартады, бірақ жіберуге рұқсат болса трафикті әлі де жібереді.

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

# on the router: bind addresses and the loaded ruleset
ss -ltnp | grep -E ':(22|80|443)\b'         # Linux / OpenWrt
sockstat -4 -l | grep -E ':(22|80|443)\b'   # FreeBSD / pfSense
nft list ruleset | grep -A6 'chain input'    # firewall4
pfctl -sr | head -40                         # pf / pfSense

Үшінші деңгей: сол мекенжайда бірдеңе тыңдап тұр ма?

Қызмет жұмыс істеп тұрып, бір мекенжайға байланғандықтан қолжетімсіз болуы мүмкін. OpenWrt-тың uhttpd-і /etc/config/uhttpd ішінде айқын тыңдау жазбаларын ұстайды, мысалы list listen_http '0.0.0.0:80'; тек LAN мекенжайына байланатын құрастырма туннель мекенжайында ештеңе қабылдамайды, ал тыңдау интерфейсінің параметрін көрсететін өнімдер де солай әрекет етеді. Жоғарыдағы тыңдау командалары бұған тікелей жауап береді.

Содан кейін бас тартуды үнсіздіктен ажыратыңыз. nc -vz 10.6.0.1 443 бас тартылған қосылымды қайтарса, пакет маршрутизаторға жеткен және бірдеңе оны қабылдамаған, не жабық порт, не айқын бас тарту ережесі. Тайм-аутқа дейін ілулі қалу пакеттің тасталғанын немесе ешқашан маршрутталмағанын білдіреді. Бұл айырмашылық келесі қай деңгейді тексеру керектігін айтады, ал ол бес секунд тұрады.

VPN интерфейсі — шекара, қалпына келтіру жолы емес

Шифрлау желіні қорғайды; ол әкімшілік бетті кім аша алатыны туралы ештеңе айтпайды. Туннель жұмыс істей бастағанда, туннель интерфейсінде бәріне рұқсат беру арқылы қолжетімділікті шешуге деген құштарлыққа қарсы тұрыңыз. Әкімшілерге өз туннель мекенжайына байланған ереже немесе бөлек тек әкімшілік туннель беріңіз, ал қарапайым пайдаланушыларды, NAS-ты, камераларды және отбасы ноутбуктарын басқару портынан алыс ұстаңыз. Файл бөлісу қажет серіктес маршрутизаторға кіруден бір ереже қашықтықта болмауы керек.

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

Құлыптаудан кейін адамдар жасайтын өтеу қадамы одан да нашар: WAN әкімшілігін қосу немесе портты веб-интерфейске жіберу. Бұл қысқа үзілісті тұрақты әшкерелеуге айналдырады, ал кіру беті сонда интернеттегі әрбір сканерге қолжетімді болады. Рұқсат етілген жақ сияқты бас тартылған жақты да сынаңыз, сонда әкімшілік қатынасы болмауы тиіс серіктес кіру сұрауының орнына тайм-аут немесе бас тарту алады.

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

Саясатқа тиіспес бұрын қайту жолын дайындаңыз

Бірінші өзгеріске дейін төрт нәрсені жазыңыз: туннель өлсе құрылғыға қалай жететініңізді, мысалы сериялық консоль, провайдер консолі немесе LAN-дағы машина; ағымдағы конфигурация қайда экспортталатынын; қай бір ережені немесе маршрутты өзгертетініңізді; және дәл сол элементті қалай қайтаратыныңызды. OpenWrt-те sysupgrade -b /tmp/backup.tar.gz конфигурацияны түсіреді, ал өзгерістер uci commit-ке дейін күтуде қалады, бұл уақытында байқасаңыз арзан қайтару береді. pfSense конфигурация тарихын ұстайды, ал AutoConfigBackup тек ол бұрын қосылған болса көмектеседі. Егер маршрутизатор fail-closed ережелер жиынымен жұмыс істесе, жоспарлаған техникалық қызмет жолыңыз сол ереже бөгейтін трафиктің ішінде еместігін растаңыз және қайта жүктеу тұрақты ережелерді өшірудің орнына қайта қолданатынын есте сақтаңыз.

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

Кетер алдында жылдам тексеру:

• Жаңа ғана өңдеген ережеге тәуелді емес көзден маршрутизаторға жете аласыз ба?
• Туннель интерфейсіндегі кіру саясаты тек әкімші көзіне рұқсат бере ме?
• Басқару қызметі туннельде бар мекенжайға байланған ба?
• Бір бас тартылған серіктесті және бір жаңа сессияны сынадыңыз ба?
• WAN басқару беті әлі де жабық па?