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 опција, што сигурно го запира целосниот тунел и исто толку сигурно ги крши приватните рути од кои зависи распоредувањето, па е многу поголем чекан од филтер по име насочен кон една опција. По секоја промена проверете го приватното одредиште, јавното одредиште и резолверот, и сметајте го завршеното ракување како доказ за ништо друго освен за ракувањето.