Importitaj VPN-itineroj malsamas de la funkcianta kliento? Komparu ambaŭ

Iuj privataj servoj respondas tra la VPN dum ordinara interreta trafiko kondutas tute alie ol en la maŝino de kolego, kaj oni emas konkludi, ke la kliento Ubuntu estas difektita. Tiu konkludo preterlasas unu paŝon. Funkcianta privata operacio kaj malsama publika vojo estas du observoj, kaj la diferenco kutime kuŝas en la trafika politiko, kiun ĉiu kliento instalis, ne en la kliento mem.

Kompari la konservitan agordon kun la efektiva reta stato postulas tri komandojn kaj respondas la demandon, kiun la konjektado provis respondi.

Unue la konservita profilo, poste la efektiva stato

Importita OpenVPN-konekto fariĝas propra NetworkManager-profilo. La dosiero .ovpn, el kiu ĝi venis, ĉesas esti fonto de vero en la momento, kiam la importo finiĝas, do posta redaktado de tiu dosiero ŝanĝas nenion pri la konekto, kiun vi uzas. Ĉi tie la komparo unue eraras, kaj ĝi eraras silente.

nmcli -f connection.id,connection.uuid,ipv4.never-default,ipv4.routes,ipv4.dns connection show office-vpn

Legu la UUID, kiam nomoj kolizias; duoblaj nomoj postvivas reinstalojn kaj profilrestarigojn, kaj vi povas pasigi horon redaktante la kopion, kiu ne estas uzata. La valoroj, kiujn vi vidas, priskribas la konservitan intencon: ĉu la profilo rajtas preni la defaŭltan itineron, kiuj itineroj estis konservitaj kaj kiujn solvilojn kaj serĉajn domajnojn ĝi petas. Ili ne priskribas, kio okazis, kiam la konekto aktiviĝis, ĉar kromprogramo aŭ puŝo de la servilo povas aldoni staton, kiun la profilo ne mencias. Tial gravas la sekva komando.

Poste rigardu, kion la sistemo efektive faris kun tiu intenco, inkluzive de politikaj reguloj kaj ĉiuj tabeloj, ne nur la ĉefa. Konservitaj ecoj estas enigoj, kaj la instalitaj tabeloj estas la rezulto.

ip -4 rule show
ip -4 route show table all

Du celoj, unu komparo

Elektu unu privatan celon, kiu funkcias, kaj unu ordinaran publikan celon, poste demandu la kernon, kiun vojon ĉiu prenus. Ĝuste fari tion en ambaŭ maŝinoj transformas malklaran diferencon en konkretan.

ip -4 route get 10.40.0.20
ip -4 route get 203.0.113.20

La adresoj estas ekzemploj por anstataŭigi per la viaj; la afero estas la paro, ne la nombroj. Komparu la interfacon, la fontadreson kaj la tabelon nomitan en ĉiu eligo. Kiam la privata serĉo nomas la tunelon kaj la publika serĉo ankaŭ nomas la tunelon, vi havas plenan tunelon kaj la alia kliento eble havas dividitan, aŭ inverse.

Ne postulu, ke la du klientoj presu identan tekston. En OpenVPN redirect-gateway def1 kutime esprimiĝas kiel du duonprefiksa itineroj anstataŭ unu defaŭlta, kaj administranto, kiu montras ilin alie, ne estas pro tio malĝusta. Juĝu la kovradon, kiun montras la serĉoj, ne la formatadon.

Kie la du klientoj laŭleĝe malsamas

La defaŭltoj de klientoj estas politikaj elektoj, kaj ili rajtas malkonsenti. Unu produkto eble preferas plenan tunelon, alia eble konservas la lokan defaŭlton kaj enkursigas nur la privatajn prefiksojn, kaj tria eble sekvas tion, kion la servilo puŝis. Diferenco estas difekto nur tiam, kiam ĝi kontraŭdiras la postulon, kiun vi ricevis.

Do komparu ĉiun klienton kun la aprobita intenco de dividita aŭ plena tunelo, ne unu kun la alia. Se la postulo estas, ke privata trafiko uzu la tunelon kaj la loka interreta vojo restu loka, tiam plena tunelo estas la cimo kaj dividita tunelo estas ĝusta, sendepende de tio, kiu kliento faris kion. Skribu la intencon antaŭ ol rigardi ajnan agordon, alie la unua kliento, kiun vi inspektas, silente fariĝas la normo.

DNS estas dua akso kaj malsukcesas sendepende. Ĝusta itinero ankoraŭ povas sendi demandojn al solvilo, kiu ne povas respondi por la privata zono, kaj ĝusta solvilo ne riparas malĝustan itineron. Kontrolu ambaŭ, kaj traktu privatan nomon, kiu solviĝas dum privata adreso ne solviĝas, kiel pruvon, ke la du tavoloj solviĝas aparte.

Tenu la komparon pura

Funkciigu unu posedanton de konekto samtempe. OpenVPN-sesio el la komandlinio, kiu kuras apud la importita profilo, instalas proprajn itinerojn kaj propran solvilan staton, kaj la rezulta miksaĵo estas la konduto de neniu el la du klientoj. Malŝaltu unu antaŭ ol mezuri la alian. Restartigu, se vi ne certas, kio ankoraŭ tenas staton, ĉar malnova itinero de antaŭ horo aspektos precize kiel politika problemo.

Tenu ankaŭ ĉion alian fiksa: la sama finpunkto, la sama konto, la samaj programversioj, la sama reto. Sukceso en la Windows-teknikaĵo de kolego testas alian klienton, alian solvilan integriĝon kaj eble alian servilprofilon, do ĝi ne estas pruvo pri la Ubuntu-administranto.

La referenco de IPv4-agordoj de NetworkManager difinas precize never-default kaj la konservitajn itinerajn ecojn, kio indas legi antaŭ ol ŝanĝi administritan valoron. Kaj memoru la amplekson de ĉi tiu komparo: ĝi kovras IPv4 kaj diras nenion pri la responda politiko IPv6, kiu havas proprajn defaŭltojn kaj propran manieron surprizi vin.