Сервер же кардар: кош ролдуу Pi'де кайсы OpenVPN бирдиги
Эки OpenVPN нускасы бир Pi'ни бөлүшөт: бири кыдырма колдонуучуларды кабыл алат, экинчиси жогорку провайдерге туташат. Экөөнүн бирин кайра баштоодон мурун бирдиктин атын жана каталогун окуңуз.
Pi'де бир убакта кыдырма колдонуучуларды кабыл алган жана жогорку провайдерге жеткен эки OpenVPN процесси иштейт, жана алар аппараттык камсыздоодон башка дээрлик эч нерсе бөлүшпөйт. Бири кирүүчү туннелдерди угат, экинчиси сыртка чалат. Ар бири өз каталогун окуйт жана ар биринин өз иштинен чыгуу режими бар. Туура эмес бирдикти кайра баштоо — кардарды оңдоо ордуна угуучуну чайкаган эң кеңири тараган жол.
Бирдиктин атын ал жүктөгөн каталог менен шайкеш келтириңиз
Upstream 2.6 эки үлгү бирдигин сунуштайт: [email protected] жана [email protected]. Сервер үлгүсү /etc/openvpn/server ичинде башталат жана ал жерден %i.conf жүктөйт. Кардар үлгүсү /etc/openvpn/client ичинде башталат. roaming аттуу нуска бир убакта эки жерде тең болушу мүмкүн — сервер жана кардар катары, эки байланышсыз конфигурация менен жана алардын ортосунда саптан башка эч кандай байланыш жок.
Файл системасынан эмес, systemd'ден сураңыз, анткени пакет жасоочулар жумуш каталогун же бинардык файл алган аргументтерди өзгөртө ала турган кошумча файлдарды кошот.
systemctl list-units --type=service 'openvpn-*@*' systemctl cat [email protected] systemctl show -p WorkingDirectory -p ExecStart [email protected]
Биринчи буйрук ар бир түзүлгөн бирдикти тизмелейт, анын ичинде ийгиликсиз болуп, жүктөлгөн бойдон калгандар да бар. Экинчиси бирдиктин файлын кандайдыр бир кайра аныктоо менен бирге басып чыгарат. Үчүнчүсү — суроону чечкен эки фактыны көрүүнүн эң тез жолу: процесстин башталган каталогу жана ага берилген конфигурация жолу.
Пакеттин багыты боюнча чечиңиз, интерфейстин аты боюнча эмес
Сервер нускасы угуучу сокетке ээ жана туташууларды кабыл алат. Анын шифрленген транспорту Pi'де жергиликтүү кирүү жана жергиликтүү чыгуу болуп саналат, ал эми колдонуучулар үчүн жиберген трафик жиберүү жолун ээрчийт жана эрежелердин башка топтомуна баш ийет. Кардар нускасынын бул мааниде угуучусу жок: ал шеригине чалат, ошондуктан анын шифрленген транспорту төмөнкү катмарга карай жергиликтүү чыгуу.
Бул айырма эреженин кайда таандык экенин айтат. Жиберүү чынжырынын ичиндеги интерфейске дал келген эреже маршруттоо мурун тандаган трафикке гана уруксат берет; ал эч качан маршрутту тандабайт. Кыдырма колдонуучунун пакеттери туура эмес жол менен чыкканда, текшериле турган чынжыр — forward, output эмес.
Теория куруудан мурун сокеттерди караңыз. udp/1194'ке байланган сервер угуучу сокетти көрсөтөт. Кардар провайдердин дареги менен байланышты көрсөтөт жана уга турган эч нерсе жок.
ss -lunp | grep openvpn ss -unp state established '( dport = :1194 or sport = :1194 )'
Бир нусканын демейки маршруту экинчисинин жоопторун кармап алышы мүмкүн
Жогорку кардар түрткөн redirect-gateway башка бардык нерселер менен атаандашкан демейки маршрутту орнотот, анын ичинде сервердин кыдырма колдонуучуларга жиберген жооптору да бар. OpenVPN туннель жеткиликтүү бойдон калышы үчүн өз шерик дарегине өзгөчөлүк жасайт, бирок бул өзгөчөлүк мейманкана тармагында отурган телефон тууралуу эч нерсе айтпайт.
Симптом адатта асимметриялуу. Кол алышуу бүтөт, кардар туташканын билдирет, ал эми трафик биринчи жооп пакетинен кийин өлөт. Булакка негизделген саясат маршруттоосу же сервер нускасында --mark аркылуу коюлган пакет белгиси эки агымды өзүнчө кармайт; алардын эч бири жалгыздан толук эрежелер топтому эмес, жана экөө тең тандаган таблицасында жарактуу маршруттарды талап кылат.
Туннелдин абалын эмес, жергиликтүү чечимди текшериңиз, анткени өзөк OpenVPN пакетти көрө электе булакты жана интерфейсти тандайт.
ip route get 203.0.113.44 ip rule show
Бир ролду кайра баштап, экинчиси аман калганын далилдеңиз
Эки роль тең бир төмөнкү катмарга көз каранды болгондо тартип маанилүү. Колдонуучу трафигин жиберүү үчүн жогорку маршрут мурун болушу керек болсо, адегенде кардарды кайра баштаңыз, ал эми анын угуучусун же пулун гана өзгөртсөңүз, адегенде серверди кайра баштаңыз. Кандай болбосун кийин эки бирдикти тең ырастаңыз, анткени ийгиликсиз кайра баштоо экинчи ролду эскирген абал менен иштеп турууга калтырышы мүмкүн.
Өзгөртүүдөн мурун токтоо шартын жазыңыз: жогорку туннелдин жоголушу кыдырма колдонуучуларды тоспойбу, же Pi'нин өз жогорку каналына кайтабы? DNS жана IPv6 да анык жоопту талап кылат, анткени жиберилген чечүүчү көбүнчө аны пайдалуу кылган маршруттан узак жашайт.
systemctl restart [email protected] systemctl is-active [email protected] journalctl -u [email protected] -n 20 --no-pager
Өзгөртүүнү үч нерсе бир убакта аткарылганда гана кабыл алыңыз: жаңы кирүүчү туташуу бүтөт, жиберилген колдонмо көздөлгөн чыгуу аркылуу өз барагына жетет жана эки процесс те өз күткөн шеригин билдирет. Үчөөнүн бири ийгиликсиз болсо, сиз туура эмес нусканы же туура эмес маршрутту өзгөрттүңүз, ал эми кийинки кадам — башка нерсени кайра баштоо эмес, бирдикти кайра окуу.