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

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

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

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

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

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

Додајте ја адресата кај клиентот трајно

Поставете ја услужната адреса на loopback со префикс на домаќин, за домаќинот да ја третира како локален влез, а не како подмрежа што треба да се достигне. ip address add 10.66.0.10/32 dev lo го прави тоа за една адреса, а повторувањето на командата за втора адреса моделира две услуги.

Извршете го тоа како еднократен тест, потоа преместете го во она што ја поседува мрежната конфигурација на домаќинот, бидејќи додатокот за време на работа исчезнува при рестарт, а дупликатите се собираат меѓу повторните поврзувања. systemd единица подредена по мрежата е една опција, а мрежниот менаџер на дистрибуцијата е друга. Што и да изберете, адресата мора да постои пред апликацијата да се поврзе, инаку услугата крева на погрешниот сокет. Проверете со 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" за сами да ја научат дестинацијата.

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

Проверете ја влезната политика и патот на одговорот

Пакет упатен до псевдонимот пристигнува кај домаќинот што го поседува како локален влез, па прашањето е дали локалниот firewall го дозволува тој извор и порта. Дозволете ја конкретната услужна порта од опсегот на VPN извори наместо да ја отворите целата адреса.

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

Внимавајте на втор слушател на истата порта поврзан со друга адреса, бидејќи јадрото доставува до сокетот што се совпаѓа и резултатите изгледаат случајни. Проверете со ss -lntp и потврдете дека поврзаната адреса е псевдонимот на услугата. NAT на изворот тука не е потребен, а неговото додавање ја крие идентитетот на повикувачот од кој зависат вашите дневници.

Тестирајте ги адресите и сопственоста одделно

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

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