OpenVPN клиентот застанува кога неговиот сервер работи на истиот хост

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

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

Прочитајте го симптомот наназад

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

Двата случаи произведуваат иста поплака од корисникот, затоа циклусите за повторен обид и скриптите за надзор не поправаат ништо. Тие го поврзуваат клиентот повторно во истиот конфликт. Корисното прво прашање е дали процесот сѐ уште работи кога сообраќајот запира.

Еден сокет и еден уред по инстанца

Сервер што слуша го врзува својот порт; на излезниот клиент исто така му треба локален порт за неговиот инкапсулиран сообраќај. Кога двата живеат на истиот хост, стандардното однесување на клиентот може да се судри со портот на серверот. Локалниот порт на клиентот може да се закачи, а врзувањето може да се прескокне таму каде партнерот не бара фиксен изворен порт:

lport 1195
nobind
dev tun1

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

nobind и припаѓа на клиентската страна. Серверот сѐ уште мора да врзува и слуша, затоа не копирајте ја линијата во конфигурацијата на серверот и не исклучувајте врзување на клиент чиј партнер филтрира на фиксен изворен порт.

Изберете еден сопственик за стандардната рута

Само една врска може да инсталира стандардна рута. Ако двата профила го пренасочуваат целиот сообраќај, втората врска тивко ја заменува првата, и првата изгледа расипана. Или задржете го излезниот тунел поделен и туркајте само префиксите на добавувачот, или дајте му посебна табела за рутирање.

ip rule add from 10.9.0.2 table 120
ip route add default dev tun1 table 120
ip route get 10.9.0.2

Адресите и бројот на табелата погоре се места за пополнување. Веднаш откако ќе го додадете правилото, потврдете дека адресата на самиот VPN сервер сѐ уште се решава преку нормалната табела; табела што го фаќа надворешниот транспорт го крши тунелот што требало да го заштити, а циклусот за повторно поврзување што следи изгледа како несигурен провајдер.

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

Проверете со табелата, не со линијата за статус

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

ip route show
ip route get 10.40.0.20
ss -lunp | grep 1194

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

Запишете ги портовите, уредите, табелите и сопственикот на рутата во runbook на хостот. Инаку следниот човек што ќе додаде трет тунел повторно ќе ја открие истата судирка, а единствениот видлив доказ ќе биде врска што работи додека некој друг не го рестартира својот демон.