Два сервизни адреса на един OpenVPN клиент: iroute и lo

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

Псевдонимът е локален, собствеността е отдалечена

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

При клиента адресът принадлежи на хоста, а loopback е естественият дом за самоличност на услуга, която никога не бива да се появява на физическа връзка. В хъба съпоставянето на партньор към префикс е отделна декларация, която чете само сървърът. Нито един запис не предполага другия.

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

Добавете адреса на клиента трайно

Поставете адреса на услугата върху loopback с префикс за хост, така че хостът да го третира като локален вход, а не като подмрежа за достигане. ip address add 10.66.0.10/32 dev lo прави това за един адрес, а повторението на командата за втори адрес моделира две услуги.

Изпълнете това като еднократен тест, после го преместете там, което управлява мрежовата конфигурация на хоста, защото добавеното по време на работа изчезва при рестарт, а дубликатите се натрупват между пресвързванията. systemd unit, подреден след мрежата, е една опция, а мрежовият мениджър на дистрибуцията е друга. Което и да изберете, адресът трябва да съществува преди приложението да се свърже, иначе услугата излиза на грешния сокет. Проверете с ip address show dev lo след рестарт, а не след ръчната команда.

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

Заявете го във файла CCD, който хъбът действително чете

На сървъра декларацията за собственост отива във файла за клиента, избран от удостовереното общо име, в директорията, посочена от client-config-dir. Редът е iroute 10.66.0.10 255.255.255.255, по един на адрес, и казва на сървъра кой партньор трябва да получава трафика за тази дестинация.

Две подробности развалят това тихо. Името на файла трябва да съвпада с името, което сървърът наистина използва, а то се различава, когато участва username-as-common-name. И iroute действа само в режим TUN с конфигурирана директория за клиентска конфигурация, така че същият ред не прави нищо при мостово внедряване. Добавяйте редове към съществуващия файл, вместо да го заменяте, защото той може вече да носи фиксиран адрес или push опции. Справочникът на OpenVPN 2.6 документира и директорията, и директивата за собственост.

Собственото ядро на хъба също се нуждае от път до тези дестинации, за да влиза локално генерираният трафик в процеса на тунела. route 10.66.0.10 255.255.255.255 в конфигурацията на сървъра покрива трафика, който сървърът създава, докато другите клиенти се нуждаят от push "route 10.66.0.10 255.255.255.255", за да научат дестинацията сами.

Маршрутизирането и оторизацията остават отделни. Изпратеният маршрут казва на клиента къде да праща пакети и не дава нищо; услугата все още трябва да приеме извикващия при свои условия.

Проверете политиката за вход и пътя на отговора

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

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

Внимавайте за втори слушател на същия порт, вързан към различен адрес, защото ядрото доставя до който сокет съвпадне и резултатите изглеждат случайни. Проверете с ss -lntp и потвърдете, че вързаният адрес е псевдонимът на услугата. NAT на източника не е необходим тук и добавянето му скрива самоличността на извикващия, от която зависят журналите ви.

Тествайте адресите и собствеността поотделно

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

Проверете и режимите на отказ, които надживяват връзката: псевдонимът остава зададен, когато тунелът е спрян, а хъбът пази маршрута си, когато партньорът отсъства. Никой обект сам по себе си не доказва, че услугата е достъпна, затова тестът на две стъпки бие един ping от лаптоп.