Per què route-nopull sol deixa el servidor de fitxers inabastable
Ignorar les rutes emeses és només la meitat d’un túnel dividit. Trieu el propietari de la ruta, afegiu el prefix de l’oficina a mà i proveu tres fluxos abans de donar-ho per arreglat.
El servidor de fitxers s’obre bé, i la videotrucada de la finestra del costat comença a entretallar-se. No hi ha res lent ni cap MTU incorrecte: el vostre client ha acceptat la llista de rutes que li ha donat el servidor, així que cada paquet surt ara pel tallafoc de l’oficina. L’arranjament no és una altra bandera d’ajustament sinó una decisió sobre qui és propietari de la taula de rutes del client. Aquesta decisió pertany a un sol lloc, i les maneres de fallar que hi ha a continuació us diuen quin lloc heu triat realment.
Decidiu qui és propietari de la taula de rutes
Hi ha tres propietaris possibles. El servidor pot emetre rutes i una passarel·la per defecte, i llavors el client instal·la el que li diuen i es converteix en un túnel complet. El perfil del client pot prendre la propietat descartant les emissions i portant les seves pròpies línies de ruta. Un gestor de connexions d’escriptori també pot posseir la decisió a través de les seves pròpies propietats de ruta i de ruta per defecte.
Cada opció falla d’una manera diferent, i per això val la pena llegir la taula abans d’editar un perfil. La fila que coincideix amb el vostre símptoma és el propietari que teniu en realitat.
| 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 |
Trieu-ne un i escriviu-lo. Barrejar-ne dos deixa un amfitrió el camí per defecte del qual contradiu la seva pròpia documentació, i el següent enginyer no pot saber quina capa ha guanyat. Suprimiu el perdedor explícitament.
route-nopull filtra les emissions, no afegeix rutes
route-nopull pertany al perfil del client, i el seu ordre en aquest fitxer és irrellevant perquè només descarta els valors que venen del servidor. Descarta les rutes emeses, inclosa una ruta per defecte emesa, mentre el túnel encara s’aixeca amb normalitat.
La conseqüència que la gent no veu és que les opcions DHCP emeses se’n van amb elles. La configuració DNS que envia el servidor també es descarta, així que els noms interns deixen de resoldre’s encara que el túnel estigui sa i el servidor sigui abastable per adreça.
Això deixa un túnel sense camí cap al prefix de l’oficina tret que n’afegiu un vosaltres mateixos: route-nopull seguit de route 10.30.0.0 255.255.0.0 al mateix perfil. Aquesta línia porta una adreça i una màscara; no anomena un salt següent.
Una forma alternativa afegeix un testimoni de passarel·la, route 10.30.0.0 255.255.0.0 vpn_gateway, que apunta l’entrada al túnel pel nom. Els importadors difereixen en si tradueixen aquesta variant, així que inspeccioneu la connexió desada si l’entrada falta de la taula del nucli.
Verifiqueu amb consultes de ruta, no amb un ping
Un ping us diu que alguna cosa ha respost. Una consulta de ruta us diu quina interfície triaria el nucli, i aquesta és la pregunta que heu fet realment. Quatre ordres curtes separen una ruta que falta d’una ruta que apunta al dispositiu equivocat.
Llegiu què ha instal·lat el túnel amb ip route show dev tun0. Cap sortida significa zero rutes, que no és un túnel dividit que funcioni, i és el resultat habitual d’afegir el filtre sense la línia explícita.
Després comproveu una adreça de l’oficina amb ip route get 10.30.5.7, i una adreça d’internet corrent amb ip route get 1.1.1.1. La segona ha d’anomenar la interfície física; si anomena el túnel, l’emissió no s’ha filtrat gens.
Finalment llegiu ip rule, perquè una regla de política deixada per un intent anterior pot anul·lar la taula que acabeu de corregir. Un perfil correcte amb una regla obsoleta a sobre sembla exactament un perfil trencat. Suprimiu la regla que vau afegir l’última vegada abans d’afegir-ne una altra.
Les subxarxes superposades semblen un túnel trencat
Dos rangs privats poden ser idèntics des del punt de vista del client, i és aquí on un túnel dividit rep la culpa d’alguna cosa que no ha causat. Si l’oficina reparteix el mateix prefix que fa servir el vostre router de casa, la ruta del túnel cobreix el router i la xarxa de casa sembla desaparèixer.
Compareu l’adreça de la vostra pròpia interfície amb la ruta que instal·la el perfil, fent servir un llistat d’adreces simple abans de canviar res. La superposició és real, i cap opció del perfil la resol. El que sí que podeu arreglar és l’anomenament, perquè la propera persona vegi dos rangs en lloc d’un.
Els arranjaments honestos són renumerar un costat o traduir adreces a l’oficina. Fixar una única ruta d’amfitrió al router funciona fins que canvia l’adreça del router, i llavors es converteix en un segon misteri a sobre del primer.
Feu que la decisió sobrevisqui a una reconnexió
Les entrades escrites a mà no sobreviuen a una reconnexió, i un gestor de connexions reconstrueix la taula cada vegada que s’inicia el perfil. Poseu la decisió on es crea la connexió, tant si és el perfil com la configuració desada del gestor. Després reinicieu la connexió un cop expressament en lloc de descobrir el comportament durant una trucada. Un perfil que només funciona fins a la propera reconnexió no està acabat.
Exerciu tres camins alhora: un amfitrió de l’oficina per adreça literal, el mateix amfitrió pel nom, i un lloc públic normal. El del mig depèn del servei de noms que heu configurat després de deixar anar les opcions DNS emeses, i és el que falla en silenci.