Защо администрацията на рутера спира да отговаря след промяна на VPN

Променихте маршрут или правило на защитната стена, за да тествате тунел на рутера, и сега страницата за администрация не отговаря от лаптопа, който работеше добре преди десет минути. Рефлексът е да обвините VPN. Повечето пъти тунелът е здрав и едно от три други неща се е счупило: няма маршрут обратно към собствения адрес на рутера, входна политика изхвърля заявката или уеб услуга не слуша адреса, който викате. И трите изглеждат еднакво в браузъра, затова хората рестартират тунела час и не научават нищо.

Ето мита, който си струва да убием първи: работещият тунел не е път обратно навътре. Той е ново мрежово свързване със свои собствени въпроси за доверие и може тихо да премахне стария ви път за управление, докато отваря нов, който никой не е прегледал.

Тунелът никога не е бил пътят за управление

Пренасочването и входът са различни задачи. „Може ли клиент да достигне NAS през тунела?“ е въпрос за пренасочване относно пакети, които минават през рутера. „Мога ли да отворя SSH порта на рутера?“ е въпрос за вход относно пакети, адресирани до самия рутер. Правило за пропускане, написано за пренасочван трафик, не прави нищо за втория въпрос и това е най-честата причина тунел, който пренася трафик безупречно, все пак да отказва сесията ви за управление.

Обратната грешка е да се доверявате на име на интерфейс. Тунелът е криптиран към партньора, а не към всяка услуга зад него, и думата VPN в етикет на интерфейс не казва нищо за това кои източници трябва да имат право да влизат.

Първи слой: има ли маршрут до собствения адрес на рутера?

Започнете на клиента и попитайте ядрото накъде ще отиде пакетът. В Linux ip route get 10.6.0.1 отпечатва избрания маршрут, изходящия интерфейс и адреса на източника. Ако той показва маршрута по подразбиране към доставчика ви, пакетът никога не влиза в тунела и никакво правило на рутера не може да го спаси.

Страната на тунела има своя версия на въпроса. WireGuard третира AllowedIPs като таблица за криптоключов маршрутизиране: от всяка страна тя обявява кои адреси на източник партньорът може да използва и кои дестинации се изпращат към този партньор. Ако записът на клиента не включва тунелния адрес на рутера, клиентът няма маршрут до него. Ако записът на сървъра за този клиент не покрива тунелния адрес на клиента, сървърът изхвърля пакета, преди да бъде прочетено каквото и да е правило на защитната стена.

Потвърдете точния адрес, който очаквате да достигнете, преди да отстранявате проблеми в политиката. Остарял DNS запис или кеширан запис за съсед отпреди промяната ви отвежда до адрес, който рутерът никога не е притежавал.

Втори слой: входната политика, а не политиката за пренасочване

Защитните стени оценяват правилата на интерфейса, на който пристига пакетът. В pfSense и OPNsense разделът на интерфейса и редът на правилата решават дали трафикът към собствените услуги на защитната стена е разрешен; правило, което пуска LAN клиенти към интернет, не е правило, което позволява на партньор по тунела да отвори уеб интерфейса. В OpenWrt с firewall4 всяка зона носи входна политика, 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

Трети слой: слуша ли нещо на този адрес?

Една услуга може да работи и все пак да е недостъпна, защото се е обвързала с един адрес. uhttpd на OpenWrt държи явни записи за слушане в /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, потвърдете, че планираният път за поддръжка не е вътре в трафика, който това правило блокира, и помнете, че рестартирането прилага отново постоянните правила, вместо да ги изчиства.

Променяйте по една граница на опит, след което тествайте от нова връзка, а не от обвивката, която държите отворена. Ако тестът се провали, върнете тази една промяна, преди да пипате следващия слой. Тунелът може да остане вдигнат през цялото време, но зелената му икона за състояние не е доказателство, че все още можете да влезете.

Бърза проверка, преди да тръгнете:

• Можете ли да достигнете рутера от източник, който не зависи от правилото, което току-що редактирахте?
• Входната политика на тунелния интерфейс позволява ли само източника на администратора?
• Услугата за управление обвързана ли е с адрес, който съществува в тунела?
• Тествахте ли един забранен партньор и една нова сесия?
• Повърхността за администрация през WAN все още ли е затворена?