VPN-samulo pingas aliajn interfacojn ĉar ili estas lokaj

Kliento de WireGuard konektiĝas kaj pingas adreson sur tute alia interfaco, kaj la respondo alvenas. Kaptaĵoj montras la peton nur sur la tunelo. Nenio estas rompita, kaj la antaŭenpaŝa agordo, kiun oni zorge malŝaltis, havas nenion komunan kun tio. Ĉi tio estas komparo inter du vojoj, kiuj aspektas similaj en diagramo kaj estas tute malsamaj en la kerno.

Unu vojo antaŭenpaŝas pakaĵojn por iu alia; la alia liveras ilin al la gastiganto mem.

Pakaĵo adresita al la gastiganto restas en la gastiganto

La fora kliento sendas IP-pakaĵon al adreso, kiun la gastiganto posedas. Enkursigado demandas unu demandon pri tiu pakaĵo: ĉu ĉi tiu celo estas loka? Ĉiu adreso, kiun la gastiganto tenas, aperas en la loka enkursiga tabelo, kaj tiu tabelo estas konsultata antaŭ la ĉefa, do la pakaĵo iras al la propra stako de la gastiganto anstataŭ eliri tra alia interfaco. La respondo estas generata loke, kaj ĝi vojaĝas reen tra la tunelo ĉar de tie venis la demando.

Tio estas la tuta mekanismo. Neniu antaŭenpaŝado okazas, neniu ŝanĝo de interfaca stato partoprenas, kaj la koncerna adreso ne bezonas esti atingebla de ie ajn alie.

Kial ip_forward ne aplikiĝas

Antaŭenpaŝado regas pakaĵojn, kiuj devas eliri tra alia interfaco ol tiu, sur kiu ili alvenis. Ping al la gastiganto mem neniam prenas tiun vojon: la pakaĵo estas konsumata loke kaj la respondo estas generata loke. Do agordi net.ipv4.ip_forward=0 ŝanĝas nenion ĉi tie, kaj regulo en la antaŭenpaŝa ĉeno neniam vidas la trafikon. La ĝusta kontrolo sidas sur la enira vojo, limigita de la envenanta interfaco aŭ fonto.

Tial malŝalti antaŭenpaŝadon kaj supozi, ke la gastiganto estas izolita, produktas falsan senton de sekureco.

Legu la lokan tabelon, kiu decidis

ip rule show kutime raportas regulon kun prioritato nulo, kiu sendas ĉiujn serĉojn unue al la loka tabelo, kaj ip route show table local listigas la proprajn adresojn de la gastiganto kun loka amplekso. Tiu tabelo inkluzivas adresojn sur interfacoj, kiuj estas administre malŝaltitaj sed ankoraŭ agorditaj. Adresoj IPv4 asignitaj statike kutime postvivas ligan falon, kaj tial ping al malŝaltita ponto povas ankoraŭ sukcesi kaj surprizi la operatoron.

IPv6 malkonsentas ĝuste pri ĉi tiu punkto. Ĝiaj adresoj kutime estas retiritaj, kiam la ligo falas, krom se keep_addr_on_down estas agordita. Komparu la familiojn anstataŭ supozi, ke unu regulo kovras ambaŭ.

Kion samulo efektive atingas

Respondo de la propra adreso de la enkursigilo sur segmento diras nenion pri la maŝinoj malantaŭ tiu segmento. La samulo ne povas atingi gastiganton malantaŭ la alia interfaco per ĉi tiu vojo; ĝi atingas nur adresojn, kiujn la enkursigilo mem posedas. Testi servon sur aparta LAN-gastiganto, anstataŭ pingi la adreson de la enkursigilo, estas tio, kio establas, ĉu antaŭenpaŝado entute estas permesita.

Limigi samulon al servoj ligitaj al la tunela adreso estas demando de enira politiko. Permesu la deziratan servon sur la tunela interfaco kaj limigu la fontojn, kiuj rajtas uzi ĝin, ĉar la pakaĵo vere alvenas tie.

Kontrolu ankaŭ adresojn, kiujn vi intencis eksigi. Forigi adreson de interfaco estas pli fidinda ol staki fajroŝirmilajn regulojn sur malnovan.