En VPN-peer pinger andre grensesnitt fordi de er lokale
Den lokale rutetabellen sender pakker til enhver adresse verten eier, uansett hvilket grensesnitt den ligger på. Videresendingsinnstillinger kommer aldri inn på den veien.
En WireGuard-klient kobler til og pinger en adresse på et helt annet grensesnitt, og svaret kommer. Opptak viser forespørselen bare på tunnelen. Ingenting er ødelagt, og videresendingsinnstillingen som ble slått av med omhu har ingenting med saken å gjøre. Dette er en sammenligning mellom to veier som ser like ut i et diagram og er helt forskjellige i kjernen.
Den ene veien videresender pakker for noen andre; den andre leverer dem til verten selv.
En pakke adressert til verten blir i verten
Den eksterne klienten sender en IP-pakke til en adresse verten eier. Rutingen stiller ett spørsmål om den pakken: er denne destinasjonen lokal? Enhver adresse verten har, vises i den lokale rutetabellen, og den tabellen konsulteres før hovedtabellen, så pakken går til vertens egen stakk i stedet for ut gjennom et annet grensesnitt. Svaret genereres lokalt, og det reiser tilbake gjennom tunnelen fordi det var der forespørselen kom fra.
Det er hele mekanismen. Ingen videresending skjer, ingen endring av grensesnitttilstand er involvert, og adressen det gjelder trenger ikke være nåbar fra noe annet sted.
Hvorfor ip_forward ikke gjelder
Videresending styrer pakker som må forlate gjennom et annet grensesnitt enn det de kom inn på. En ping til verten selv tar aldri den veien: pakken forbrukes lokalt, og svaret genereres lokalt. Derfor endrer innstillingen net.ipv4.ip_forward=0 ingenting her, og en regel i videresendingskjeden ser aldri trafikken. Den riktige kontrollen sitter på inngangsveien, avgrenset av innkommende grensesnitt eller kilde.
Derfor skaper det en falsk trygghet å slå av videresending og anta at verten er isolert.
Les den lokale tabellen som bestemte
ip rule show rapporterer vanligvis en regel med prioritet null som sender alle oppslag til den lokale tabellen først, og ip route show table local lister opp vertens egne adresser med lokal omfang. Den tabellen omfatter adresser på grensesnitt som er administrativt nede men fortsatt konfigurert. IPv4-adresser som er tildelt statisk overlever vanligvis et lenkebrudd, og det er derfor en ping til en nedslått bro fortsatt kan lykkes og overraske operatøren.
IPv6 er uenig på nøyaktig dette punktet. Adressene trekkes vanligvis tilbake når lenken faller, med mindre keep_addr_on_down er satt. Sammenlign familiene i stedet for å anta at én regel dekker begge.
Hva en peer faktisk når
Et svar fra ruterens egen adresse på et segment sier ingenting om maskinene bak det segmentet. Peeren kan ikke nå en vert bak det andre grensesnittet via denne veien; den når bare adresser ruteren selv eier. Å teste en tjeneste på en separat LAN-vert, i stedet for å pinge ruterens adresse, er det som fastslår om videresending i det hele tatt er tillatt.
Å begrense en peer til tjenester som er bundet til tunneladressen er et spørsmål om inngangspolicy. Tillat den ønskede tjenesten på tunnelegrensesnittet og begrens kildene som kan bruke den, fordi pakken faktisk ankommer der.
Kontroller også adresser du hadde tenkt å utfase. Å fjerne en adresse fra et grensesnitt er mer pålitelig enn å stable brannmurregler oppå en utdatert.