Зошто маршрутата на целосен тунел го отсекува серверот што го носи

Вклучете целосен тунел и секоја дестинација сега му припаѓа на VPN интерфејсот, вклучително и машината што го завршува. Надворешните пакети што го носат тунелот се адресирани до таа машина, па маршрутата на крајот го троши транспортот од кој зависи. Една дополнителна конкретна маршрута го решава тоа, и причината вреди да се разбере. Без таа причина следното преизградување повторно ја внесува грешката.

Маршрута што го јаде сопствениот транспорт

Инкапсулацијата го завиткува секој пакет во второ заглавие. Надворешното е адресирано од локалната физичка адреса до јавната адреса на серверот, и мора да ја премине физичката врска пред да може да постои било кој тунел.

Сега дозволете пребарувањето за таа јавна адреса да го избере тунелот. За да го испрати пакетот, машината мора да го инкапсулира, што бара маршрута до истата адреса, која го враќа тунелот. Клиентите го решаваат ова пред сѐ на еден од два начина. Внимателниот одбива да ја инсталира стандардната маршрута и пријавува грешка, додека помалку внимателниот пријавува успех и потоа не поместува ништо. Тивкиот неуспех е тој што чини едно попладне.

Совпаѓањето на најдолгиот префикс ја одлучува пребарувањето пред да се погледне која било метрика, па маршрутата за една адреса ги надминува сите стандардни маршрути на машината. Тоа е целиот механизам зад поправката.

Инсталирајте го исклучокот пред стандардната

Создадете маршрута за една адреса за серверот, со физичката порта како следен скок, пред да се помести стандардната маршрута. Редоследот е важен: инсталирање потоа значи живеење со расипан тунел додека пишувате.

Повеќето клиенти го прават ова без барање. OpenVPN ја бара оддалечената адреса и ја закачува пред да ја препише стандардната порта, а неговата опција route-delay постои за платформи каде таа низа се трка. wg-quick тргнува по сосема друг пат, означувајќи пакети и консултирајќи правило за политика наместо да додаде исклучок. Различни механизми, исто барање: надворешниот пакет мора да избега од тунелот што самиот го создава.

ip route add 203.0.113.10/32 via 192.168.1.1 dev eth0
ip route get 203.0.113.10

Излезот од пребарувањето е тестот за прифаќање. Мора да го наведе физичкиот уред и физичкиот следен скок. Уред за тунел во тој одговор значи дека исклучокот недостасува или е поставен по нешто што го надминува.

Огледалната слика на серверот

Истата стапица чека на другата страна, обратно. Дајте му на серверот стандардна маршрута преку друг тунел, или турнете му маршрута што ги покрива јавните адреси на клиентите, и неговите одговори ќе добијат навика за погрешен правец.

Замислете клиент што се поврзува и испраќа барање. Одговорот е адресиран до јавната адреса на тој клиент, која сега се совпаѓа со маршрута на тунелот, па излегува од друг интерфејс носејќи извор што клиентот никогаш не го избрал. Клиентот може да го прими тој пакет и сепак да го отфрли, зашто ништо не го врзува за барањето што го испратил. Тргнете од одлуката за рутирање на серверот, а не од тајмаутот на клиентот, бидејќи само едното од двете го покажува вистинскиот избор.

ip route get 198.51.100.44 from 10.90.0.1
ip rule show
sudo tcpdump -ni any host 198.51.100.44

Постојат три поправки и тие не се рамноправни. Закачувањето на услугата за физичката адреса или преведувањето на изворот, двете ја кријат одлуката за рутирање наместо да ја исправат. Испраќањето на сообраќајот со одговори за базенот на тунелот низ посебна табела ја исправа причината, а другите две се прифатливи само додека дизајнот на рутирање е замрзнат.

Исклучоци што тунелот сѐ уште ги краде

Неколку задачи бараат отворен интернет дури и кога тунелот ја поседува стандардната маршрута, и секоја бара свој исклучок. Ажурирачот на динамичен DNS обично прв се расипува.

Тој го решава провајдерот, отвора врска и открива дека сопствените пакети патуваат низ тунел чија адреса се сменила пред секунди, па ажурирањето не успева или ја објавува погрешната адреса. Три излези: закачете го провајдерот со маршрута до домаќин низ физичката порта, стартувајте го ажурирањето пред тунелот да се крене или дајте му на ажурирачот табела за политика што тунелот никогаш не ја допира. Синхронизацијата на време ја има истата изложеност на уред што стартува без resolver, а крајните точки за проверка на сертификати припаѓаат на списокот од истата причина.

Исклучок што никој не го запишал е исклучок што следното преизградување тивко ќе го испушти.

Докажете го по повторно поврзување, не пред тоа

Тестирајте три дестинации, не една: крајната точка, приватна адреса зад тунелот и јавна адреса надвор од него. Едно успешно пребарување речиси ништо не кажува за другите две.

ip route get 203.0.113.10
traceroute -n 203.0.113.10
ip route get 10.90.0.5
ip route get 1.1.1.1

Потоа рестартирајте ја врската, зашто клиент што ја преизградува табелата при повторно поврзување ќе ја отфрли маршрутата што сте ја впишале рачно. Ако има kill switch, проверете дали крајната точка е дозволена, инаку тунелот не може да се врати по промена на мрежата и симптомот личи на прекин. Чувајте го исклучокот во профилот или unit датотеката, а не во историјата на shell, за да го пресоздаде повторното поврзување наместо да го избрише.