VPN правила на рутеру: ускладите извор и одредиште

Странице за куповину рутера приказују VPN рутирање као једно поље за потврду, а ова фраза крије три различита питања. Да ли се правило поклапа са уређајем који шаље саобраћај, са сервером који га прима, или са оба? Шта се дешава са саобраћајем који се не поклапа ни са једним? И када се два правила преклапају, које побеђује? Записивање одговора као пара извора и одредишта претвара нејасан списак функција у проверљив дизајн.

Назив функције крије два краја

Медијски плејер који треба да користи тунел је поклапање извора. Приватни канцеларијски префикс који треба да буде доступан кроз тунел је поклапање одредишта. Радна станица која тунел треба да користи само за једну услугу је оба, а тај пресек је случај са којим већина потрошачког фирмвера лоше поступа.

Запишите захтев као пар пре него што упоредите производе. Тај пар ћете касније тестирати.

Производ који нуди списак уређаја или глобални списак одредишта можда не може да изрази „само овај уређај, само ова одредишта“. Разлика није козметичка: глобално правило одредишта шаље саобраћај сваког уређаја ка том сајту кроз тунел, а правило уређаја шаље сав саобраћај тог уређаја. Ни једно није захтев. Тестирајте тај случај са два уређаја пре него што поверите екрану.

Изградите правило као пресек

Табела чува дизајн искреним. Ставите сценарио лево, затим одвојено назовите поклапање пошиљаоца и поклапање циља:

Трећи ред је занимљив јер му требају обе половине истовремено. Ако фирмвер може да изрази само једну осу, захтев мора да се подели на два правила или премести на уређај који то може.

Одржавајте идентитет извора стабилним. DHCP резервација, наменски сегмент или механизам идентитета уређаја раде, али адреса која се мења по истеку закупа не ради. Укључите IPv6, јер једна IPv4 адреса не идентификује сав саобраћај уређаја.

Приоритет одлучује преклапање

Преклапање правила је нормално. Широко правило уређаја и уско правило одредишта могу да описују исти ток, а документовани редослед приоритета одлучује које побеђује. Привлачан екран подешавања не каже вам тај редослед.

Прочитајте у приручнику о редоследу и о случају без поклапања, затим тестирајте обоје саобраћајем који можете да посматрате:

ip rule show
ip route get 203.0.113.10

Ако документација не наводи редослед, претпоставите да уже правило можда неће победити и пројектујте у складу с тим. Два правила која не могу да се сукобе лакше је подржавати од једног паметног правила са недокументованим приоритетом.

Имена захтевају политику освежавања

Одредиште записано као домен додаје проблем одржавања. Рутер мора да га реши, освежи мапирање, обради више адреса и поддомена и носи се са DNS-ом апликација који заобилази очекивани резолвер.

Копирање једног резултата претраге у IP правило је снимак, а не политика домена.

Одлучите колико одговор може да буде стар пре него што правило буде погрешно и шта рутер ради када решавање не успе. Правило које чува последњу познату адресу може да надживи миграцију услуге; правило које одбацује унос може тихо да заустави тунелирање. Оба понашања су прихватљива ако су записана поред правила.

Дефинишите стање недоступности

Поставка руте не намеће саобраћај само кроз VPN. Када је тунел искључен, рутер може да блокира ток, пошаље га директно или употреби други тунел, и сваки избор има другачији потпис квара.

Одлучите које захтев тражи, затим то проверите заустављањем тунела и посматрањем тока:

curl -sS -o /dev/null -w "%{http_code}" --max-time 5 https://service.example/
ping -c 2 203.0.113.10

Саобраћај који потиче са самог рутера је одвојен обим. DNS прослеђивање, провере ажурирања и надзор могу да започну нове токове са самог рутера уместо да наследе поклапање извора уређаја. Узмите те токове експлицитно у обзир, иначе ће се појавити као необјашњена цурења у дневницима.