Prečo druhý tunel VPN rozbije ten prvý?

Inštalácia druhého klienta VPN na dosiahnutie jednej zákazníckej siete je obvyklý spôsob, ako to začína, a prvý tunel zhasne, zatiaľ čo obaja klienti hlásia úspech. Každý klient nainštaloval predvolenú trasu, tá druhá bola konkrétnejšia, a jadro ju teraz nasleduje pre všetko okrem vlastného vonkajšieho spojenia prvého tunela. Nič nespadlo a žiadny profil nie je nesprávny. Jedna trasa nahradila druhú a riešením je rozhodnúť, ktorý tunel má vlastniť predvolenú trasu.

Príznak: druhý klient ticho vyhrá

OpenVPN: voľba redirect-gateway def1 neprepisuje 0.0.0.0/0. Pridáva 0.0.0.0/1 a 128.0.0.0/1: spolu pokrývajú každú adresu IPv4 a každý prefix poráža obyčajnú predvolenú trasu dĺžkou. Pôvodná predvolená trasa zostáva v tabuľke a prestáva sa používať na bežnú prevádzku a hostiteľská trasa k serveru VPN bráni tunelu zachytiť jeho vlastné vonkajšie pakety. Obaja klienti to robia a druhý jednoducho nainštaluje svoju dvojicu neskôr.

Preto prvý tunel vyzerá mŕtvy, nie odpojený. Jeho rozhranie je hore, riadiaci kanál žije a žiadna prevádzka aplikácií sa k nemu už nedostane. Opačná sťažnosť má rovnaký chýbajúci push: telefón, ktorý sa pripojí, ale nič neposiela, zvyčajne hovorí so serverom, ktorý nikdy neinzeroval redirect-gateway, takže zariadenie si ponechá svoju predvolenú trasu a dosiahne iba na pool.

Urobte snímku trás pred pripojením druhého klienta a po ňom. Dve polovičné trasy, ktoré sa v tabuľke objavia, sú celá zmena a vysvetľujú obe sťažnosti. Nič iné v tabuľke sa kvôli príznaku nemusí hýbať. Preto odstránenie druhého klienta okamžite obnoví prvý.

Prečítajte si, ktorý tunel skutočne vyhrá

Neodvodzujte víťaza z poradia, v ktorom sa klienti spustili, ani z ikony v oznamovacej oblasti. Spýtajte sa jadra, ktorú trasu by použilo pre cieľ mimo oboch privátnych sietí, a prečítajte si vrátené rozhranie.

ip route show
ip route get 198.51.100.24
route print -4
Find-NetRoute -RemoteIPAddress 198.51.100.24

Prvé dva príkazy sú odpoveď Linuxu a posledné dva ekvivalent Windows. Spustite ich, kým sú oba tunely hore, potom jeden odpojte a spustite ich znova. Rozdiel medzi dvoma výstupmi je fakt, ktorý potrebujete pred voľbou riešenia, a zaberie menej času ako čítanie logu ktoréhokoľvek klienta.

Zaznamenajte výsledok vrátane názvu rozhrania a prefixu, ktorý sedel. Tiket, ktorý hovorí, že druhý VPN rozbil prvý, je opis príznaku, nie smerovacie tvrdenie, na ktorom sa dá konať. Vyhľadanie z neho urobí fakt, ktorý ďalší inžinier zopakuje jedným príkazom.

Windows: zabráňte, aby jeden profil vlastnil predvolenú trasu

Windows uchováva uložené profily a vstavaný klient umožňuje, aby jeden závisel od druhého, takže prvý naskočí automaticky, keď sa druhý vytočí. Profil pripojený naposledy zvyčajne drží predvolenú trasu, takže praktickým vlastníkom je posledné vytočenie, nie prvé. Dajte každému profilu vlastné push trasy a zapnite split tunneling pre ten, ktorý predvolenú trasu vlastniť nemá.

Set-VpnConnection -Name "Contoso" -SplitTunneling $true
rasdial Contoso

Split tunneling to mení: do tabuľky sa dostanú len prefixy pushnuté serverom, čo nechá predvolenú trasu prvému tunelu. Dizajn stále zlyhá, ak oba servery pushujú predvolenú trasu, pretože vtedy vyhrá posledné spojenie a žiadne nastavenie na strane klienta to nezmení. Opravte push na strane servera alebo prijmite jedného vlastníka.

Profily spúšťané aplikáciou sú iná funkcia a stojí za to ich poznať: profil Windows sa môže spustiť pri štarte menovaného spustiteľného súboru a filtre prevádzky rozhodujú, čo ponesie. Je to nastavenie profilu, nie pravidlo firewallu, a rieši iný problém než konflikt predvolenej trasy.

Linux: držte druhý tunel mimo hlavnej tabuľky

Spustenie dvoch inštancií openvpn --config na jednom stroji dá oboch klientov do tej istej tabuľky a tri možnosti ich oddelia s rastúcou izoláciou. Najľahšie je prestať nechať druhého klienta upravovať tabuľku vôbec: route-nopull s explicitnými trasami alebo skript route-up, ktorý nainštaluje len to, čo zamýšľate. Potom druhý tunel nesie presne vami pomenované prefixy a nič iné. Potom rozhodujete, ktoré prefixy kam idú, namiesto toho, aby ste to zisťovali dodatočne.

Policy routing je stredná možnosť. Pravidlo vyberie samostatnú tabuľku pre jednu zdrojovú adresu alebo značku firewallu a tá tabuľka nesie trasy druhého tunela. Filtrovanie reverznej cesty je tu pasca, pretože odpoveď, ktorá dorazí na iné rozhranie, než by tabuľka vybrala, sa zahodí, takže pred záverom, že tunel je rozbitý, skontrolujte nastavenie rp_filter.

ip rule add from 10.44.7.0/24 table 100
ip route add default dev tun1 table 100
sysctl net.ipv4.conf.all.rp_filter

Sieťové menné priestory sú najťažšia a najčistejšia možnosť. Spustite druhého klienta vnútri ip netns, dajte mu pár veth a vstúpte do tohto menného priestoru, aby ste ho používali. Rušenie zmizne, pretože každý menný priestor vlastní vlastné tabuľky namiesto zdieľania jednej, čo stojí za nastavenie navyše, keď oba tunely musia zostať hore týždne.

Podľa aplikácie a reťazenie ako samostatný problém

Niekedy má druhý tunel používať len jeden program. Na Linuxe to dosiahne policy routing podľa používateľa, cgroup alebo portu a jedna destinácia sa dá pripnúť k rozhraniu bez toho, aby sa predvolená trasa vôbec dotkla. Aplikácia, ktorá pripne svoj socket k jednému rozhraniu, tabuľku trás vôbec nekonzultuje, takže spúšťač môže ďalej používať fyzický adaptér, kým sa v jeho vlastných nastaveniach nevyberie adresa.

Reťazenie je iná operácia než prevádzkovanie dvoch tunelov vedľa seba. Zreťaziť A cez B znamená, že adresa vnútorného servera musí byť dostupná zvnútra vonkajšieho tunela. Vonkajší klient tiež nesmie považovať šifrované pakety vnútorného klienta za únik. Jeden klient vo virtuálnom stroji je hrubá, ale spoľahlivá verzia; oba na jednom hostiteľovi vyžadujú smerovaciu prácu vyššie plus vonkajšiu cestu k vnútornému serveru, ktorá nikdy nevstúpi do vnútorného tunela.

Zapíšte vlastníka predvolenej trasy, zoznam prefixov každého tunela a cestu DNS. Tieto tri fakty premenia ďalší incident na vyhľadanie namiesto vyšetrovania.