At gøre den bærbare computer til en router er en populær måde at løse det forkerte problem på. Videresendelse findes, så en maskine kan sende pakker videre, hvis destination ikke er maskinen selv, og den har ingen mening om, hvor hurtigt en browser på samme maskine indlæser en side. De to veje ligner kun hinanden, fordi begge sender trafik gennem én tunnel. Skil dem ad én gang, og en stor del af rådene om at slå videresendelse til eller åbne firewallen viser sig at beskrive en topologi, du ikke har.

To pakkeveje, der ser identiske ud fra skrivebordet

Browseren på den bærbare computer opretter sin egen anmodning. Værten vælger tunnelruten, klientprocessen pakker pakken ind og sender den til modparten, og svaret kommer tilbage til programmet. Intet i den sekvens krydser en videresendelsesbeslutning, fordi denne maskine både er kilden og destinationen for samtalen.

Sæt nu en anden enhed på et bevidst konfigureret Ethernet-segment, og gør den bærbare computer til dens standardgateway. Den enhed starter anmodningen, den bærbare computer modtager en pakke adresseret et andet sted, og kernen skal beslutte, om den skal sendes videre. Det er videresendelsesrollen, og den kommer med forudsætninger, som klientrollen aldrig havde brug for: en tilladt transitvej, ruter på begge sider og en returvej, der stadig virker, hvis oversættelse er en del af designet.

RoleWho originates the trafficWhat has to be true
Client onlyThe laptop itselfTunnel route, working resolver, supported profile
GatewayAnother deviceForwarding enabled, permitted transit, routes both ways, return-path decision

Hvad ip_forward egentlig ændrer

Kernens IPv4 sysctl-dokumentation beskriver ip_forward som den kontakt, der lader en vært videresende pakker mellem grænseflader. Det er ikke en hurtig vej for trafik, som værten selv har genereret, og ingen læsning af den parameter gør en lokal browser hurtigere. Om noget tilføjer videresendelse tilstand og politik til en maskine, der før lavede mindre arbejde.

Den samme dokumentation advarer om, at ændring af værdien nulstiller andre IPv4-parametre til deres standardværdier for vært eller router. Det gør kontakten til en konfigurationshændelse snarere end en prøve: finjusterede indstillinger kan rulle tilbage under dig, og ændringen kan være ansvarlig for en regression, som ingen ville tænke på at tilskrive den. Det betyder også, at kontakten bør sættes én gang, bevidst, af den, der ejer gateway-rollen. At vippe den under en undersøgelse af langsomhed er det ene tilfælde, hvor bivirkningen med garanti forveksles med symptomet.

Tre firewallspørgsmål, der ikke er det samme spørgsmål

At tillade en VPN-lytter, at tillade de tjenester, den bærbare computer kører, og at tillade trafik at passere gennem den bærbare computer er tre separate tilladelser. Den første lader en modpart nå en daemon, den anden blotlægger noget lokalt, og den tredje gør maskinen til transit for en anden. Hver har et forskelligt omfang, og den sidste er langt bredere end de svar, en almindelig udgående applikation har brug for.

Når en bestemt strøm er blokeret, navngiv dens kilde, destination, retning og politikejer, før du redigerer en regel. En smal regel for den strøm er en rettelse; at acceptere alt på tunnelgrænsefladen er en politikændring, der tilfældigvis indeholder rettelsen. En browser, der virker bagefter, beviser, at strømmen virker, ikke at den brede regel var nødvendig.

Mål først, når vejen er korrekt

Mål med samme destination, samme arbejdsbelastning og sammenlignelige forhold, og ændr én variabel ad gangen. En test, der samler en videresendelsesændring, en udvidelse af firewallen og en kopieret cipher-indstilling, giver et tal og ingen forklaring, fordi intet i den fortæller, hvilken af de tre der flyttede resultatet.

Hold rute- og resolverfejl helt ude af ydelsessamtalen. Et navn, der opløses langsomt, er ikke et gennemstrømningsproblem, og en overførsel, der stopper ved én fast størrelse, er normalt et MTU-spørgsmål og ikke en hastighedsgrænse. Skriv ned, hvilken af de tre du faktisk observerede, før du sammenligner nogen tal. Ellers arver den næste læser en måling, der måler det forkerte, og en ændring, som ingen kan retfærdiggøre.

Beskriv den topologi, du har, ikke etiketten på klienten

En bærbar computer, der deler sin forbindelse, hoster et routet containernetværk eller bærer trafik for en virtuel maskine, er en gateway, uanset hvad softwaren kalder sig selv. Ordet klient beskriver, hvordan tunnelen er konfigureret, ikke om pakker sendes videre til en anden.

Gør rollen eksplicit i driftsproceduren: hvad der skaber trafik, hvad der skal passere gennem maskinen, og hvilken af de to den aktuelle opgave handler om. Aktivér gateway-rollen, når den hører til den understøttede plan, ikke som en uforklaret hastighedsjustering anvendt på en topologi, der aldrig havde brug for en.

Relaterede artikler