Један Pi, две OpenVPN инстанце: шта чита свака јединица
Два OpenVPN демона на једном Pi читају различите конфигурационе датотеке и излазе кроз различите куке. Мапирајте сваку инстанцу, а затим одвојено тестирајте путању корисног терета.
Пребројте OpenVPN процесе пре него што додирнете профил. Pi који прихвата роаминг кориснике и истовремено позива услугу на вишем нивоу покреће два демона, и сваки од њих чита конфигурациону датотеку коју бира име инстанце које сте унели. Предлошци пакета затим сваком демону дају сопствени радни директоријум, сопствену датотеку стања извршавања и сопствени тунелски уређај. Ако ову поделу урадите погрешно, провешћете вече мењајући исправно подешавање у датотеци коју процес који ради никада не отвара.
Свако име инстанце бира сопствену датотеку
У датотекама јединица које долазе са OpenVPN 2.6, аргументи за покретање носе заменско место инстанце које се попуњава текстом након знака @. Предложак сервера ради из конфигурационог директоријума сервера и решава свој аргумент према тамошњем %i.conf, док предложак клијента чини исто из директоријума клијента. Зато [email protected] чита admits.conf у директоријуму сервера, а [email protected] чита uplink.conf у директоријуму клијента, и ниједно од тих имена нема никакво значење у другом директоријуму.
Потврдите мапирање на самом строју уместо да претпоставите да је пакет задржао подразумеване вредности вишег нивоа. Drop-in дистрибуције сме у потпуности да замени радни директоријум или конфигурациони аргумент.
systemctl cat [email protected]
systemctl cat [email protected]Прочитајте ред WorkingDirectory и конфигурациони аргумент у том излазу, јер само омогућена јединица одлучује која се датотека учитава. Drop-in који додаје --config на ExecStart побеђује предложак чак и када путања предлошка изгледа исправно. Затражите путање фрагмената и drop-in-ова када желите да знате да ли је на делу локално преписивање. Ако се обе улоге решавају на једну датотеку, имате један процес који покушава да буде и сервер и клијент, а каснија опција у тој датотеци тихо побеђује.
Локални транспорт и прослеђени терет ударају у различите куке
Шифрована веза сервера са сваким роаминг корисником ствара се на самом Pi, па његови спољашњи одговори излазе кроз локалну излазну куку. Веза клијента са његовим партнером на вишем нивоу такође је локално створен излаз, иако достиже удаљену мрежу. Прослеђени корисни терет је трећа категорија, а језгро га упарује тек након што је већ одабрало излазни уређај за пакет.
| Flow | Hook that sees it | What to inspect |
|---|---|---|
| Roaming user handshakes to the server | Local input and local output | Listener socket, bind address, rule admitting the UDP port |
| User payload leaving through the upstream tunnel | Forward | IPv4 forwarding switch, selected route, permission rule, any translation |
| Pi's own connection to the upstream peer | Local output | Underlay route to the provider endpoint, not the tunnel route |
Правило које унутар forward ланца одговара излазном интерфејсу може да дозволи или одбаци пакет који је усмеравање већ доделило том интерфејсу, али никада не бира интерфејс. Када један хост заврши један тунел и започне други, политика која шаље кориснички терет у тунел вишег нивоа и политика која штити сопствене шифроване одговоре Pi две су одвојене одлуке. Оне случајно заврше на истој физичкој NIC, зато се бркају.
Та разлика објашњава чест половни квар. Корисници се повежу, руковање се доврши, а њихов саобраћај и даље излази погрешним путем, јер је руковање било локално, а терет прослеђен и само једно од двога је икада тестирано.
Увезена путања може прогутати одговоре вашим корисницима
Безбедносно подешавање профила клијента одлучује шта виши ниво сме да угура у таблицу усмеравања Pi, а широко преусмеравање је опција која функционални хост са двојном улогом претвара у покварен. Ако угурана путања покрива јавне адресе роаминг корисника, одговори које сервер ствара према њима могу да прате нову путању у тунел вишег нивоа уместо да изађу кроз доњи слој. Људи често потврде да тунел према провајдеру још ради и зауставе се на томе, јер је тај саобраћај властити превоз тунела и наставља да тече док се све остало понаша погрешно.
Политика заснована на извору или mark ознаци начин је да два тока остану одвојена. OpenVPN-ова Linux mark опција означава властите шифроване пакете демона ознаком заштитног зида, коју усмеравачко правило затим може да пошаље у наменску таблицу. Изворне адресе раде једнако добро када спољашњи одговори сервера увек излазе са једне адресе доњег слоја. Оба приступа траже ваљане путање у таблици коју одаберу и изузетак за endpoint провајдера, иначе се сам тунел више не диже.
Питајте језгро којим би путем одговор заиста кренуо пре него што напишете било које правило. Адресе испод су заменска места за адресу доњег слоја Pi и јавну адресу једног роаминг корисника.
ip rule show
ip route get 198.51.100.7 from 192.0.2.10Проверите поделу, па заустављајте једну улогу одједном
Тестирајте три тока одвојено, јер успешно руковање ништа не доказује о друга два. Прихватите нову долазну везу, пошаљите једну дозвољену апликацију кроз излаз вишег нивоа и потврдите да оба процеса још достижу своје партнере.
Затим зауставите улогу клијента и посматрајте шта улога сервера задржава. То је најјефтинији начин да пронађете правило путање или mark ознаке које је било намењено једној инстанци, а примењено на обе.
systemctl stop [email protected]
systemctl status [email protected] --no-pager
ss -lunp | grep openvpn
journalctl -u [email protected] -n 20 --no-pagerЖелите да видите да је слушалац још везан, тунелски уређај још присутан и дневник без нових грешака док је улога клијента заустављена. Ако заустављање клијента прекине и одговоре сервера постојећим корисницима, две улоге деле нешто што је требало бити ограничено на једну од њих. Забележите коју инстанцу, коју конфигурациону датотеку и ког власника тока је свака промена дотакла, јер ће иначе следећа особа која отклања грешке на овом хосту поновити исто откриће од нуле.