Dva tunely OpenVPN na jednom hoste Linux: komu patrí trasa?

Dva profily sú pripojené a jeden z nich potichu prenáša prevádzku určenú druhému. Hostiteľ Linux dokáže spustiť obidvoch OpenVPN klientov naraz bez problémov. Čo nedokáže, je rozhodnúť za vás, ktorý proces si smie nárokovať ktorý prefix. To rozhodnutie treba urobiť predtým, než druhý tunel nabehne, nie po tom, čo zdroj prestane odpovedať.

Začnite úlohou, ktorú musí splniť druhé spojenie

Kancelária dostupná cez jeden profil a laboratórium dostupné cez druhý potrebujú oba tunely hore a ani jeden z nich nesmie nárokovať všetko. Jedna neústupná aplikácia, ktorá musí odchádzať cez druhý profil, potrebuje pravidlo politiky, nie druhú predvolenú trasu. Záložné spojenie potrebuje len jeden tunel bežiaci naraz, takže záloha by nemala štartovať spolu so strojom.

Sú to tri rôzne konfigurácie a pletú sa preto, lebo všetky tri začínajú rovnako: druhý profil a úspešné pripojenie. Najprv si zapíšte zamýšľané usporiadanie, potom konfigurujte k nemu. Jedna veta o zámere ušetrí hodinu zachytávania paketov.

systemctl list-units --type=service 'openvpn-client@*'
ip -4 route show default

Prvý príkaz vypíše bežiace inštancie vrátane tých spustených ručne mimo správcu. Druhý vypíše aktuálny nárok na predvolenú trasu, a to je stav, ktorý budete musieť neskôr vysvetliť.

Prekrývajúce sa pooly sa rozbijú skôr než smerovanie

Dva servery ochotne pridelia adresy z rovnakého 10.8.0.0/24. Klient potom drží dve rozhrania v jednom prefixe a nič nehovorí, ktorá destinácia patrí ktorej, a výsledné správanie vyzerá ako porucha smerovania, ale v skutočnosti je to porucha číslovania. Prečíslovanie poolu stojí jednu úpravu konfigurácie; každé neskoršie obchádzanie smerovania stojí celý víkend. Pozrite sa na pool skôr, než k nemu pridáte trasu.

Pozrite sa aj na miestnu LAN. Domáca LAN s číslom 192.168.1.0/24, ktorú jeden tunel tiež vystavuje, vytvára rovnakú nejednoznačnosť a príznakom je názov hostiteľa, ktorý sa preloží, ale spojenie sa nikdy nedokončí. Vyzerá to ako porucha prekladu názvov, kým nevypíšete trasy.

ip -4 addr show
ip route show table all | grep -E '10\.|192\.168\.'

Porovnajte oba výstupy s obidvoma konfiguráciami servera, než sa dotknete klienta. Ak sa prefixy prekrývajú, zastavte sa a prečíslujte, pretože ich nerozdelí žiadne množstvo reštartov.

Dajte každému profilu vlastnú jednotku a každému prefixu vlastníka

Každý profil dostane vlastný názov inštancie a vlastný konfiguračný súbor, preto inštancia s názvom office načítava office.conf, kým inštancia s názvom lab načítava lab.conf. Potvrďte toto mapovanie cez správcu služieb namiesto spoliehania sa na výpis adresára, pretože drop-in môže zmeniť, ktorý súbor sa načíta. Nesprávne mapovanie znamená, že ladíte profil, ktorý nebeží.

Potom rozhodnite, kto inštaluje trasy. Keď servery pretláčajú nekompatibilné sady, buď pretlačenie odmietnite a prefixy vymenujte sami, alebo nechajte jeden profil držať predvolenú trasu a druhý veďte pravidlami politiky. Dva procesy, ktoré obidva inštalujú predvolenú trasu, skončia s tichým víťazom a bez písomného záznamu o rozhodnutí.

systemctl cat [email protected]
grep -E 'route-nopull|pull-filter|redirect-gateway' /etc/openvpn/client/lab.conf

Prvý ukazuje jednotku s akýmkoľvek prepisom, ktorý mení jej argumenty. Druhý ukazuje, či profil vôbec prijíma pretlačené trasy, a to je prepínač, ktorý určuje všetko ďalej.

Značky udržujú odpovede na rozhraní, z ktorého prišli

Keď každý tunel obsluhuje iné zdroje, odpoveď môže odísť nesprávnym spojením a spojenie zomrie po prvom pakete. Vzor, ktorý vydrží, je označiť prichádzajúce pakety podľa vstupného rozhrania, obnoviť túto značku na odpovedi a dať každej značke tabuľku s vlastnou predvolenou bránou.

Voľné filtrovanie spätnej cesty sa zvyčajne musí uvolniť pre dotknuté rozhrania, pretože odpoveď legitímne prichádza spojením, ktoré by hlavná tabuľka nikdy nevybrala. Držte značky úzke, aby nikdy nezachytili vlastnú šifrovanú prevádzku tunelov, čo by poslalo tunel sám sebou.

ip rule show
ip route show table 101
sysctl net.ipv4.conf.all.rp_filter

Prečítajte si existujúce pravidlá, než pridáte ďalšie. Duplicitné priority a zabudnuté tabuľky sú obvyklým dôvodom, prečo sa politika značiek zdá úplne bez účinku.

Dokážte izoláciu zastavením jedného spojenia

S obidvoma tunelmi hore si zapíšte adresu každého rozhrania, trasu k jednému hostiteľovi za každým tunelom a cestu, ktorou sa vydá nesúvisiaci cieľ. Požiadajte jadro o vyhľadanie namiesto čítania jednej tabuľky, pretože jedna tabuľka nikdy neukáže konečné rozhodnutie.

Potom zastavte jednu inštanciu a sledujte, ako jej rozhranie a trasy miznú, kým druhá pokračuje. Prerušenie v prežívajúcej znamená, že obe stále zdieľajú názov zariadenia, trasu alebo pravidlo firewallu, ktoré nikto neoddvojil.

Vráťte zastavený profil a zopakujte rovnaké kontroly. Keď tunel prežije len prvý štart po reštarte, pozeráte sa na chybu životného cyklu, nie na návrh smerovania.