Ein VPN-peer pingar andre grensesnitt fordi dei er lokale

Ein WireGuard-klient koplar til og pingar ei adresse på eit heilt anna grensesnitt, og svaret kjem. Opptak viser førespurnaden berre på tunnelen. Ingenting er øydelagt, og videresendingsinnstillinga som vart slått av med omhug har ingenting med saka å gjere. Dette er ein samanliknad mellom to vegar som ser like ut i eit diagram og er heilt ulike i kjernen.

Den eine vegen videresender pakkar for nokon andre; den andre leverer dei til verten sjølv.

Ein pakke adressert til verten blir i verten

Den eksterne klienten sender ein IP-pakke til ei adresse verten eig. Rutinga stiller eitt spørsmål om den pakken: er denne destinasjonen lokal? Kvar adresse verten har, viser seg i den lokale rutetabellen, og den tabellen blir konsultert før hovudtabellen, så pakken går til verten sin eigen stakk i staden for ut gjennom eit anna grensesnitt. Svaret blir generert lokalt, og det reiser tilbake gjennom tunnelen fordi det var der førespurnaden kom frå.

Det er heile mekanismen. Ingen videresending skjer, inga endring av grensesnitttilstand er involvert, og adressa det gjeld treng ikkje vere nåbar frå noko anna stad.

Kvifor ip_forward ikkje gjeld

Videresending styrer pakkar som må forlate gjennom eit anna grensesnitt enn det dei kom inn på. Ein ping til verten sjølv tek aldri den vegen: pakken blir forbrukt lokalt, og svaret blir generert lokalt. Derfor endrar innstillinga net.ipv4.ip_forward=0 ingenting her, og ein regel i videresendingskjeda ser aldri trafikken. Den rette kontrollen sit på inngangsvegen, avgrensa av innkommande grensesnitt eller kjelde.

Derfor skapar det falsk tryggleik å slå av videresending og anta at verten er isolert.

Les den lokale tabellen som bestemte

ip rule show rapporterer vanlegvis ein regel med prioritet null som sender alle oppslag til den lokale tabellen først, og ip route show table local listar opp verten sine eigne adresser med lokal omfang. Den tabellen omfattar adresser på grensesnitt som er administrativt nede men framleis konfigurerte. IPv4-adresser som er tildelte statisk overlever vanlegvis eit lenkebrot, og det er derfor ein ping til ei nedslått bru framleis kan lukkast og overraske operatøren.

IPv6 er usamd på nøyaktig dette punktet. Adressene blir vanlegvis trekte tilbake når lenka fell, med mindre keep_addr_on_down er sett. Samanlikn familiane i staden for å anta at éin regel dekkjer begge.

Kva ein peer faktisk når

Eit svar frå rutaren si eiga adresse på eit segment seier ingenting om maskinene bak det segmentet. Peeren kan ikkje nå ein vert bak det andre grensesnittet via denne vegen; han når berre adresser rutaren sjølv eig. Å teste ei teneste på ein separat LAN-vert, i staden for å pinge rutaradressa, er det som fastslår om videresending i det heile er tillaten.

Å avgrense ein peer til tenester som er bundne til tunneladressa er eit spørsmål om inngangspolicy. Tillat den ønskte tenesta på tunnelegrensesnittet og avgrens kjeldene som kan bruke ho, fordi pakken faktisk kjem dit.

Kontroller også adresser du hadde tenkt å fase ut. Å fjerne ei adresse frå eit grensesnitt er meir påliteleg enn å stable brannmurreglar oppå ei utdatert.