Чаму адміністраванне роўтара перастае адказваць пасля змены 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?