TUN/TAP: неважечки аргумент — несовпаѓање на рамкирањето на OpenVPN

Клиентот се автентицира, дневникот вели поврзано, и ниту еден пакет не ја преминува тунелата. Серверот го завршува обидот со write to TUN/TAP: Invalid argument (code=22), што изгледа како дефект на управувачот и обично не е. На рутери и мали Linux сервери, таа линија најчесто значи дека двете страни не се согласуваат како се рамкираат податочните пакети, па јадрото го одбива дешифрираниот меѓубафер што му е предаден. Рутирањето во тој момент сѐ уште не е тестирано.

Точна табела за рутирање и раскинат договор за рамкирање изгледаат исто од страната на клиентот: поврзано, и ништо не работи.

Тунелата се крева и ништо не ја преминува

Грешките при пишување на уредот за тунела се случуваат по дешифрирањето и пред рутирањето. Демонот дешифрира пакет, му го предава на интерфејсот, и интерфејсот го одбива затоа што меѓубаферот не одговара на она што го очекува тој уред. Кодот 22 е општиот одговор за неважечки аргумент, па корисната информација е слојот: ова е патеката на податоците, а не ракувањето. Ако сообраќајот работеше вчера и запре денес без промена на конфигурацијата, сомневајте се во ажурирање на пакет или фирмвер што поместило стандардна вредност пред да се сомневате во мрежата.

Читајте го дневникот околу поставувањето на податочниот канал наместо првата грешка. Договорениот режим на компресија, типот dev и турнатите опции се појавуваат при поголема деталност, и тие ви кажуваат кое од трите несовпаѓања го имате.

Компресијата е рамкирање, не пропусен опсег

Кога компресијата е овозможена, секој податочен пакет носи заглавие што опишува како бил кодиран, и двата краја мора да се согласат за тоа заглавие. Сервер што сѐ уште носи comp-lzo од стара примерна конфигурација, спарен со клиент без линија за компресија, го создава токму овој проблем: серверот очекува заглавие што клиентот никогаш не го напишал. Мешањето на comp-lzo со compress lz4-v2 не успева на ист начин, бидејќи алгоритмите се разликуваат иако и двата се нарекуваат компресија. Опцијата е договор за рамкирање, а не функција за пропусен опсег на современите врски.

Однесувањето на верзиите додава стапица. Серијата 2.5 почна да издава предупредувања за застареност за опциите за компресија, а 2.6 повлекува граница помеѓу одбивање на компресирани пакети и едноставно оставање на податоците некомпресирани. Затоа ажурирањето на фирмверот на рутерот може да го смени фактичкиот договор без никој да ја уредува тунелата.

Порамнете ги двата краја или отстранете го од двата

Набројте ја секоја директива за компресија: серверската датотека, сите турнати опции, датотеките специфични за клиентот и профилот на клиентот. comp-lzo на серверот бара истиот збор на клиентот, а adaptive е наследната стандардна вредност што голата опција обично ја значи во постари изработки. GUI прекинувачот на рутерот означен LZO или компресија ја пишува истата опција, па поставете го да се совпаѓа наместо да мешате алгоритми. Не претпоставувајте дека слично име е компатибилно.

Ако компресијата не е посакувана, отстранете ја намерно од двата краја. allow-compression no на серверот одбива компресирани пакети, но само откако клиентите престанале да ги нудат; неговото применување додека клиент сѐ уште турка компресија повторно го создава несовпаѓањето во спротивната насока.

Проверете го туркањето и типот на уредот

Серверот може да турка директива за компресија од својата главна датотека или од датотека специфична за клиентот, а клиентот може да ги отфрли турнатите опции со pull-filter. Поврзете еден клиент при деталност 4, прочитајте што објавил серверот наспроти она што го прифатил клиентот, потоа потврдете дека ниту еден филтер не го отстранил. Ако двете страни сега се согласуваат, а грешката останува, погледнете го типот на уредот: dev tap на едниот крај и dev tun на другиот не можат да разменуваат рамки, и јадрото го одбива пишувањето на ист начин.

Распоредувањето TAP со мост бара вистински мост на серверот, не само друго име на уред. Преименувањето на интерфејс во tap0 без додавање на мост создава уред што го прифаќа пишувањето и не оди никаде.

Потоа проверете со еден клиент и една дестинација: пинг до адресата на тунелата на серверот, потоа до хост во неговата LAN. Првото го докажува податочниот канал, а второто препраќањето.