Две услужне адресе на једном 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" да сами науче одредиште.

Рутирање и ауторизација остају одвојени. Послата рута говори клијенту где да шаље пакете и ништа не даје; услуга и даље мора да прихвати позиваоца под својим условима.

Проверите политику улаза и повратни пут

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

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

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

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

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

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