Waarom route-nopull alleen die lêerserver onbereikbaar laat
Om gepushte roetes te ignoreer is net die helfte van 'n gesplete tonnel. Kies die roete-eienaar, voeg die kantoorvoorvoegsel met die hand by, en toets drie vloeie voordat jy dit as reg beskou.
Die lêerserver maak fyn oop, en die video-oproep in die volgende venster begin hakkel. Niks is stadig nie en geen MTU is verkeerd nie: jou kliënt het die roetelys aanvaar wat die bediener hom gegee het, so elke pakkie verlaat nou deur die kantoor se firewall. Die oplossing is nie nog 'n instellingsvlag nie, maar 'n besluit oor wie die kliënt se roetetabel besit. Daardie besluit hoort op een plek, en die foutmodusse hieronder wys jou watter plek jy eintlik gekies het.
Besluit wie die roetetabel besit
Drie eienaars is moontlik. Die bediener kan roetes en 'n verstekgateway pus, in welke geval die kliënt installeer wat hom gesê word en 'n voltonnel word. Die kliëntprofiel kan eienaarskap neem deur pusse te verwerp en sy eie roetelyne te dra. 'n Lessenaarverbindingsbestuurder kan ook die besluit besit deur sy eie roete- en verstekroete-eienskappe.
Elke keuse misluk op 'n ander manier, daarom is dit die moeite werd om die tabel te lees voordat jy 'n profiel wysig. Die ry wat by jou simptoom pas, is die eienaar wat jy werklik het.
| Owner | Where it lives | Result |
|---|---|---|
| Server | server config, redirect-gateway, pushed routes | client becomes a full tunnel |
| Profile | route-nopull and its own route lines | tunnel up, office prefix missing |
| Manager | never-default plus its own routes | desktop decides, profile ignored |
Kies een en skryf dit neer. Om twee te meng laat 'n gasheer wie se verstekpad sy eie dokumentasie weerspreek, en die volgende ingenieur kan nie sien watter laag gewen het nie. Skrap die verloorder uitdruklik.
route-nopull filter pusse, dit voeg nie roetes by nie
route-nopull hoort in die kliëntprofiel, en sy volgorde in daardie lêer maak nie saak nie, want dit verwerp net waardes wat van die bediener kom. Dit verwerp gepushte roetes, insluitend 'n gepushte verstekroete, terwyl die tonnel nog steeds normaal opkom.
Die gevolg wat mense miskyk, is dat gepushte DHCP-opsies saamgaan. DNS-instellings wat die bediener stuur, word ook verwerp, so interne name hou op om te resolveer selfs al is die tonnel gesond en die bediener bereikbaar per adres.
Dit laat 'n tonnel sonder 'n pad na die kantoorvoorvoegsel, tensy jy self een byvoeg: route-nopull gevolg deur route 10.30.0.0 255.255.0.0 in dieselfde profiel. Daardie reël dra 'n adres en 'n masker; dit noem nie 'n volgende sprong nie.
'n Alternatiewe vorm voeg 'n gateway-token by, route 10.30.0.0 255.255.0.0 vpn_gateway, wat die inskrywing by die naam na die tonnel wys. Invoerders verskil in of hulle daardie variant vertaal, so ondersoek die gestoorde verbinding as die inskrywing in die kerntabel ontbreek.
Verifieer met roetesoektogte, nie met 'n ping nie
'n Ping sê vir jou dat iets geantwoord het. 'n Roetesoektog sê vir jou watter koppelvlak die kernel sou kies, en dit is die vraag wat jy eintlik gevra het. Vier kort opdragte skei 'n ontbrekende roete van 'n roete wat na die verkeerde toestel wys.
Lees wat die tonnel geïnstalleer het met ip route show dev tun0. Geen uitset hoegenaamd beteken nul roetes, wat nie 'n gesplete tonnel is wat werk nie, en dit is die gewone uitkoms van die byvoeg van die filter sonder die eksplisiete reël.
Kontroleer dan een kantooradres met ip route get 10.30.5.7, en een gewone internetadres met ip route get 1.1.1.1. Die tweede moet die fisiese koppelvlak noem; as dit die tonnel noem, is die push glad nie gefiltreer nie.
Lees laastens ip rule, want 'n beleidsreël wat deur 'n vroeëre poging gelaat is, kan die tabel wat jy pas reggestel het, oorheers. 'n Korrekte profiel met 'n verouderde reël bo-op lyk presies soos 'n stukkende profiel. Skrap die reël wat jy laas bygevoeg het voordat jy nog een byvoeg.
Oorvleuelende subnette lyk soos 'n stukkende tonnel
Twee private reekse kan uit die kliënt se oogpunt identies wees, en dit is waar 'n gesplete tonnel vir iets wat hy nie veroorsaak het nie, die skuld kry. As die kantoor dieselfde voorvoegsel uitdeel as wat jou tuisroeteerder gebruik, dek die tonnelroete die roeteerder en die huisnetwerk lyk of dit verdwyn.
Vergelyk die adres op jou eie koppelvlak met die roete wat die profiel installeer, deur 'n gewone adreslys te gebruik voordat jy iets verander. Die oorvleueling is werklik, en geen profielopsie los dit op nie. Wat jy kan regstel, is die benaming, sodat die volgende persoon twee reekse sien eerder as een.
Die eerlike oplossings is om een kant te hernommer of om adresse by die kantoor te vertaal. Om 'n enkele gasheerroete na die roeteerder vas te pen, werk totdat die roeteerderadres verander, en dan word dit 'n tweede raaisel bo-op die eerste.
Laat die besluit 'n heropverbinding oorleef
Inskrywings wat met die hand getik is, oorleef nie 'n heropverbinding nie, en 'n verbindingsbestuurder bou die tabel elke keer as die profiel begin, weer op. Plaas die besluit waar die verbinding geskep word, of dit die profiel of die bestuurder se gestoorde instellings is. Herbegin dan die verbinding een keer doelbewus eerder as om die gedrag tydens 'n oproep te ontdek. 'n Profiel wat net tot die volgende heropverbinding werk, is nie klaar nie.
Oefen drie paaie gelyktydig: 'n kantoor-gasheer per letterlike adres, dieselfde gasheer per naam, en 'n gewone openbare webwerf. Die middelste een hang af van die naamdiens wat jy opgestel het nadat jy die gepushte DNS-opsies laat vaar het, en dit is die een wat stilweg misluk.