Kial servilo malantaŭ VPN-kliento respondas tra la tunelo

Envenantaj konektoj al gastiganto kiu ankaŭ rulas VPN-klienton malsukcesas tre specife: la manpremo alvenas, la demono respondas, kaj la kliento ricevas nenion rete. Nenio blokas la pordon. La respondo eliris tra la tunelo, ĉar la tunelo posedas la defaŭltan vojon kaj la kerno enkursigas respondojn laŭ celo, ne laŭ memoro pri tio, de kie la peto venis. La demono estas en ordo kaj la pordo estas malfermita.

La respondo estas enkursigata, ne memorata

VPN-kliento kiu instalas defaŭltan vojon aldonas rikordon kiu superas la LAN-pordegon, aŭ laŭ metriko aŭ dividante la spacon en du pli precizajn duonojn. Elirantaj pakaĵoj nun elektas la tunelan interfacon. La kerno neniam demandas de kie la pakaĵo, al kiu ĝi respondas, origine alvenis. Tiu ununura preterlaso klarigas ĉiun sekvan simptomon.

La antaŭa direkto estas enkursigata laŭ celo, kaj same la malantaŭa. La respondo estas adresita al publika kliento, kiun la tunelo volonte portos. La malproksima fino ricevas pakaĵon kies fonton ĝi ne posedas, forĵetas ĝin, kaj la origina kliento atendas ĝis la tempo finiĝas.

Strikta inversvoja filtrado povas forĵeti la envenantan pakaĵon antaŭ ol la demono eĉ legas ĝin. Kontrolu tiun nombrilon unue, ĉar filtra forĵeto kaj enkursiga eraro aspektas idente de ekstere.

ip route show default
sysctl net.ipv4.conf.all.rp_filter net.ipv4.conf.eth0.rp_filter
nft list ruleset | grep -A3 'hook forward'

La unua komando montras kiu defaŭlta vojo nun venkas. La dua raportas ĉu strikta filtrado validas tutmonde aŭ laŭ interfaco, kaj la tria montras ajnan regulon de la plusenda ĉeno kiu povus esti implikita.

Tri manieroj konservi la revenan vojon

Ekskludi la celon de la servo el la tunelo estas la plej mallarĝa opcio. Gastiganta vojo direktita al la LAN-pordego, plus demono ligita al la fizika adreso anstataŭ al ĉiu adreso, tenas tiun unu fluon ekster la tunelo. La ŝanĝo estas loka kaj facile malfarebla.

Politika enkursigo estas la ĝenerala respondo. Regulo ŝlosita al la fonta adreso aŭ al fajroŝirmila marko elektas tabelon kies defaŭlto montras al la WAN-pordego, dum la propraj konektoj de la gastiganto daŭre uzas la tunelon. Tenu la prioritaton eksplicita por ke la regulo ne estu poste ombrumita.

ip rule add from 203.0.113.25/32 table 100 priority 100
ip route add default via 192.0.2.1 dev eth0 table 100
ip route get 198.51.100.7 from 203.0.113.25

La unuaj du komandoj konstruas la alternativan vojon por respondoj el la publika adreso. La tria demandas la kernon kiun vojon ĝuste tiu fonto kaj celo prenus, kaj tiel vi konfirmas ke la regulo havas ajnan efikon.

Fonta tradukado estas la tria opcio kaj la sola kiu postvivas enkursigilon kiu jam faras NAT antaŭ la servo. La respondo devas reveni al tiu enkursigilo, kaj maskado al la WAN-interfaco tion atingas kaŝante la klienton el la protokoloj de la servo. Anstataŭigi la defaŭltan vojon mane post konekto estas diagnozo, ĉar la kliento reskribas la tabelon ĉe la sekva rekonekto.

Kiam la skatolo ankaŭ enkursigas por LAN

La sama malsukceso aperas unu salton pli malproksime kiam la gastiganto enkursigas por aparatoj malantaŭ ĝi. Envenanta konekto estas plusendita al interna aparato kies sola reena vojo estas la tunelo, kaj la respondo atingas la eksteran klienton de la adreso de la provizanto. La interna aparato funkcias ĝuste la tutan tempon.

Konekta spurado tiam vidas respondon por fluo kiun ĝi neniam registris kaj forĵetas ĝin. Celdestina tradukado liveras la envenantan konekton al la aparato, kaj fonta tradukado igas la respondon ŝajni deveni de la enkursigilo mem.

Politika vojo kiu tenas la plusenditan pordon sur la WAN dum la propra trafiko de la enkursigilo uzas la tunelon estas la pli pura ekvivalento. Sen fonta tradukado la respondo estas adresita al la ekstera kliento, kaj la interna aparato tute ne havas vojon al tiu adreso.

Tri provoj kiuj apartigas la kaŭzojn

Faru tri provojn: konekton en la skatolon el la interreto, konekton el ĝi al publika gastiganto, kaj nomserĉadon. Kiam la unuaj du malkongruas, la reena vojo kulpas. Kiam nomoj malsukcesas ambaŭdirekte, la solvilo estas alia difekto kiu nur dividas la tunelon.

Unue riparu la enkursigan demandon, poste rigardu nomojn. Miksi la du estas kiel funkcianta servilo estas kulpigita pro rompita solvilo.

Notu kiun interfacon la escepto nomas kaj tenu la agordon sub versia kontrolo. Regulo skribita kontraŭ interfaco kiu renomiĝas post ĝisdatigo pasas hodiaŭ kaj malsukcesas post la sekva restartigo.