Jeden Pi, dve inštancie OpenVPN: čo číta každá jednotka

Spočítajte procesy OpenVPN, skôr než sa dotknete profilu. Pi, ktorý prijíma roamingových používateľov a zároveň vytáča službu na vyššej úrovni, spúšťa dva démony a každý z nich číta konfiguračný súbor vybraný názvom inštancie, ktorý ste zadali. Šablóny balíka potom dajú každému démonu vlastný pracovný adresár, vlastný súbor stavu behu a vlastné tunelové zariadenie. Ak túto delenie pokazíte, strávite večer zmenou správneho nastavenia v súbore, ktorý bežiaci proces nikdy neotvorí.

Každý názov inštancie si vyberá vlastný súbor

V jednotkových súboroch dodávaných s OpenVPN 2.6 nesú štartovacie argumenty zástupný symbol inštancie, ktorý sa vypĺňa textom za znakom @. Šablóna servera beží z konfiguračného adresára servera a svoj argument rieši voči tamojšiemu %i.conf, kým šablóna klienta robí to isté z adresára klienta. Takže [email protected] číta admits.conf v adresári servera a [email protected] číta uplink.conf v adresári klienta, a ani jeden z týchto názvov nemá v druhom adresári nijaký význam.

Overte mapovanie na stroji, namiesto toho, aby ste predpokladali, že balík zachoval predvolené hodnoty. Drop-in distribúcie môže pracovný adresár alebo konfiguračný argument úplne nahradiť.

systemctl cat [email protected]
systemctl cat [email protected]

Prečítajte si riadok WorkingDirectory a konfiguračný argument v tomto výstupe, pretože iba povolená jednotka rozhoduje o tom, ktorý súbor sa načíta. Drop-in, ktorý pridáva --config k ExecStart, vyhráva nad šablónou aj vtedy, keď cesta šablóny vyzerá správne. Pýtajte sa na cesty fragmentov a drop-inov, keď chcete vedieť, či je v hre lokálne prepísanie. Ak sa obe roly rozriešia do jedného súboru, máte jeden proces, ktorý sa snaží byť serverom aj klientom, a neskoršia možnosť v tom súbore ticho vyhráva.

Lokálna doprava a presmerované zaťaženie narážajú na rôzne háky

Šifrované spojenie servera s každým roamingovým používateľom sa vytvára priamo na Pi, takže jeho vonkajšie odpovede vychádzajú cez lokálny výstupný hák. Spojenie klienta s jeho partnerom na vyššej úrovni je tiež lokálne vytvorený výstup, hoci dosahuje vzdialenú sieť. Presmerovaná užitočná záťaž je tretia kategória a jadro ju spáruje až po tom, čo už vybral výstupné zariadenie pre paket.

Pravidlo, ktoré v rámci forward reťazca zodpovedá výstupnému rozhraniu, môže povoliť alebo zahodiť paket, ktorý smerovanie už priradilo tomuto rozhraniu, ale nikdy rozhranie nevyberie. Keď jeden hostiteľ ukončí jeden tunel a začne druhý, politika, ktorá posiela používateľskú záťaž do tunela na vyššej úrovni, a politika, ktorá chráni vlastné šifrované odpovede Pi, sú dve oddelené rozhodnutia. Náhodou skončia na tej istej fyzickej NIC, a preto sa zamieňajú.

Tento rozdiel vysvetľuje časté polovičné zlyhanie. Používatelia sa pripoja, handshake sa dokončí a ich prevádzka aj tak odchádza nesprávnou cestou, pretože handshake bol lokálny a záťaž bola forward a testovaná bola len jedna z dvoch.

Importovaná trasa môže prehltnúť odpovede pre vašich používateľov

Nastavenie zabezpečenia klientskeho profilu rozhoduje o tom, čo môže vyššia úroveň vtlačiť do smerovacej tabuľky Pi, a široké presmerovanie je možnosť, ktorá z funkčného hostiteľa s dvojitou rolou urobí pokazeného. Ak vtlačená trasa pokrýva verejné adresy roamingových používateľov, odpovede, ktoré server pre nich vytvára, môžu nasledovať novú trasu do tunela na vyššej úrovni namiesto toho, aby vyšli cez podkladovú vrstvu. Ľudia často overia, že tunel k poskytovateľovi stále funguje, a tam sa zastavia, pretože táto prevádzka je vlastná doprava tunela a pokračuje v prúdení, kým všetko ostatné sa správa nesprávne.

Politika založená na zdroji alebo značke mark je spôsob, ako udržať dva toky oddelene. Linuxová možnosť mark v OpenVPN označí vlastné šifrované pakety démona značkou firewallu, ktorú potom smerovacie pravidlo môže poslať do vyhradenej tabuľky. Zdrojové adresy fungujú rovnako dobre, keď vonkajšie odpovede servera vždy vychádzajú z jednej podkladovej adresy. Oba prístupy potrebujú platné trasy v tabuľke, ktorú vyberú, a výnimku pre koncový bod poskytovateľa, inak sa samotný tunel prestane dvíhať.

Predtým, než napíšete akékoľvek pravidlo, spýtajte sa jadra, akou cestou by odpoveď skutočne išla. Adresy nižšie sú zástupné symboly pre podkladovú adresu Pi a verejnú adresu jedného roamingového používateľa.

ip rule show
ip route get 198.51.100.7 from 192.0.2.10

Overte rozdelenie, potom zastavte jednu rolu po druhej

Testujte tri toky oddelene, pretože fungujúci handshake nič nedokazuje o ostatných dvoch. Prijmite nové prichádzajúce spojenie, pošlite jednu povolenú aplikáciu cez výstup na vyššej úrovni a potvrďte, že oba procesy stále dosahujú svojich partnerov.

Potom zastavte rolu klienta a sledujte, čo si rola servera ponechá. Je to najlacnejší spôsob, ako nájsť pravidlo trasy alebo značky mark, ktoré bolo určené jednej inštancii a použité na obe.

systemctl stop [email protected]
systemctl status [email protected] --no-pager
ss -lunp | grep openvpn
journalctl -u [email protected] -n 20 --no-pager

Chcete vidieť, že poslucháč je stále naviazaný, tunelové zariadenie stále existuje a protokol je bez nových chýb, kým je rola klienta zastavená. Ak zastavenie klienta preruší aj odpovede servera existujúcim používateľom, obe roly zdieľajú niečo, čo malo byť obmedzené na jednu z nich. Zapisujte, ktorej inštancie, ktorého konfiguračného súboru a ktorého vlastníka toku sa každá zmena dotkla, pretože inak ďalšia osoba, ktorá bude tohto hostiteľa ladiť, zopakuje ten istý objav od nuly.