Копирането на /32 от тунела няма да насочи офис подмрежата
Адресът, който VPN дава на адаптера ви, описва връзката, а не дестинацията. Добавете префикса на ресурса към профила и оставете маршрута по подразбиране.
VPN се свързва, интерфейсът показва адрес с маска от тридесет и два бита, а офис сървърът остава недостъпен. Следващата стъпка често е тази маска да се използва отново в маршрут, с идеята, че интерфейсът описва какво може да достигне тунелът. Не описва. Този адрес описва локалния край на връзка точка-точка, а дестинацията, която ви интересува, е в различен префикс от другата ѝ страна.
Смесват се две различни неща: адресът, който тунелът ви е дал, и мрежата, която искате да достигнете през него.
Два адреса, две задачи
При тунел точка-точка клиентският адрес често е един адрес на хост, защото в другия край на връзката има точно един партньор. Няма споделен сегмент и няма ARP, така че маска, която би изглеждала абсурдно на Ethernet, тук е напълно нормална.
Префиксът на дестинацията е факт за офис мрежата, не за тунела. Ако ви трябва един сървър, маршрутът е маршрут до хост за този сървър. Ако ви трябва цялата офис подмрежа, маршрутът е подмрежата. Нито един от тези отговори не може да се прочете от интерфейса и избирането на един от тях, защото е стоял до адреса на тунела, е начинът да се счупи работеща настройка.
| What you need to reach | What to install |
|---|---|
| One server, nothing else | A host route for that address |
| The office subnet | A route for the subnet prefix |
| Everything in the private space | Only if the requirement says so, and only with the owner's approval |
Третият ред е мястото, където оптимизмът се превръща в прекъсване. Насочването на цял частен диапазон в тунел, който обслужва само един сайт, избутва несвързан трафик по път, който не може да го достави, и получените откази изглеждат като счупен VPN, а не като прекалено широк маршрут.
Изберете префикса от изискването
Напишете изискването като изречение, преди да пипате профил: кои хостове трябва да са достъпни и кой е най-тесният префикс, който ги покрива? Един сървър е маршрут до хост. Подмрежа е маршрут до подмрежа. Диапазон от подмрежи е обобщение, а обобщението е обещание, че всеки адрес в него е достъпен, което рядко е вярно.
После сверeте числото с това, което офисът всъщност използва. Копирането на префикс от съобщение в чат, без да го потвърдите с плана за адресиране на сайта, е начинът маршрутът да сочи към подмрежа, която никой не притежава.
Запомнете също, че маршрутът е път, а не разрешение. Шлюзът все още решава дали вашият клиент може да използва дестинацията, а услугата все още може да ви откаже. Правилното инсталиране на маршрута довежда пакета там и не отговаря нищо за оторизацията.
Добавяйте към профила, никога не го замествайте
Маршрутите в профил на NetworkManager са многозначно свойство и разликата между задаване и добавяне е един знак. Използвайте формата с плюс, за да добавите запис и да запазите всичко вече записано.
nmcli connection modify uuid 11111111-2222-4333-8444-555555555555 \
+ipv4.routes "10.40.20.9/32"Без плюса присвояването замества целия списък. В профил, който вече носи няколко префикса, това безшумно изтрива работещите и симптомът идва по-късно като услуга, която преди е била достъпна от този лаптоп.
Използвайте UUID вместо името. Имената се дублират след възстановяване и връзката, която редактирате, може да не е тази, която носи трафика ви. Първо проверете за съществуващ идентичен запис, защото добавянето на дубликат е разхвърляно дори когато е безвредно.
Тази справка за свойствата на маршрутите описва дестинацията, незадължителния следващ хоп, метриката и синтаксиса на атрибутите за инсталираната версия. Прочетете я преди да добавите следващ хоп, защото дали е нужен зависи от интеграцията и топологията, а отгатването му по първия адрес в списък на интерфейси не е метод.
Маршрут по подразбиране и DNS са отделни решения
Adding an office prefix says nothing about where the rest of your traffic goes. If policy requires ordinary internet traffic to stay outside the tunnel, that is the ipv4.never-default decision, and it belongs to whoever owns the connection policy rather than to whoever is fixing one unreachable server.
Автоматичните маршрути са другото нещо, което не бива да се пипа небрежно. Потискането им, за да се реши един липсващ запис, може да премахне няколко работещи, а човекът, който го е предложил, обикновено е гледал друг профил с други push-ове.
DNS има свой път и свои откази. Име, което се разрешава до правилния адрес през грешен резолвер, или резолвер, който не може да отговори за частната зона, ще изглежда като проблем с маршрутизацията, докато маршрутът е безупречен. Тествайте адреса и името поотделно, после решете кой слой всъщност се е провалил.
Проверете какво е приложено
Запазена промяна не е приложена промяна. Свържете се отново през поддържания жизнен цикъл на мениджъра, после погледнете действителния маршрут за желаната дестинация и правилата за политика, които решават коя таблица се ползва.
Ако префиксът е там, а връзката още се проваля, преминали сте към друг проблем: избор на адрес на източника, обратен маршрут в далечния край или услуга, която отказва клиента ви. Всяко от тези е по-добро място за гледане от профила, който вече сте коригирали.