Dva VPN klijenta na jednom računaru: šta se sudara i šta funkcioniše
Dva klijenta se bore za podrazumijevanu rutu, resolver i filter drajvere. Zabilježite ko posjeduje izlaz, pa odvojite drugi tunel pomoću VM-a ili netns-a.
Vaš drugi klijent se povezuje, resursi prvog prestaju da se razrješavaju, a tiket kaže da je radni VPN pokvario lični. Ništa nije pokvareno u smislu kvara: oba klijenta su radila ono za šta su napravljena, a mašina ima samo jednu tabelu rutiranja. Sudar je oko četiri resursa za koje svaki klijent pretpostavlja da ih posjeduje. Prođite kroz njih po redu i popravka obično postaje dizajnerska odluka, a ne popravka.
Korak 1: pronađite koji klijent posjeduje izlaz
Pročitajte trenutnu odluku o izlazu prije nego što bilo šta promijenite. Pretraga rute za javnu adresu govori vam koji interfejs i sljedeći hop bi paket sada koristio, i to je odgovor na to ko je pobijedio. Uporedite to s imenima interfejsa koje su klijenti napravili, a koja obično nose naziv proizvoda ili protokola. Ako pretraga pokazuje na tunel koji niste očekivali, već ste pronašli sudar.
ip route get 1.1.1.1
ip route show default
route print
Neki klijenti uopšte ne zamjenjuju podrazumijevanu rutu; dodaju dvije polovine, jednu za donju polovinu adresnog prostora i jednu za gornju, koje zajedno pokrivaju sve. To ostavlja originalnu podrazumijevanu rutu vidljivom i čini da ručna popravka izgleda ispravno dok saobraćaj i dalje izlazi kroz tunel. Čitajte metriku i dužinu prefiksa, a ne samo postojanje podrazumijevanog unosa.
Zaustavite se ako oba klijenta traže isti prefiks s istom metrikom. Jezgro će izabrati jedan, a drugi će izgledati povezan dok ništa ne nosi.
Korak 2: provjerite resolver i preklapajuće prefikse
DNS je drugi sudar i daje prepoznatljiv simptom: imena ne rade dok adrese rade. Svaki klijent nameće svoj resolver, a posljednji koji upiše pobjeđuje za naredne upite. Pitajte resolver servis šta koristi po linku umjesto da čitate stranicu postavki klijenta.
resolvectl status
Get-DnsClientServerAddress
dig +short intranet.corp.example
Zatim uporedite privatne prefikse koje dvije mreže koriste. Ako obje strane dodjeljuju iz istog opsega, nikakav dogovor na strani klijenta to neće popraviti, jer mašina ne može reći koja 10.0.0.0/8 destinacija pripada kojem tunelu. Jedna strana mora biti prenumerisana ili prevedena, a to je razgovor s vlasnicima mreže, a ne promjena konfiguracije. Preklapanje je jedini sudar u kojem je iskren odgovor da se dizajn mora promijeniti.
Zaustavite se ovdje ako se prefiksi preklapaju. Sve kasnije u ovoj kontrolnoj listi pretpostavlja da se ne preklapaju.
Korak 3: izaberite obrazac razdvajanja koji se održava
Pouzdani obrasci izbjegavaju pokretanje dva klijenta prema istoj tabeli rutiranja. Jedan klijent s politikom split-tunela koja doseže obje privatne mreže je najjednostavniji, pod uslovom da se destinacije ne preklapaju i da vlasnik politike pristane. Virtuelna mašina ili mrežni imenski prostor je sljedeći korak, jer svaki dobija svoju tabelu i svoj resolver.
sudo ip netns add vpn2
sudo ip netns exec vpn2 ip link show
sudo ip netns exec vpn2 curl -sI https://intranet.corp.example/
Imenski prostor daje isto razdvajanje kao virtuelna mašina bez drugog operativnog sistema, ali ima grube ivice: tunelski uređaj se mora premjestiti u njega, a aplikacija se mora pokrenuti unutar njega. Odvojen fizički uređaj je često najmanje iznenađujuća opcija za lični VPN uz upravljani radni klijent. Slaganje jednog tunela u drugi nije obrazac razdvajanja; unutrašnja krajnja tačka mora ostati dostupna kroz vanjski tunel, a takav raspored dodaje MTU i probleme s kašnjenjem povrh toga.
Izaberite jedan obrazac i zapišite zašto. Miješanje imenskog prostora za jednu aplikaciju sa split tunelom za ostale ponovo stvara originalni sudar u obliku koji se teže otklanja.
Korak 4: provjerite obje mreže iz iste sesije
Testirajte jedan resurs na svakoj privatnoj mreži iz okruženja u kojem aplikacija zaista radi, a ne iz vaše ljuske ako aplikacija radi unutar imenskog prostora. Provjerite izlazni interfejs, razriješenu adresu i kod odgovora zajedno, jer uspjeh u jednom od tri može sakriti neuspjeh u ostalim. Ponovite nakon ponovnog pokretanja, jer redoslijed kojim se klijenti pokreću odlučuje ko pobjeđuje. Upravo taj redoslijed ljudi zaborave zabilježiti.
curl -sI https://intranet.corp.example/
curl -sI https://files.personal.example/
ip route get 10.20.30.40
Zabilježite verzije klijenata, interfejse, stanje resolvera i prefikse za svaku mrežu. Kada se klijent ažurira i promijeni svoje ponašanje rutiranja, taj zapis je razlika između petominutne popravke i ponovne izgradnje. Sljedeća osoba neće dijeliti vaše sjećanje o tome koji tunel je prvi podignut.
Kontrolna lista je kompletna kada možete navesti interfejs koji posjeduje podrazumijevanu rutu, resolver koji koristi svako ime, obrazac koji razdvaja drugi tunel i rezultat jednog zahtjeva po mreži nakon ponovnog pokretanja. Bilo šta manje je konfiguracija koja danas slučajno radi.