Ingevoerde VPN-roetes verskil van die werkende kliënt? Vergelyk albei

Sommige private dienste antwoord deur die VPN terwyl gewone internetverkeer heeltemal anders werk as op 'n kollega se masjien, en die versoeking is om te conclude dat die Ubuntu-kliënt stukkend is. Daardie gevolgtrekking slaan 'n stap oor. 'n Werkende private werking en 'n anders public pad is twee waarnemings, en die verskil sit gewoonlik in die verkeersbeleid wat elke kliënt geïnstalleer het, nie in die kliënt self nie.

Om die gestoorde konfigurasie met die werklike netwerktoestand te vergelyk, neem drie opdragte en beantwoord die vraag wat die raaiwerk probeer antwoord het.

Eers die gestoorde profiel, dan die werklike toestand

'n Ingevoerde OpenVPN-verbinding word 'n NetworkManager-profiel van sy eie. Die .ovpn-lêer waaruit dit gekom het, hou op om die bron van waarheid te wees sodra die invoer voltooi is, so om daardie lêer later te wysig verander niks aan die verbinding wat jy gebruik nie. Dit is die eerste plek waar die vergelyking verkeerd loop, en dit loop stil verkeerd.

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

Lees die UUID wanneer name bots; duplikaatname oorleef herinstallasies en profielherstel, en jy kan 'n uur spandeer om die kopie te wysig wat nie in gebruik is nie. Die waardes wat jy sien, beskryf die gestoorde bedoeling: of die profiel die verstekroete mag neem, watter roetes gestoor is, en watter oplossers en soekdomeine dit vra. Hulle beskryf nie wat gebeur het toe die verbinding geaktiveer is nie, want 'n inprop of 'n bedienerstoot kan toestand byvoeg wat die profiel nie noem nie. Daarom maak die volgende opdrag saak.

Kyk dan wat die stelsel werklik met daardie bedoeling gedoen het, insluitend beleidsreëls en elke tabel, nie net die hoof een nie. Gestoorde eienskappe is insette, en die geïnstalleerde tabelle is die resultaat.

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

Twee bestemmings, een vergelyking

Kies een private bestemming wat werk en een gewone publieke bestemming, en vra dan die kern watter pad elkeen sal neem. Om dit op albei masjiene te doen, is wat 'n vae verskil in 'n spesifieke een verander.

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

Die adresse is voorbeelde wat jy deur jou eie moet vervang; die punt is die paar, nie die getalle nie. Vergelyk die koppelvlak, die bronadres en die tabel wat in elke uitset genoem word. Wanneer die private soektog die tonnel noem en die publieke soektog ook die tonnel noem, het jy 'n vol tonnel en die ander kliënt het miskien 'n gesplitste een, of omgekeerd.

Moenie vereis dat die twee kliënte dieselfde teks druk nie. 'n OpenVPN redirect-gateway def1 word gewoonlik as twee halfprefiksroetes uitgedruk eerder as een verstek, en 'n bestuurder wat dit anders vertoon is daardeur nie verkeerd nie. Beoordeel dekking, wat die soektogte wys, eerder as formatering.

Waar die twee kliënte wettig verskil

Kliënterverstekke is beleidskeuses, en hulle mag verskil. Een produk verkies dalk 'n vol tonnel, 'n ander hou die plaaslike verstek en roeteer net die private prefikse, en 'n derde volg wat die bediener gestoot het. 'n Verskil is net 'n fout wanneer dit die vereiste weerspreek wat jy gekry het.

Vergelyk dus elke kliënt met die goedgekeurde gesplitste of voltonnel-bedoeling, nie met mekaar nie. As die vereiste is dat private verkeer die tonnel gebruik en die plaaslike internetpad plaaslik bly, dan is 'n vol tonnel die fout en 'n gesplitste tonnel korrek, maak nie saak watter kliënt wat gedoen het nie. Skryf die bedoeling neer voordat jy na enige konfigurasie kyk, anders word die eerste kliënt wat jy inspekteer stilweg die standaard.

DNS is 'n tweede as en dit faal onafhanklik. 'n Korrekte roete kan steeds navrae stuur aan 'n oplosser wat nie vir die private sone kan antwoord nie, en 'n korrekte oplosser maak nie 'n verkeerde roete reg nie. Kontroleer albei, en beskou 'n private naam wat resolveer terwyl 'n private adres dit nie doen as bewys dat die twee lae apart opgelos word.

Hou die vergelyking skoon

Laat een verbindingseienaar op 'n slag loop. 'n Opdragreël-OpenVPN-sessie wat langs die ingevoerde profiel loop, installeer sy eie roetes en sy eie oplosserstatus, en die mengsel wat ontstaan is nie een van die twee kliënte se gedrag nie. Breek een af voordat jy die ander meet. Herbegin as jy onseker is wat nog toestand hou, want 'n verouderde roete van 'n uur gelede lyk presies soos 'n beleidsprobleem.

Hou alles anders ook vas: dieselfde eindpunt, dieselfde rekening, dieselfde sagtewareweergawes, dieselfde netwerk. 'n Sukses op 'n kollega se Windows-skootrekenaar toets 'n ander kliënt, 'n ander oplosserintegrasie en moontlik 'n ander bedienerprofiel, so dit is nie bewys oor die Ubuntu-bestuurder nie.

NetworkManager se IPv4-instellingsverwysing definieer never-default en die gestoorde roeteeienskappe presies, wat die moeite werd is om te lees voordat jy 'n bestuurde waarde verander. En onthou die omvang van hierdie vergelyking: dit dek IPv4, en dit sê niks oor die ooreenstemmende IPv6-beleid nie, wat sy eie verstekke en sy eie manier het om jou te verras.