En WireGuard-klient opretter forbindelse og pinger en adresse på en helt anden grænseflade, og svaret ankommer. Optagelser viser kun anmodningen på tunnelen. Intet er i stykker, og den videresendelsesindstilling, der omhyggeligt blev slået fra, har intet med det at gøre. Dette er en sammenligning mellem to veje, der ser ens ud på et diagram og er helt forskellige i kernen.

Den ene vej videresender pakker for en anden; den anden leverer dem til værten selv.

En pakke, der er adresseret til værten, bliver i værten

Den fjernede klient sender en IP-pakke til en adresse, som værten ejer. Rutning stiller ét spørgsmål om den pakke: er denne destination lokal? Enhver adresse, værten har, optræder i den lokale rutningstabel, og den tabel konsulteres før hovedtabellen, så pakken går til værtens egen stak i stedet for ud gennem en anden grænseflade. Svaret genereres lokalt, og det rejser tilbage gennem tunnelen, fordi det er der, forespørgslen kom fra.

Det er hele mekanismen. Der sker ingen videresendelse, ingen ændring af grænsefladetilstand er involveret, og den pågældende adresse behøver ikke at være nåbar fra noget andet sted.

Hvorfor ip_forward ikke gælder

Videresendelse styrer pakker, der skal forlade gennem en anden grænseflade end den, de ankom på. Et ping til værten selv tager aldrig den vej: pakken forbruges lokalt, og svaret genereres lokalt. Derfor ændrer indstillingen net.ipv4.ip_forward=0 intet her, og en regel i videresendelseskæden ser aldrig trafikken. Den korrekte kontrol sidder på inputvejen, afgrænset af indgående grænseflade eller kilde.

Derfor skaber det en falsk tryghed at slå videresendelse fra og antage, at værten er isoleret.

Læs den lokale tabel, der afgjorde det

ip rule show rapporterer normalt en regel med prioritet nul, der sender alle opslag til den lokale tabel først, og ip route show table local viser værtens egne adresser med lokalt omfang. Den tabel omfatter adresser på grænseflader, der er administrativt nede, men stadig konfigureret. IPv4-adresser, der er tildelt statisk, overlever normalt et linktab, og det er derfor, et ping til en nedlagt bro stadig kan lykkes og overraske operatøren.

IPv6 er uenig på præcis dette punkt. Dets adresser trækkes normalt tilbage, når linket falder, medmindre keep_addr_on_down er sat. Sammenlign familierne i stedet for at antage, at én regel dækker begge.

Hvad en modpart faktisk når

Et svar fra routerens egen adresse på et segment siger intet om maskinerne bag det segment. Modparten kan ikke nå en vært bag den anden grænseflade ad denne vej; den når kun adresser, som routeren selv ejer. At teste en tjeneste på en separat LAN-vært i stedet for at pinge routerens adresse er det, der afgør, om videresendelse overhovedet er tilladt.

At begrænse en modpart til tjenester, der er bundet til tunneladressen, er et spørgsmål om inputpolitik. Tillad den ønskede tjeneste på tunnelegrænsefladen, og begræns de kilder, der må bruge den, fordi pakken faktisk ankommer der.

Kontroller også adresser, du havde tænkt at udfase. At fjerne en adresse fra en grænseflade er mere pålideligt end at stable firewallregler oven på en forældet en.

Relaterede artikler