Рутирање OpenVPN клиенти преку Cloudflare? Прво проверете ја улогата
Клиентот на уред не е рутер. Потврдете дека улогата на Cloudflare препраќа пакети на други домаќини, па задржете го сопствениот тунел на серверот на неговата стара патека.
Имате работен OpenVPN сервер и домаќин што го извршува и софтверот за уреди на Cloudflare, а следниот очигледен чекор изгледа како насочување на клиентскиот сообраќај кон него. Две работни врски на една машина не составуваат транзитна порта. Недостасува улога документирана за препраќање пакети што му припаѓаат на некој друг, и политика што ги класифицира тие пакети кога ќе пристигнат.
Пред секое правило стојат четири прашања: каков сообраќај влегува, каде оди понатаму, како одговорите го наоѓаат патот назад и што прави дизајнот кога таа втора патека не успева. Првите две се прашања за можности.
Две услуги на еден домаќин не се транзитна патека
Клиентот на уред е изграден да обработува сообраќај што настанува на машината каде што работи. Тој пресретнува разрешување на имиња или избран сообраќај на апликации и го испраќа низ сопствениот тунел, а неговата политика е напишана за корисникот на тој уред и за процесите на тој уред. Пакет препратен од OpenVPN клиент не е локален излез, па истите правила не го класифицираат. Тоа не е детаљ од конфигурацијата што може да се покрие со пошироко правило, зашто токму тоа одлучува дали софтверот воопшто го гледа пакетот.
Затоа прашањето за дизајнот е прашање за можности. Или инсталираниот производ има документирана улога што препраќа сообраќај за други мрежи, или транзитната функција припаѓа на сосема друго место.
Која улога на Cloudflare смее да препраќа
Клиентот за уреди на Cloudflare нуди режими што се разликуваат по опфат: само разрешување на имиња, сообраќај од уредот и понекогаш и двете. Ниту еден од тие режими не го претвора домаќинот во рутер за приватен опсег што пристигнува преку друг тунел. Посебната улога за рутирање е одделен производ со свој конектор, регистрација и мрежен модел.
| Question | What has to answer it |
|---|---|
| Does the installed product forward packets from other hosts? | A documented routing or connector role, not a device mode |
| Which prefixes does the connector advertise? | Its own configuration and status output |
| Does the server's own transport still take the old path? | ip route get for the endpoint, before and after |
| Do replies return through the same path? | Connection tracking counters on the forward rule |
Проверете ја инсталираната улога пред да дизајнирате рути околу неа. Прочитајте кој интерфејс го создава конекторот, дали објавува конкретни префикси или стандардна рута, и дали локалната политика важи за препратените пакети како и за локалните. Ако се обработува само локален сообраќај, OpenVPN серверот не може да биде транзитна точка, како и да е напишано правилото за преведување.
Овде исто така барањето за јавен излез мора да се формулира точно. Излезот што го обезбедува Cloudflare за препратен клиентски сообраќај е конкретен случај на употреба и треба да се потврди наспроти услугата што навистина ја имате.
Држете го надворешниот тунел независен од новата рута
Во мигот кога додавате стандардна рута кон новиот интерфејс, сопствениот излезен сообраќај на серверот почнува да се натпреварува за неа, а тоа вклучува одговори до OpenVPN клиентите и вашата SSH сесија кон машината. Обичниот симптом е тунел што се воспоставува и потоа умира, или администратор заклучен надвор додека промената изгледа како да проработела. Споредете ip route get за крајната точка пред и потоа, и користете рутирање засновано на политика или рута до домаќинот за да го задржите сопствениот транспорт на серверот таму каде што бил. Извршете го тоа споредување од самата машина, зашто сопствениот поглед на серверот за неговата рута е тој што е важен.
Исклучок за јавната адреса на серверот не е доволен сам по себе, зашто повратната патека на секој оддалечен администратор е различен тек. Одлучете кои од тие текови мора да ја преживеат промената, па потоа проверете го секој наместо да претпоставите дека првиот ги покрива останатите.
Ограничете го препраќањето и преведувањето на еден тек
Примените пакети ја следат патеката на препраќање, а не патеката на локален излез, затоа важното правило живее во forward-куката. Каде што следниот интерфејс бара преведување, ограничете го изворот на клиентскиот базен, одредиштето на дозволеното и излезот на тој единствен интерфејс. Правило masquerade врзано само за интерфејс не избира рута само по себе и не дозволува препраќање покрај ниеден друг филтер.
Одлучете го однесувањето при затворање при дефект однапред, па потоа тестирајте го. Запрете ја следната патека и потврдете дека клиентите го губат предвидениот излез наместо тивко да се вратат на вообичаениот нагорен канал, зашто тоа е резултатот што никој не го забележува додека сообраќајот не почне да излегува низ погрешната врата. Повторете ја проверката за разрешување на имиња и за IPv6, зашто множество правила само за v4 остава патека v6 отворена.
Запишете ги четирите одговори на кои застанавте и набљудувањето што го докажува секој. Транзитна патека што можете да ја опишете е онаа што можете да ја браните на следниот преглед на инциденти.