Kāpēc otrs VPN tunelis salauž pirmo?

Otra VPN klienta instalēšana, lai sasniegtu vienu klienta tīklu, ir ierastais veids, kā tas sākas, un pirmais tunelis kļūst tumšs, kamēr abi klienti ziņo par panākumiem. Katrs klients instalēja noklusējuma maršrutu, otrais bija konkrētāks, un kodols tagad to ievēro visam, izņemot paša pirmā tuneļa ārējo savienojumu. Nekas nesabruka un neviens profils nav nepareizs. Viens maršruts aizstāja otru, un risinājums ir izlemt, kuram tunelim jāpieder noklusējuma maršruts.

Simptoms: otrais klients klusi uzvar

OpenVPN: opcija redirect-gateway def1 nepārraksta 0.0.0.0/0. Tā pievieno 0.0.0.0/1 un 128.0.0.0/1: kopā tās aptver katru IPv4 adresi, un katrs prefikss garumā pārspēj vienkāršu noklusējumu. Sākotnējais noklusējums paliek tabulā un vairs netiek izmantots parastam trafikam, un maršruts uz VPN serveri neļauj tunelim notvert savus ārējos paketes. Abi klienti to dara, un otrais vienkārši instalē savu pāri vēlāk.

Tāpēc pirmais tunelis izskatās miris, nevis atvienots. Tā saskarne ir augšā, vadības kanāls ir dzīvs, un neviens lietojumprogrammas trafiks uz to vairs nenonāk. Pretējā sūdzība nāk no tā paša trūkstošā push: tālrunis, kas pieslēdzas, bet neko nesūta, parasti runā ar serveri, kas nekad nav paziņojis redirect-gateway, tāpēc ierīce patur savu noklusējumu un sasniedz tikai baseinu.

Uzņemiet maršrutu momentuzņēmumu pirms un pēc otrā klienta pieslēgšanās. Divi pusmaršruti, kas parādās tabulā, ir visa izmaiņa, un tie izskaidro abas sūdzības. Nekam citam tabulā nav jākustas, lai simptoms parādītos. Tāpēc otrā klienta noņemšana nekavējoties atjauno pirmo.

Izlasiet, kurš tunelis patiešām uzvar

Neizseciniet uzvarētāju no klientu palaišanas secības vai sistēmas teknē esošās ikonas. Pajautājiet kodolam, kuru maršrutu tas izmantotu galamērķim ārpus abiem privātajiem tīkliem, un izlasiet atgriezto saskarni.

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

Pirmie divi ir Linux atbilde, bet pēdējie divi ir Windows ekvivalents. Izpildiet tos, kamēr abi tuneļi ir augšā, pēc tam atvienojiet vienu un izpildiet vēlreiz. Atšķirība starp divām izvadēm ir fakts, kas jums nepieciešams pirms risinājuma izvēles, un tas aizņem mazāk laika nekā jebkura klienta žurnāla lasīšana.

Pierakstiet rezultātu, tostarp saskarnes nosaukumu un atbilstošo prefiksu. Biļete, kurā teikts, ka otrais VPN salauza pirmo, ir simptoma apraksts, nevis maršrutēšanas apgalvojums, uz kura kāds varētu rīkoties. Meklēšana to pārvērš faktā, ko nākamais inženieris var atkārtot ar vienu komandu.

Windows: neļaujiet vienam profilam piederēt noklusējumu

Windows glabā saglabātos profilus, un iebūvētais klients ļauj vienam būt atkarīgam no cita, lai pirmais automātiski paceltos, kad otrais zvana. Profils, kas pieslēdzās pēdējais, mēdz saglabāt noklusējumu, tāpēc praktiskais īpašnieks ir pēdējais zvans, nevis pirmais. Dodiet katram profilam savus push maršrutus un ieslēdziet split tunneling tam, kuram nevajadzētu piederēt noklusējums.

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

Split tunneling to maina: tabulā nonāk tikai servera pushotie prefiksi, kas atstāj noklusējumu pirmajam tunelim. Dizains joprojām neizdodas, ja abi serveri pusho noklusējuma maršrutu, jo tad uzvar pēdējais savienojums un nekāds klienta puses iestatījums to nemaina. Izlabojiet push servera pusē vai pieņemiet vienu īpašnieku.

Lietojumprogrammas palaisti profili ir cita funkcija, un to ir vērts zināt: Windows profils var sākties, kad palaižas nosaukts izpildfails, un trafika filtri izlemj, ko tas nes. Tas ir profila iestatījums, nevis ugunsmūra noteikums, un tas risina citu problēmu nekā noklusējuma maršruta konflikts.

Linux: turiet otro tuneli ārpus galvenās tabulas

Divu openvpn --config instanču palaišana vienā mašīnā ievieto abus klientus vienā tabulā, un trīs opcijas atdala tos ar pieaugošu izolāciju. Viegākā ir neļaut otrajam klientam tabulu vispār rediģēt: route-nopull ar skaidriem maršrutiem vai route-up skripts, kas instalē tikai to, ko esat iecerējis. Tad otrais tunelis nes tieši jūsu nosauktos prefiksus un neko citu. Tad jūs izlemjat, kuri prefiksi kur iet, nevis atklājat to pēc tam.

Politikas maršrutēšana ir vidējā opcija. Noteikums izvēlas atsevišķu tabulu vienai avota adresei vai ugunsmūra atzīmei, un šī tabula nes otrā tuneļa maršrutus. Šeit slazds ir reversā ceļa filtrēšana, jo atbilde, kas ierodas citā saskarnē nekā tabula izvēlētos, tiek izmesta, tāpēc pārbaudiet rp_filter iestatījumu pirms secināt, ka tunelis ir salauzts.

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

Tīkla nosaukumvietas ir smagākā un tīrākā opcija. Palaidiet otro klientu ip netns iekšienē, dodiet tam veth pāri un ieejiet šajā nosaukumvietā, lai to izmantotu. Traucējumi pazūd, jo katrai nosaukumvietai ir savas tabulas, nevis viena koplietota, un tas ir tā vērts papildu iestatīšanas dēļ, kad abiem tuneļiem jāpaliek augšā nedēļām.

Pēc lietojumprogrammas, un ķēdēšana kā atsevišķa problēma

Dažreiz tikai vienai programmai vajadzētu izmantot otro tuneli. Linux sistēmā politikas maršrutēšana pēc lietotāja, cgroup vai porta sasniedz šo rezultātu, un vienu galamērķi var piespraust saskarnei, nemaz neaizskarot noklusējumu. Lietojumprogramma, kas piesprauž savu ligzdu vienai saskarnei, vispār neuzklausa maršrutēšanas tabulu, tāpēc palaidējs var turpināt izmantot fizisko adapteri, līdz tā iestatījumos tiek izvēlēta adrese.

Ķēdēšana ir cita darbība nekā divu tuneļu palaišana līdzās. Ķēdēt A pāri B nozīmē, ka iekšējā servera adresei jābūt sasniedzamai no ārējā tuneļa iekšpuses. Ārējais klients arī nedrīkst uzskatīt iekšējā klienta šifrētās paketes par noplūdi. Viens klients virtuālajā mašīnā ir raupjā, bet uzticamā versija; abi vienā resursdatorā prasa augstāk minēto maršrutēšanas darbu un ārēju ceļu uz iekšējo serveri, kas nekad neieiet iekšējā tunelī.

Pierakstiet noklusējuma īpašnieku, katra tuneļa nesto prefiksu sarakstu un DNS ceļu. Šie trīs fakti pārvērš nākamo incidentu meklēšanā, nevis izmeklēšanā.