A subida da VPN máis lenta ca baixada? Decida que límite está a atopar

A maioría das liñas de acceso son asimétricas, así que un túnel normalmente sobe máis lentamente do que baixa, e esa é a resposta esperada e non un fallo. A pregunta interesante é se a súa subida está limitada pola liña, por outra cousa que xa a usa ou por un fluxo que se atasca en lugar de ir constante. Eses tres producen a mesma queixa e esixen un traballo distinto.

Tres límites que desde a barra de progreso parecen idénticos

A capacidade é o primeiro, e é unha propiedade do produto de acceso, non do túnel. Un enlace ascendente de poucos megabits é normal en fibra residencial e en moitos plans móbiles, e o custo do cifrado é pequeno fronte a esa diferenza. A encapsulación tamén engade bytes por paquete, o que recorta o rendemento útil nas dúas direccións e non só nunha, así que por si soa non pode explicar unha asimetría grande.

A contención é o segundo. A sincronización na nube, as fototecas e os axentes de actualización soben mentres o equipo parece inactivo, e un segundo dispositivo na mesma liña fai o mesmo. A cola é o terceiro: un enlace ascendente saturado empurra o tráfico interactivo detrás dos datos masivos, así que as chamadas córtanse mentres a propia transferencia informa dun progreso saudable.

Mida unha dirección á vez

Use o mesmo dispositivo, o mesmo perfil e o mesmo destino, e nunca execute as dúas direccións á vez salvo que a contención sexa xusto o que quere observar. Pare as súas propias transferencias opcionais antes da primeira execución. Dúas execucións cunha bandeira entre elas resolven a maior parte.

iperf3 envía desde o cliente por defecto, así que a execución simple mide a súa ruta de subida; -R inverte a dirección e mide a baixada. Execúteas con uns minutos de diferenza e anote ambos os números en lugar de facer a media:

iperf3 -c speed.example.net -t 30 -P 4
iperf3 -c speed.example.net -t 30 -P 4 -R

Se a cifra de subida é unha fracción pequena da de baixada e se mantén estable entre execucións, a forma corresponde a unha liña de acceso asimétrica e o túnel non é a historia. Se a subida oscila entre execucións ou se derruba aos dez segundos, siga lendo.

Decida por onde cambia a subida

Cambie unha variable á vez e observe que dirección se move. Un segundo punto final de VPN que sobe mellor apunta a ese punto final ou á ruta ata el. A mesma subida lenta desde un segundo dispositivo na mesma liña apunta á liña. Un dispositivo distinto nunha liña distinta que tamén é lento apunta á política de entrada do destino, que non pode arranxar localmente.

Anote bytes por segundo e tempo transcorrido para a mesma carga, non unha única puntuación de velocidade. Un cliente de copias de seguridade e unha proba de velocidade usan destinos e concorrencia distintos, así que comparar as súas cifras non responde nada. Se as peticións pequenas van ben e só se arrastran as transferencias grandes, o límite probablemente non é o ancho de banda.

Para o uso diario, limitar unha subida en segundo plano ou programala fóra das horas de reunións adoita axudar máis que calquera axuste do túnel. Xulgue ese cambio pola carga combinada: unha copia de seguridade que remata máis tarde pero xa non estraga as chamadas adoita ser o mellor intercambio.

Cando o atasco vence a lentitude

Unha transferencia que se conxela nun punto repetible e logo se retoma compórtase como un problema de MTU da ruta e non como un límite de velocidade. O túnel reduce a carga útil por paquete, e un dispositivo que descarta a mensaxe ICMP resultante deixa o emisor adiviñando. Ese patrón merece a súa propia proba, porque a reparación é distinta de axustar unha velocidade. Unha cifra baixa e estable apunta á capacidade, mentres que un estalido seguido de silencio apunta a unha carga que a ruta non pode levar.

Probe a ruta cunha carga que non deba fragmentarse e logo compare a MTU da interface do túnel co valor que pasa:

ping -M do -s 1400 -c 3 203.0.113.10
ip link show dev tun0 | grep -o "mtu [0-9]*"

Se a sonda grande desaparece mentres unha pequena ten éxito, aperte o TCP MSS no túnel en lugar de baixar a MTU da interface para cada protocolo. Os atascos persistentes despois dese punto pertencen ao almacenamento ou ao ritmo da aplicación receptora, non á ruta de rede.

Que cambiar e que deixar

Cambie as cousas que controla: os horarios de transferencia en segundo plano, a elección de punto final e a MSS para unha ruta que se atasca. Manteña cada cambio reversible e limitado a unha carga. Deixe en paz as cousas que a medición di que están ben, incluída unha velocidade de baixada que xa coincide coa liña.

Anote as cifras de antes e despois xunto co perfil, o punto final e a hora do día, porque un problema de subida que se move co punto final é unha cuestión de encamiñamento e un que se move co dispositivo é local. Ese rexistro é o que converte unha queixa vaga nunha decisión, e custa dúas execucións da mesma orde.