Правила за VPN на рутера: съпоставете източника и дестинацията
Правилото за VPN на рутера има два края: устройството, което изпраща трафик, и дестинацията, която трябва да използва тунела. Първо решете пресечната точка и резервния вариант.
Страниците за пазаруване на рутери представят VPN маршрутизацията като една отметка и тази фраза крие три различни въпроса. Правилото съвпада ли с устройството, което изпраща трафика, със сървъра, който го получава, или с двете? Какво се случва с трафика, който не съвпада с нито едно? И когато две правила се припокрият, кое печели? Ако запишете отговора като двойка източник и дестинация, неясният списък с функции се превръща в проверим дизайн.
Името на функцията крие два края
Медиен плейър, който трябва да използва тунела, е съвпадение по източник. Частен офис префикс, който трябва да е достъпен през тунела, е съвпадение по дестинация. Работна станция, която трябва да използва тунела само за една услуга, е и двете, и тази пресечна точка е случаят, с който повечето потребителски фърмуери се справят лошо.
Запишете изискването като двойка, преди да сравнявате продукти. Тази двойка е това, което ще тествате по-късно.
Продукт, който предлага списък с устройства или глобален списък с дестинации, може да не изрази „само това устройство, само тези дестинации“. Разликата не е козметична: глобално правило за дестинация изпраща трафика на всяко устройство към този сайт през тунела, а правило за устройство изпраща целия трафик на това устройство. Нито едно от двете не е изискването. Тествайте този случай с две устройства, преди да се доверите на екрана.
Изградете правилото като пресечна точка
Таблицата държи дизайна честен. Поставете сценария отляво, после назовете съвпадението на изпращача и съвпадението на целта поотделно:
| Scenario | Sender match | Target match | Rule shape |
|---|---|---|---|
| Media player uses the tunnel | Player address | Any internet destination except the LAN | Source only |
| Office prefix reachable | Authorized LAN devices | 10.40.0.0/16 | Target only |
| One app on one laptop | Laptop address | The service address set | Source and target |
| Guest network never tunnels | Guest subnet | Any | Deny, evaluated first |
Третият ред е интересният, защото се нуждае от двете половини наведнъж. Ако фърмуерът може да изрази само една ос, изискването трябва да се раздели на две правила или да се премести на устройство, което може.
Пазете идентичността на източника стабилна. 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 препращането, проверките за актуализации и мониторингът могат да стартират нови потоци от самия рутер, вместо да наследят съвпадението по източник на устройството. Отчетете тези потоци изрично, иначе ще се появят като необяснени изтичания в журналите.