’n VPN-portaal ping ander koppelvlakke omdat hulle plaaslik is

’n WireGuard-kliënt maak verbinding en ping ’n adres op ’n heeltemal ander koppelvlak, en die antwoord kom aan. Opnames wys die versoek net op die tonnel. Niks is stukkend nie, en die aanstuurinstelling wat sorgvuldig afgeskakel is, het niks daarmee te doen nie. Dit is ’n vergelyking tussen twee paaie wat in ’n diagram dieselfde lyk en in die kernel heeltemal verskil.

Een pad stuur pakkette namens iemand anders aan; die ander lewer hulle by die gasheer self af.

’n Pakket wat aan die gasheer gerig is, bly in die gasheer

Die afgeleë kliënt stuur ’n IP-pakket na ’n adres wat die gasheer besit. Roetering vra een vraag oor daardie pakket: is hierdie bestemming plaaslik? Elke adres wat die gasheer hou, verskyn in die plaaslike roetertabel, en daardie tabel word voor die hoof een geraadpleeg, so die pakket gaan na die gasheer se eie stokel in plaas van uit ’n ander koppelvlak. Die antwoord word plaaslik gegenereer, en dit reis terug deur die tonnel omdat dit is waar die navraag vandaan gekom het.

Dit is die hele meganisme. Geen aanstuur vind plaas nie, geen koppelvlaktoestandverandering is betrokke nie, en die adres in kwessie hoef nie van enige ander plek bereikbaar te wees nie.

Waarom ip_forward nie van toepassing is nie

Aanstuur beheer pakkette wat deur ’n ander koppelvlak as dié waarop hulle aangekom het, moet verlaat. ’n Ping na die gasheer self neem nooit daardie pad nie: die pakket word plaaslik verbruik en die antwoord word plaaslik gegenereer. Om net.ipv4.ip_forward=0 te stel verander dus niks hier nie, en ’n reël in die aanstuurketting sien nooit die verkeer nie. Die korrekte beheer sit op die invoerpad, beperk deur inkomende koppelvlak of bron.

Daarom skep die afskakel van aanstuur en die aanvaarding dat die gasheer geïsoleer is, ’n valse gevoel van veiligheid.

Lees die plaaslike tabel wat besluit het

ip rule show rapporteer gewoonlik ’n reël teen prioriteit nul wat alle opsoeke eerste na die plaaslike tabel stuur, en ip route show table local lys die gasheer se eie adresse met plaaslike omvang. Daardie tabel sluit adresse in op koppelvlakke wat administratief af is maar steeds opgestel is. IPv4-adresse wat staties toegewys is, oorleef gewoonlik ’n skakelverlies, en dit is hoe ’n ping na ’n afgeskakelde brug steeds kan slaag en die operateur kan verras.

IPv6 verskil presies op hierdie punt. Sy adresse word gewoonlik onttrek wanneer die skakel val, tensy keep_addr_on_down gestel is. Vergelyk die families in plaas daarvan om te aanvaar dat een reël albei dek.

Wat ’n portaal werklik bereik

’n Antwoord vanaf die roeteerder se eie adres op ’n segment sê niks oor die masjiene agter daardie segment nie. Die portaal kan nie ’n gasheer agter die ander koppelvlak deur hierdie pad bereik nie; dit bereik net adresse wat die roeteerder self besit. Om ’n diens op ’n aparte LAN-gasheer te toets, eerder as om die roeteerder se adres te ping, is wat bepaal of aanstuur hoegenaamd toegelaat word.

Om ’n portaal tot dienste wat op die tonneladres gebind is, te beperk, is ’n vraag oor invoerbeleid. Laat die gewenste diens op die tonnelkoppelvlak toe en beperk die bronne wat dit mag gebruik, want die pakket kom werklik daar aan.

Kontroleer ook vir adresse wat jy bedoel het om uit te diens. Om ’n adres van ’n koppelvlak te verwyder, is betroubaarder as om firewall-reëls bo-op ’n verouderde een te stapel.