OpenVPN iroute наспроти рута во јадрото: која недостасува?

Пакетот за 10.77.20.0/24 носи две одделни одлуки на OpenVPN сервер: оперативниот систем мора да го предаде на VPN интерфејсот, а OpenVPN мора да знае кој поврзан клиент го поседува тој префикс. Рута во јадрото што недостасува го отфрла пред тунелот, а рута на партнерот што недостасува го отфрла потоа. Двете грешки изгледаат исто од далечната LAN, а дијагностицирањето која ја имате бара по една команда на секоја страна.

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

Две одлуки, не една рута

Замислете врска од локација до локација каде 10.77.20.0/24 стои зад еден клиент. Рутата во јадрото на серверот, на пример ip route add 10.77.20.0/24 dev tun0, ги испраќа соодветните пакети до уредот на тунелот. Потоа OpenVPN ја разгледува сопствената внатрешна табела, изградена од iroute записите во директориумот со конфигурација на клиентот, за да одлучи која врска со партнер ќе ги прими. Без рутата во јадрото пакетот никогаш не стигнува до процесот, а без рутата на партнерот стигнува до процесот и не оди никаде.

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

Каде припаѓа iroute и што кажува

Записот оди во датотека по клиент именувана по common_name на клиентот, под client-config-dir, како iroute 10.77.20.0/24. Совпаѓањето на името на датотеката не е козметичко: OpenVPN ја бара автентифицираната идентитет и ја чита датотеката токму со тоа име, па датотека со име site-a важи само за клиент чие заедничко име е site-a. Додајте ccd-exclusive ако клиентите без таква датотека треба целосно да се одбијат, што е правилното поставување кога секој клиент е порта на локација. Држете една датотека по порта и именувајте ја по субјектот на сертификатот што навистина го издавате.

Тестирајте го записот од серверот пред да ја обвините далечната LAN. Статусната датотека ги наведува поврзаните клиенти со нивните заеднички имиња, а серверот што работи со --verb 4 го запишува инсталирањето на iroute во моментот кога партнерот се поврзува. Ако при поврзувањето не се појави ништо, датотеката е во погрешен директориум или наведува погрешен идентитет.

Стапицата: датотеката е тука, идентитетот е погрешен

Правилно изгледачки iroute прикачен на погрешен партнер губи повеќе време од датотека што недостасува, бидејќи на дискот сето изгледа правилно. Преименување сертификати, дупликат заеднички имиња и username-as-common-name што го менува ефективниот идентитет сето тоа го создаваат. Проверете кој идентитет го автентифицираше серверот, наместо кој го очекувавте: статусниот излез е меродавен, а името на датотеката е само клуч за пребарување.

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

Довршете ја патеката зад партнерот

Сопственоста над партнерот е средината на патеката, не крајот. Клиентот мора да ги проследува пакетите од тунелот во својата LAN, што значи овозможено проследување на IP на тој домаќин и правило на огнен ѕид што го дозволува преминот. Домаќините во далечната LAN треба да имаат повратна патека за адресата на тунелот: или рута што покажува назад кон портата, или намерно проектиран NAT на страната на клиентот. Потврдете го поставувањето за проследување на клиентот со sysctl net.ipv4.ip_forward, наместо да претпоставувате стандардна вредност на дистрибуцијата.

Ако други VPN клиенти треба да стигнат до таа подмрежа, распоредот повторно расте: на серверот му треба client-to-client, а тие клиенти треба да го насочуваат префиксот низ тунелот. Ништо од тоа не произлегува од сопствената табела на рути на серверот.

Проверете една дестинација од вистински извор, а не од самиот сервер. Ping од неврзана LAN домаќин до домаќин зад клиентот вежба повратната патека, правилото за проследување и сопственоста над партнерот во еден потег, додека успешното ракување докажува само идентитет. Потоа исклучете го партнерот сопственик и запишете што прави рутата, бидејќи тој одговор е вашиот начин на откажување.