route-gateway не е redirect-gateway: какво всъщност се променя
Опцията само подава следващ хоп за маршрутите, които OpenVPN инсталира. Премахването ѝ не изключва изпратен пълен тунел, а поправката е в пренасочването.
Тунелът ви се вдига, частната подмрежа отговаря, а обикновеното сърфиране все още изчезва във VPN, въпреки че някой е изтрил реда за шлюза от профила. Тази комбинация е отпечатък от редактирането на грешна директива. Премахнатото даваше на клиента следващ хоп за маршрутите, които той инсталира; това, което продължаваше да прихваща трафика, дойде от другаде и беше изпратено от сървъра. Покритието и следващият хоп са отделни задачи и само една от тях решава дали публичните дестинации използват тунела.
Редът, който премахнахте, беше следващ хоп, а не превключвател на политика
Всеки маршрут, който клиентът инсталира, се нуждае от адрес на шлюз, към който да сочи, и директивата за шлюза е източникът на този адрес, когато маршрутът не посочи такъв сам. Изтрийте я и тези маршрути няма към какво да се прикачат, така че или не се инсталират, или попадат на път, който не води никъде. Частната подмрежа е точно това, което такъв маршрут пренасяше.
Междувременно оцелялото поведение има друг автор: опция за пренасочване в изпратения блок, която премества обикновения изходящ трафик в тунела според своите флагове. Премахването на шлюза нито я изключва, нито я отслабва. Резултатът е най-лошото от двете състояния: публичният трафик все още се прихваща, а частната дестинация, която оправдаваше тунела, вече е недостъпна. Затова и втората поправка, направена в същия дух, също не променя нищо.
Четири лоста, четири различни задачи
В тази дискусия четири директиви се цитират взаимозаменяемо и само една от тях управлява покритието, тоест кои дестинации изобщо се насочват през тунела. Втората задава следващия хоп, който използват маршрутите, третата инсталира един префикс, а четвъртата изхвърля всичко, което сървърът е изпратил, включително частните маршрути, нужни на внедряването. Таблицата ги подрежда по това, което администраторът се опитва да промени, а не по име, защото именно имената причиняват объркването. Третирайте ги като четири отделни решения и изберете това, което наистина искате да отмените.
На практика и четирите често пристигат в един изпратен блок, ред след ред, което ги прави да изглеждат части от една настройка. Те не са, и справката на OpenVPN ги документира като различни механизми точно поради тази причина. Да разберете кое решение отменяте, е задачата; поправката е един ред.
| What you are trying to change | Directive that decides it | What it leaves alone |
|---|---|---|
| Which destinations use the tunnel | redirect-gateway | Per-prefix routes and resolver choice |
| The next hop a pushed route points at | route-gateway | Coverage of public destinations |
| One reachable prefix | route | Every other destination, default path included |
| All pushed routing and DNS at once | route-nopull | Nothing, which is the problem |
Филтрирайте изпратения ред, запазете следващия хоп
Ако покритието, на което възразявате, пристига като изпратена опция, тесният отговор е да игнорирате тази опция по име и да оставите останалата част от изпратения блок непокътната. Записан като филтър, той изглежда като реда по-долу и принадлежи в профила на засегнатия клиент, а не в конфигурацията на сървъра.
pull-filter ignore "redirect-gateway"Теснотата е смисълът. Тъй като филтърът сравнява текстов префикс, по-кратък шаблон съвпада също и с директивата за следващия хоп, което отнема точно информацията, от която зависят частните маршрути, и възпроизвежда първоначалната грешка в ново облекло. Филтърът действа и само върху изпратени опции, така че никога не докосва еквивалентен ред, записан локално или наложен от мрежов мениджър. Свържете се отново след това, защото жива сесия не преоценява какво е изпратил сървърът.
Четете търсенето, а не таблицата
След презареждане на профила попитайте ядрото накъде всъщност ще отидат две дестинации: една в частния префикс и една в публичния интернет. Пълният изход на главната таблица е по-труден за четене и по-лесен за погрешно четене, защото маршрут може да съществува и пак да загуби от по-конкретно съвпадение. При маршрутизация по политики правилото, таблицата и адресът на източника също влизат в проверката.
ip route get 10.40.7.25
ip route get 203.0.113.77
ip rule showВариантът def1 заслужава познаване, защото оставя стария запис по подразбиране видим, докато двойка полу-подразбирания печели търсенето. Затова ред 0.0.0.0/0 в изхода сам по себе си не доказва нищо. Търсенето отговаря на въпроса, на който списъкът само изглежда, че отговаря.
DNS, IPv6 и частният маршрут все още трябва да работят
Отказът от едно IPv4 пренасочване не казва нищо за резолвера, така че изпратена DNS опция може да продължи да изпраща заявки в тунела, докато маршрутите изглеждат правилни. IPv6 по подразбиране може да направи същото за семейство адреси, което проверката за IPv4 не е докоснала. И двете се нуждаят от изрично решение, а не от предположение. След това потвърдете, че частната услуга все още отговаря, защото разделен тунел, който е загубил частния си маршрут, не е разделен тунел, а счупен.
Един по-широк инструмент заслужава предупреждение: route-nopull изхвърля всеки изпратен маршрут и всяка изпратена DNS опция, което със сигурност спира пълния тунел и точно толкова сигурно чупи частните маршрути, на които внедряването разчита, така че е много по-голям чук от филтър по име, насочен към една опция. Проверете частната дестинация, публична дестинация и резолвера след всяка промяна и считайте завършеното ръкостискане за доказателство за нищо друго освен ръкостискането.