Are un laptop cu VPN nevoie de redirecționare IP ca să fie mai rapid?
Redirecționarea trece pachete între interfețe; nu accelerează un browser local. Separați rolul de client de rolul de poartă înainte de a lărgi o regulă.
Transformarea laptopului într-un router este o modalitate populară de a rezolva problema greșită. Redirecționarea există pentru ca o mașină să poată trece mai departe pachete a căror destinație nu este ea însăși, și nu are nicio părere despre cât de repede încarcă o pagină un browser de pe aceeași mașină. Cele două căi arată la fel doar pentru că ambele trimit trafic printr-un singur tunel. Separați-le o dată și o mare parte din sfaturile despre activarea redirecționării sau deschiderea firewall-ului se dovedesc a descrie o topologie pe care nu o aveți.
Două căi de pachete care de la birou par identice
Browserul de pe laptop își creează propria cerere. Gazda alege ruta tunelului, procesul client împachetează pachetul și îl trimite partenerului, iar răspunsul se întoarce la aplicație. Nimic din acea secvență nu traversează o decizie de redirecționare, pentru că această mașină este atât sursa, cât și destinația conversației.
Acum puneți un alt dispozitiv pe un segment Ethernet configurat intenționat și faceți din laptop poarta lui implicită. Acel dispozitiv inițiază cererea, laptopul primește un pachet adresat altundeva, iar nucleul trebuie să decidă dacă îl trece mai departe. Acesta este rolul de redirecționare, și vine cu condiții pe care rolul de client nu le-a avut niciodată: o cale de tranzit permisă, rute pe ambele părți și o cale de întoarcere care încă funcționează dacă traducerea face parte din proiect.
| Role | Who originates the traffic | What has to be true |
|---|---|---|
| Client only | The laptop itself | Tunnel route, working resolver, supported profile |
| Gateway | Another device | Forwarding enabled, permitted transit, routes both ways, return-path decision |
Ce schimbă de fapt ip_forward
Documentația nucleului despre IPv4 sysctl descrie ip_forward ca întrerupătorul care permite unei gazde să redirecționeze pachete între interfețe. Nu este o cale rapidă pentru traficul pe care gazda l-a generat singură, și nicio citire a acelui parametru nu face un browser local mai rapid. Dacă ceva, redirecționarea adaugă stare și politică unei mașini care înainte făcea mai puțină muncă.
Aceeași documentație avertizează că schimbarea valorii readuce alți parametri IPv4 la valorile lor implicite pentru gazdă sau router. Asta face din întrerupător un eveniment de configurare și nu o probă: setările reglate pot reveni sub picioarele dumneavoastră, iar schimbarea poate fi responsabilă pentru o regresie pe care nimeni nu s-ar gândi să i-o atribuie. Înseamnă, de asemenea, că întrerupătorul trebuie setat o dată, deliberat, de cine deține rolul de poartă. Comutarea lui în timpul unei investigații a încetinirii este singurul caz în care efectul secundar este garantat confundat cu simptomul.
Trei întrebări de firewall care nu sunt aceeași întrebare
Permiterea unui ascultător VPN, permiterea serviciilor pe care le rulează laptopul și permiterea traficului să treacă prin laptop sunt trei permisiuni separate. Prima lasă un partener să ajungă la un demon, a doua expune ceva local, iar a treia transformă mașina în tranzit pentru altcineva. Fiecare are o altă anvergură, iar ultima este mult mai largă decât răspunsurile de care are nevoie o aplicație obișnuită de ieșire.
Când un flux anume este blocat, numiți sursa, destinația, direcția și proprietarul politicii înainte de a edita o regulă. O regulă îngustă pentru acel flux este o corectare; acceptarea tuturor pe interfața tunelului este o schimbare de politică ce include din întâmplare corectarea. Un browser care funcționează după aceea dovedește că fluxul funcționează, nu că regula largă era necesară.
Măsurați doar când calea este corectă
Măsurați cu aceeași destinație, aceeași încărcare și condiții comparabile și schimbați o singură variabilă o dată. Un test care grupează o modificare de redirecționare, o lărgire a firewall-ului și o setare de cifrare copiată produce un număr și nicio explicație, pentru că nimic din el nu spune care dintre cele trei a mișcat rezultatul.
Țineți eșecurile de rută și de resolver complet în afara conversației despre performanță. Un nume care se rezolvă încet nu este o problemă de debit, iar un transfer care se oprește la o dimensiune fixă este de obicei o chestiune de MTU și nu o limită de viteză. Notați care dintre aceste trei lucruri le-ați observat cu adevărat înainte de a compara orice numere. Altfel cititorul următor moștenește o măsurătoare care măsoară lucrul greșit și o modificare pe care nimeni nu o poate justifica.
Descrieți topologia pe care o aveți, nu eticheta de pe client
Un laptop care își partajează conexiunea, găzduiește o rețea rutată de containere sau transportă trafic pentru o mașină virtuală este o poartă, oricum s-ar numi software-ul. Cuvântul client descrie cum este configurat tunelul, nu dacă pachetele sunt trecute altcuiva.
Faceți rolul explicit în manualul de operare: ce generează trafic, ce trebuie să traverseze mașina și care dintre cele două privește sarcina curentă. Activați rolul de poartă când aparține planului acceptat, nu ca o ajustare de viteză neexplicată aplicată unei topologii care nu a avut niciodată nevoie de așa ceva.