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 башкаруу бети дагы эле жабыкпы?