Zašto drugi VPN tunel pokvari prvi?

Instaliranje drugog VPN klijenta radi pristupa jednoj klijentskoj mreži uobičajen je način na koji ovo počinje, i prvi tunel se ugasi dok oba klijenta prijavljuju uspjeh. Svaki klijent instalirao je default rutu, druga je bila specifičnija, a kernel je sada slijedi za sve osim za vlastitu vanjsku vezu prvog tunela. Ništa nije palo i nijedan profil nije pogrešan. Jedna ruta zamijenila je drugu, a rješenje je odlučiti koji tunel treba posjedovati default.

Simptom: drugi klijent tiho pobjeđuje

OpenVPN: opcija redirect-gateway def1 ne prepisuje 0.0.0.0/0. Ona dodaje 0.0.0.0/1 i 128.0.0.0/1: zajedno pokrivaju svaku IPv4 adresu, a svaki prefiks pobjeđuje običan default po dužini. Originalni default ostaje u tabeli i prestaje se koristiti za običan saobraćaj, a host ruta do VPN servera sprječava tunel da uhvati vlastite vanjske pakete. Oba klijenta to rade, a drugi jednostavno svoj par instalira kasnije.

Zato prvi tunel izgleda mrtav, a ne prekinut. Interfejs mu je podignut, kontrolni kanal živ, i nikakav saobraćaj aplikacija više do njega ne dolazi. Suprotna žalba ima isti uzrok — nedostajući push: telefon koji se poveže ali ništa ne šalje obično razgovara sa serverom koji nikada nije oglašavao redirect-gateway, pa uređaj zadržava svoj default i doseže samo pool.

Napravite snimku ruta prije i poslije povezivanja drugog klijenta. Dvije polu-rute koje se pojave u tabeli čine cijelu promjenu i objašnjavaju obje žalbe. Ništa drugo u tabeli ne mora se pokrenuti da bi se simptom pojavio. Zato uklanjanje drugog klijenta odmah vraća prvi.

Pročitajte koji tunel zapravo pobjeđuje

Ne zaključujte pobjednika iz redoslijeda pokretanja klijenata ni iz ikone u traci. Pitajte kernel koju bi rutu koristio za odredište izvan obje privatne mreže i pročitajte interfejs koji vrati.

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

Prve dvije su odgovor za Linux, a posljednje dvije ekvivalent za Windows. Pokrenite ih dok su oba tunela podignuta, zatim prekinite jedan i pokrenite ih ponovo. Razlika između dva izlaza je činjenica koja vam treba prije odabira rješenja, i traje kraće od čitanja loga bilo kojeg klijenta.

Zapišite rezultat, uključujući naziv interfejsa i prefiks koji se poklopio. Tiket koji kaže da je drugi VPN pokvario prvi opisuje simptom, a ne rutnu tvrdnju na koju se neko može osloniti. Provjera to pretvara u činjenicu koju sljedeći inženjer može reproducirati jednom komandom.

Windows: spriječite da jedan profil posjeduje default

Windows čuva sačuvane profile, a ugrađeni klijent dopušta da jedan zavisi od drugog, pa se prvi podiže automatski kad se drugi poveže. Profil koji se povezao posljednji obično zadržava default, pa je praktični vlasnik posljednje povezivanje, a ne prvo. Dajte svakom profilu vlastite push rute i uključite split tunneling za onaj koji ne treba posjedovati default.

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

Split tunneling to mijenja: u tabelu dospijevaju samo prefiksi koje server gura, što ostavlja default prvom tunelu. Dizajn i dalje pada ako oba servera guraju default rutu, jer tada pobjeđuje posljednja veza i nijedna klijentska postavka to ne mijenja. Ispravite push na serveru ili prihvatite jednog vlasnika.

Profili koje pokreće aplikacija druga su funkcija i vrijedi ih znati: Windows profil može se pokrenuti kada se pokrene imenovani izvršni fajl, a filteri saobraćaja odlučuju šta nosi. To je postavka profila, a ne pravilo firewall-a, i rješava drugi problem od sukoba default ruta.

Linux: držite drugi tunel izvan glavne tabele

Pokretanje dvije openvpn --config instance na istoj mašini stavlja oba klijenta u istu tabelu, a tri opcije razdvajaju ih s rastućom izolacijom. Najlakša je potpuno zaustaviti drugi klijent da uređuje tabelu, koristeći route-nopull s eksplicitnim rutama, ili route-up skriptu koja instalira samo ono što želite. Tada drugi tunel nosi tačno prefikse koje navedete i ništa drugo. Tada vi odlučujete koji prefiksi idu gdje, umjesto da to otkrivate poslije.

Policy routing je srednja opcija. Pravilo odabire odvojenu tabelu za jednu izvornu adresu ili firewall oznaku, a ta tabela nosi rute drugog tunela. Reverse-path filtering je zamka ovdje, jer odgovor koji stigne na drugi interfejs od onog koji bi tabela odabrala biva odbačen, pa provjerite postavku rp_filter prije nego zaključite da je tunel pokvaren.

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

Mrežni namespaceovi su najteža i najčišća opcija. Pokrenite drugi klijent unutar ip netns, dajte mu veth par i uđite u taj namespace da ga koristite. Smetnje nestaju jer svaki namespace posjeduje vlastite tabele umjesto da dijeli jednu, što vrijedi dodatnog podešavanja kada oba tunela moraju ostati podignuta sedmicama.

Po aplikaciji, i lančanje kao odvojen problem

Ponekad samo jedan program treba koristiti drugi tunel. Na Linuxu policy routing po korisniku, cgroupu ili portu postiže taj rezultat, a jedno odredište može se prikvačiti za interfejs bez diranja defaulta. Aplikacija koja prikvači svoj socket za jedan interfejs nikada ne konsultuje tabelu rutiranja, pa pokretač može nastaviti koristiti fizički adapter dok se adresa ne odabere unutar njegovih postavki.

Lančanje je druga operacija od pokretanja dva tunela jedan uz drugi. Lančati A preko B znači da adresa unutrašnjeg servera mora biti dostupna iz unutrašnjosti vanjskog tunela. Vanjski klijent takođe ne smije zamijeniti šifrovane pakete unutrašnjeg klijenta za curenje. Jedan klijent unutar virtualne mašine je gruba ali pouzdana verzija; oba na jednom hostu zahtijevaju rutiranje gore plus vanjski put prema unutrašnjem serveru koji nikada ne ulazi u unutrašnji tunel.

Zapišite vlasnika defaulta, listu prefiksa koje nosi svaki tunel i DNS put. Te tri činjenice pretvaraju sljedeći incident u provjeru umjesto istrage.