Нуждае ли се всеки OpenVPN peer от ред remote? Не съвсем

Две peer конфигурации се сравняват една до друга, едната има ред remote, другата не, и изводът е, че една от тях е счупена. Този извод е грешен достатъчно често, за да си струва да бъде разгледан. Директивата описва накъде трябва да бъде изпратен първият пакет. Тя не избира дали процесът действа като иницииращ клиент или като изчакващ шлюз и не решава коя страна доказва самоличността си пред другата.

Какво всъщност задава remote

Записът remote посочва хост, по избор порт и транспорт и по избор няколко такива записа, които се опитват поред.

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

Четете записа като връзка между адреси. Дали далечната страна е доверена, се решава от сертификатите и опциите за проверка, а не от факта, че адресът е записан.

Три подредби решават отговора

Роуминг клиентът се нуждае от дестинация, защото трябва да инициира и без нея не знае къде е шлюзът. Шлюзът за много клиенти не се нуждае от дестинация за всеки потребител, защото клиентите пристигат и се автентикират. Умишлена връзка между два peer с известни крайни точки може да има дестинация от едната страна, от двете страни или от никоя, в зависимост от това коя страна инициира.

Поставянето на фиксиран клиентски адрес в общ шлюз е грешката, която следва от пренебрегването на тези категории. Тя работи за единствения peer, чийто адрес е записан, и подвежда всички останали.

Нищо в директивата не превръща конфигурация в сървър за много клиенти и нищо в присъствието ѝ не пречи на сървърна роля. Справката за OpenVPN 2.6 документира незадължителните аргументи и поведението без remote поотделно, което е подсказка колко независими са те.

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

При TCP едната страна изчаква, а другата набира. Това са отделни директиви от дестинацията и смесването им дава двойка, в която и двете изчакват или и двете набират.

Има и роля на TCP филтър на източника, поради което плоското твърдение, че сървър никога не може да съдържа remote, е грешно.

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

Защо липсващият remote не е отворена врата

Процес без дестинация все пак отказва трафик от peer, които не се автентикират, и точно това се пропуска, когато липсващият ред се чете като слушател, отворен за всеки.

Автентикацията и дестинацията са независими и първата е тази, която има значение за доверието.

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

Запишете какво предполага конфигурацията

За всяка страна запишете три неща: как първият пакет достига до peer, коя страна може да приеме транспорта и какво проверява всяка страна за другата.

Тези предположения са дизайнът. Директивите са само тяхното изписване.

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