Twee OpenVPN-prosesse loop op 'n Pi wat sowel swerwende gebruikers toelaat as 'n opstroomverskaffer bereik, en hulle deel byna niks behalwe die hardeware. Een luister vir inkomende tonnels terwyl die ander uitbel. Elkeen lees sy eie gids, en elkeen het sy eie foutmodus. Om die verkeerde een te herbegin is die algemeenste manier waarop ’n kliëntherstel uiteindelik die luisteraar omgooi.

Pas die eenheidnaam by die gids wat dit laai

Opstroom 2.6 lewer twee sjabloon-eenhede, [email protected] en [email protected]. Die bediener-sjabloon begin in /etc/openvpn/server en laai %i.conf daarvandaan. Die kliënt-sjabloon begin in /etc/openvpn/client. ‘n Instansie met die naam roaming kan op albei plekke gelyktydig bestaan, as ‘n bediener en as ‘n kliënt, met twee onverwante konfigurasies en geen skakel tussen hulle buiten die string nie.

Vra systemd eerder as die lêerstelsel, want pakketbouers voeg bykomende lêers by wat die werkende gids of die argumente wat die program ontvang, kan verander.

systemctl list-units --type=service 'openvpn-*@*'
systemctl cat [email protected]
systemctl show -p WorkingDirectory -p ExecStart [email protected]

Die eerste opdrag lys elke geïnstantieerde eenheid, ook dié wat misluk het en gelaai gebly het. Die tweede druk die eenheidlêer saam met enige oorheersing. Die derde is die vinnigste manier om die twee feite te sien wat die vraag beslis: die gids waarin die proses begin, en die konfigurasiepad wat dit ontvang het.

Beslis volgens pakketrigting, nie volgens koppelvlaknaam nie

‘n Bediener-instansie besit ‘n luistersok en aanvaar verbindings. Sy versleutelde vervoer is plaaslike invoer en plaaslike uitvoer op die Pi, terwyl die verkeer wat dit vir gebruikers aanstuur die aanstuurpad volg en aan ‘n ander stel reëls voldoen. ‘n Kliënt-instansie besit nie in daardie sin ‘n luisteraar nie: dit bel ‘n eweknie, so sy versleutelde vervoer is plaaslike uitvoer na die onderlaag.

Daardie verskil sê vir jou waar ‘n reël hoort. ‘n Reël wat ‘n koppelvlak in ‘n aanstuurketting pas, laat net verkeer toe wat die roetering reeds gekies het; dit kies nooit die roete nie. Wanneer ‘n swerwende gebruiker se pakkette deur die verkeerde pad vertrek, is die ketting om te ondersoek aanstuur, nie uitvoer nie.

Kyk na sokkies voordat jy teoretiseer. ‘n Bediener wat aan udp/1194 gebind is, wys ‘n luistersok. Die kliënt wys ‘n assosiasie met die verskaffer se adres en niks wat luister nie.

ss -lunp | grep openvpn
ss -unp state established '( dport = :1194 or sport = :1194 )'

Een instansie se verstekroete kan die ander se antwoorde vang

‘n redirect-gateway wat deur die opstroom-kliënt gestuur word, installeer ‘n verstekroete wat met alles anders op die masjien meeding, insluitend die antwoorde wat die bediener aan swerwende gebruikers stuur. OpenVPN maak ‘n uitsondering vir sy eie eweknie-adres sodat die tonnel bereikbaar bly, maar daardie uitsondering sê niks oor ‘n selfoon op ‘n hotelnetwerk nie.

Die simptoom is gewoonlik asimmetries. Die handskud voltooi, die kliënt rapporteer verbind, en verkeer sterf ná die eerste antwoordpakket. Brongebaseerde beleidroetering, of ‘n pakketmerk wat met --mark op die bediener-instansie gestel word, hou die twee strome uitmekaar; nie een is op sigself ‘n volledige reëlstel nie, en albei het geldige roetes nodig in watter tabel hulle ook kies.

Toets die plaaslike beslissing eerder as die tonneltoestand, want die kern kies die bron en koppelvlak voordat OpenVPN die pakket sien.

ip route get 203.0.113.44
ip rule show

Herbegin een rol en bewys die ander het oorleef

Orde maak saak wanneer albei rolle van dieselfde onderlaag afhanklik is. Herbegin die kliënt eerste as die opstroomroete moet bestaan voordat gebruikerverkeer aangestuur kan word, en herbegin die bediener eerste wanneer jy net sy luisteraar of sy poel verander. Bevestig in elk geval albei eenhede daarna, want ‘n mislukte herbegin kan die ander rol teen verouderde toestand laat loop.

Skryf die stopvoorwaarde neer voor die verandering: blokkeer die verlies van die opstroomtonnel swerwende gebruikers, of val dit terug op die Pi se eie opstroom? DNS en IPv6 het ook ‘n duidelike antwoord nodig, want ‘n gestuurde resolver oorleef dikwels die roete wat dit nuttig gemaak het.

systemctl restart [email protected]
systemctl is-active [email protected]
journalctl -u [email protected] -n 20 --no-pager

Aanvaar die verandering net wanneer drie dinge gelyktydig geld: ‘n nuwe inkomende verbinding voltooi, ‘n aangestuurde toepassing bereik sy bestemming deur die beoogde uitgang, en albei prosesse rapporteer steeds hulle verwagte eweknie. As een van die drie misluk, het jy die verkeerde instansie of die verkeerde roete verander, en die volgende stap is om die eenheid weer te lees eerder as om iets anders te herbegin.

Verwante artikels