Бір Pi, екі OpenVPN данасы: әр юнит нені оқиды
Бір Pi-дегі екі OpenVPN демоны әртүрлі конфигурация файлдарын оқып, әртүрлі ілмектер арқылы шығады. Әр дананы сәйкестендіріп, содан кейін пайдалы жүктеме жолын бөлек тексеріңіз.
Профильге қол тигізбес бұрын OpenVPN процестерін санаңыз. Роуминг пайдаланушыларын қабылдайтын және сонымен бірге upstream қызметіне қосылатын Pi екі демонды іске қосады, және олардың әрқайсысы сіз терген дана атымен таңдалған конфигурация файлын оқиды. Пакеттің үлгілері содан кейін әр демонға жеке жұмыс каталогын, жеке runtime күй файлын және жеке туннель құрылғысын береді. Бұл бөлуді қате жасасаңыз, жұмыс істеп тұрған процесс ешқашан ашпайтын файлдағы дұрыс параметрді өзгертуге бір кеш жұмсайсыз.
Әр дана аты өз файлын таңдайды
OpenVPN 2.6-мен жеткізілетін unit файлдарында іске қосу аргументтерінде @ белгісінен кейінгі мәтінмен толтырылатын дана орынбасары бар. Сервер үлгісі сервер конфигурация каталогынан жұмыс істеп, өз аргументін сол жердегі %i.conf бойынша шешеді, ал клиент үлгісі дәл солай клиент каталогынан жасайды. Сондықтан [email protected] сервер каталогындағы admits.conf файлын оқиды, ал [email protected] клиент каталогындағы uplink.conf файлын оқиды, және екі атаудың ешқайсысы басқа каталогта ешбір мағынаға ие емес.
Пакет upstream әдепкілерін сақтады деп ойламай, сәйкестікті машинада растаңыз. Дистрибутивтің drop-in қосымшасы жұмыс каталогын немесе конфигурация аргументін толығымен ауыстыра алады.
systemctl cat [email protected]
systemctl cat [email protected]Сол шығыстағы WorkingDirectory жолын және конфигурация аргументін оқыңыз, өйткені қай файл жүктелетінін тек қосылған unit шешеді. ExecStart ішіне --config қосатын drop-in үлгі жолы дұрыс көрінсе де үлгіден басым түседі. Жергілікті қайта анықтау бар-жоғын білгіңіз келсе, фрагмент пен drop-in жолдарын сұраңыз. Егер екі рөл де бір файлға шешілсе, сізде бір процесс сервер де, клиент те болуға тырысады, және сол файлдағы кейінгі опция үнсіз басым түседі.
Жергілікті көлік пен қайта жіберілген жүк түрлі ілмектерге тиеді
Сервердің әр роуминг пайдаланушыға шифрланған қосылымы Pi-дің өзінде жасалады, сондықтан оның сыртқы жауаптары жергілікті output ілмегі арқылы шығады. Клиенттің upstream теңдесіне қосылымы да жергілікті жасалған output болып табылады, тіпті ол қашықтағы желіге жетсе де. Қайта жіберілетін пайдалы жүктеме үшінші санат, және ядро оны пакет үшін шығу құрылғысын таңдап қойғаннан кейін ғана сәйкестендіреді.
| 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 тізбегіндегі шығу интерфейсіне сәйкес келетін ереже маршруттау әлдеқашан сол интерфейске тағайындаған пакетті рұқсат ете алады немесе тастай алады, бірақ ол интерфейсті ешқашан таңдамайды. Бір хост бір туннельді аяқтап, екіншісін бастағанда, пайдаланушы жүктемесін upstream туннеліне жіберетін саясат пен Pi-дің өз шифрланған жауаптарын қорғайтын саясат — екі бөлек шешім. Олар кездейсоқ бір физикалық NIC-ке түседі, сондықтан шатастырылады.
Бұл айырмашылық жиі кездесетін жартылай сәтсіздікті түсіндіреді. Пайдаланушылар қосылады, handshake аяқталады, бірақ трафигі әлі де дұрыс емес жолмен шығады, өйткені handshake жергілікті, ал жүктеме forward болды және екеуінің тек біреуі ғана тексерілді.
Импортталған маршрут пайдаланушыларыңызға жауаптарды жұтып қоюы мүмкін
Клиент профилінің қауіпсіздік параметрі upstream-тың Pi маршруттау кестесіне нені push ете алатынын шешеді, ал кең redirect — жұмыс істеп тұрған қос рөлді хостты бұзылғанға айналдыратын опция. Егер push етілген маршрут роуминг пайдаланушыларының жария мекенжайларын қамтыса, сервер оларға қарай жасайтын жауаптар underlay арқылы шығудың орнына жаңа маршрутпен upstream туннеліне кіруі мүмкін. Адамдар провайдерге туннель әлі жұмыс істейтінін растап, сонда тоқтайды, өйткені бұл трафик туннельдің өз көлігі және қалғанының бәрі дұрыс емес әрекет еткенде де ағып тұрады.
Көз немесе mark негізіндегі саясат — екі ағынды бөлек ұстаудың жолы. OpenVPN-ның Linux mark опциясы демонның өз шифрланған пакеттеріне firewall mark қояды, содан кейін маршруттау ережесі оны арнайы кестеге жібере алады. Бастапқы мекенжайлар да дәл сондай жақсы жұмыс істейді, егер сервердің сыртқы жауаптары әрқашан бір underlay мекенжайынан шықса. Екі тәсілге де таңдалған кестеде жарамды маршруттар және провайдер endpoint-і үшін ерекшелік қажет, әйтпесе туннельдің өзі көтерілмейді.
Кез келген ереже жазбас бұрын, жауап шын мәнінде қандай жолмен жүретінін ядродан сұраңыз. Төмендегі мекенжайлар — Pi-дің underlay мекенжайы мен бір роуминг пайдаланушысының жария мекенжайы үшін орынбасарлар.
ip rule show
ip route get 198.51.100.7 from 192.0.2.10Бөлуді тексеріңіз, содан кейін рөлдерді бір-бірлеп тоқтатыңыз
Үш ағынды бөлек тексеріңіз, өйткені сәтті handshake қалған екеуі туралы ештеңе дәлелдемейді. Жаңа кіріс қосылымын қабылдаңыз, бір рұқсат етілген қолданбаны upstream шығысы арқылы жіберіңіз және екі процесс те өз теңдестеріне әлі жететінін растаңыз.
Содан кейін клиент рөлін тоқтатып, сервер рөлі нені сақтайтынын бақылаңыз. Бұл бір данаға арналған, бірақ екеуіне де қолданылған маршрут немесе mark ережесін табудың ең арзан жолы.
systemctl stop [email protected]
systemctl status [email protected] --no-pager
ss -lunp | grep openvpn
journalctl -u [email protected] -n 20 --no-pagerКөргіңіз келетіні — клиент рөлі өшіп тұрғанда listener әлі байланған, туннель құрылғысы әлі бар және журналда жаңа қателер жоқ. Егер клиентті тоқтату сервердің қазіргі пайдаланушыларға жауаптарын да үзсе, екі рөл біреуіне ғана шектелуі тиіс нәрсені ортақ пайдаланады. Әр өзгеріс қай данаға, қай конфигурация файлына және қай ағын иесіне тигенін жазып қойыңыз, әйтпесе бұл хостты келесі жөндейтін адам сол ашылуды нөлден қайталайды.