OpenVPN redirect-gateway: какво прави всеки флаг с маршрутите

Свържете се с redirect-gateway в профила и маршрутът на машината ви по подразбиране може да изчезне, да се раздели на две или да остане точно там, където беше, в зависимост от флагове, които никой не прочита два пъти. Опцията променя състоянието на маршрутизацията и нищо друго, затова единственото надеждно доказателство за това какво е направила е таблицата, която клиентът е инсталирал след това. Следва таблицата след свързване, маршрутът, който поддържа жив самия тунел, и трафикът IPv6, който директивата никога не твърди, че покрива. Всяка стъпка е команда, която можете да изпълните на клиента, докато тунелът е активен.

Какво прави всеки флаг с маршрута по подразбиране

Без никакъв флаг опцията премахва обичайния маршрут по подразбиране и поставя тунела на негово място, така че старият шлюз изчезва от таблицата, докато връзката е активна. Добавете def1 и този маршрут по подразбиране остава в списъка, а работата вършат два по-тесни маршрута. Добавете bypass-dhcp и DHCP маршрутът също оцелява, което е важно в мрежа, където клиентът все още трябва да достигне локалния DHCP сървър. Списъкът с флагове на страницата с ръководството за OpenVPN 2.6 е достатъчно кратък, за да се прочете веднъж, и всеки ред променя кои маршрути попадат в таблицата.

Изпратена опция се държи по същия начин, щом пристигне, затова профилът на клиента може да не съдържа нищо, докато таблицата изглежда напълно пренасочена. Това е нормално: сървърът изпрати флаговете, клиентът ги приложи, а локалният файл никога не спомена директивата. Когато изпращането изглежда, че не прави нищо, проверете филтъра от страна на клиента, който приема или отхвърля изтеглените опции, защото отхвърлената опция не поражда грешка и от двете страни.

def1 печели чрез конкретност, без да пипа вашия маршрут по подразбиране

Два половин маршрута по подразбиране покриват заедно пространството IPv4, 0.0.0.0/1 и 128.0.0.0/1. Всеки от тях е по-конкретен от 0.0.0.0/0, затова търсенето ги предпочита, докато истинският маршрут по подразбиране остава в таблицата за всичко, което иска най-малко конкретното съвпадение.

Четете таблицата, а не профила, защото само таблицата показва в кой от тези случаи се намирате. Два реда са достатъчни, за да ги различите:

ip route show default
ip route show | grep -E '^(0\.0\.0\.0/1|128\.0\.0\.0/1)'

Обърнете внимание на интерфейса и метриката на всеки ред, не само на дестинацията. Маршрут по подразбиране, сочещ към тунела, и двойка половин маршрути, сочещи към тунела, описват едно и също намерение и се провалят по различен начин, когато тунелът падне, защото в единия случай резервният вариант все още съществува. Запишете и двете полета в бележката за промяната. Оцелелият резервен вариант понякога е това, което поддържа отдалечена сесия достатъчно дълго, за да се поправи тунелът, и също той изтича трафик, когато намерението е било пълен тунел.

Пазете крайната точка на тунела достъпна

Клиентът се нуждае от маршрут до далечния край на тунела, който сам по себе си не минава през тунела. OpenVPN инсталира този маршрут до хоста, преди да промени нещо друго, а ръчна редакция на маршрути или втори VPN клиент могат да го отнемат. Симптомът след това е връзка, която съобщава, че е свързана, и след това не пропуска нищо.

Попитайте ядрото кой интерфейс би използвало за адреса на крайната точка, докато тунелът е активен. Отговорът трябва да посочва физическия интерфейс и неговия шлюз, никога tun0:

ip route get 198.51.100.20

Ако това търсене връща устройството на тунела, тунелът носи собствения си транспорт и ще се срине, щом някой пакет трябва да излезе. Локалните префикси, вторият адаптер и маршрутизацията по политика все още имат значение тук, затова пренасочване, което работи на чист лаптоп, може да се провали на хост с интерфейс за управление и два маршрута по подразбиране. Обикновено обвиняват профила за това, което е направил планът на адресите.

Трафикът IPv6 продължава да ползва своята таблица

Пренасочването на IPv4 оставя IPv6 на мира и двете семейства се променят от различни флагове. На хост с двоен стек и работещ маршрут v6 по подразбиране трафикът v4 може да стои напълно вътре в тунела, докато всяка дестинация, способна на v6, излиза през физическата връзка. Хост, който изглежда правилен в една таблица, изтича в другата.

Проверете таблицата v6 след свързване, вместо да предполагате, че тунелът я е покрил. Директивата носи флагове за семейство адреси точно по тази причина, а профил, който ги пропуска, наследява това, което платформата прави по подразбиране:

ip -6 route show default
ip -6 route get 2001:db8::10

Докажете кой интерфейс използва приложението

Състоянието „свързано“ не е блокировка, а промяната на маршрут не е аварийно спиране. Ако директният трафик трябва да спре, когато тунелът се провали, тази политика живее в защитната стена и се нуждае от собствен тест.

Тествайте пътя, който приложението наистина изминава, а не пътя, който описва профилът. Първо поискайте маршрута, после свържете заявка към всеки интерфейс поред и сравнете какво съобщава далечната страна:

ip route get 203.0.113.10
curl -s --interface tun0 https://ifconfig.me
curl -s --interface eth0 https://ifconfig.me

Ако и двете заявки върнат един и същ адрес, приложението не използва тунела, дори таблицата за маршрутизация да казва, че трябва. Ако успее само заявката, свързана с тунела, физическият път е филтриран за тази дестинация и тунелът прави това, което сте поискали. Запишете флаговете, инсталираните маршрути, търсенето на крайната точка и двата резултата от изхода в записа за промяната, за да наследи следващият човек факти, а не екранна снимка.