Динамичните клиенти се свързват и маршрутизират нормално, но единственият клиент с фиксиран адрес изобщо не достига до сървъра. В защитната стена нищо не е променено и редът в CCD изглежда правдоподобен. Обичайната причина е втори аргумент, написан за различна TUN топология от тази, с която работи сървърът. Отказът е тих: клиентът получава адрес и сървърът приема връзката, но трафикът не преминава.

При net30 това поле е адрес на партньора; при subnet е маска на подмрежата. Двете форми са алтернативи, никога последователност.

Двете форми, една до друга

При традиционно внедряване с net30 всеки клиент притежава блок /30: мрежов адрес, два използваеми адреса и broadcast адрес. ifconfig-push приема адреса на клиента и адреса на партньора, а партньорът е другият използваем адрес в същия блок, използван от сървърната страна на връзката точка-точка.

# net30: client address and its peer
ifconfig-push 10.99.0.6 10.99.0.5
# topology subnet: client address and the pool netmask
ifconfig-push 10.99.0.20 255.255.255.0

При topology subnet клиентът споделя една подмрежа със сървъра и същата директива приема адрес и маска на подмрежата. Собственият адрес на сървъра идва от директивата server, а не от второто поле. Смесването на формите създава клиент, който смята, че е на връзка точка-точка, докато сървърът го маршрутизира като хост в подмрежа, или обратното. Ето защо маска на подмрежата никога не бива да се съчетава с net30.

И двата реда в блока са единични редове за CCD файл. Всеки клиент получава точно един от тях.

Прочетете топологията, с която сървърът действително работи

Прочетете работещата конфигурация, а не подразбиращата се от пакета, защото топологията може да е зададена преди години и копирана напред. Търсете topology subnet или липсата му, след което проверете как редът server разпределя адреси. Конфигурация, която никога не споменава топология, не е същата като тази, която задава subnet.

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

Дръжте фиксирания адрес извън динамичния пул

Фиксираният адрес трябва да стои извън динамичния пул, иначе на двама клиенти може да бъде даден един и същ адрес. При топология subnet nopool на реда server потиска автоматичния пул, а явен диапазон ifconfig-pool определя какво получават динамичните клиенти.

dev tun
topology subnet
server 10.99.0.0 255.255.255.0 nopool
ifconfig-pool 10.99.0.100 10.99.0.210 255.255.255.0
client-config-dir /etc/openvpn/ccd

Сървърът взема 10.99.0.1 за себе си, а фиксираният адрес на клиента стои извън диапазона на пула. CCD файлът се именува по ефективната идентичност на клиента, а не по името на профилния файл, и не получава допълнително разширение. Ако username-as-common-name е активен, удостовереното потребителско име е идентичността, която трябва да се съпостави. Две устройства, които споделят една идентичност, ще споделят и фиксирания адрес, което е проблем на политика, а не на маршрутизация.

Проверете назначението, което клиентът действително е получил

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

Промяната на топологията засяга всеки клиент и всяко презаписване, затова я третирайте като миграция, а не като ремонт на един клиент. Коригирането на статичния ред към вече използваната топология обикновено е по-малката промяна. справката за server-options документира помощника и презаписванията, специфични за клиента.

Подобни статии