Зашто администрација рутера престаје да одговара после промене 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 администрацију још увек затворена?