La VPN de la enkursigilo funkcias, sed la LAN-klientoj ne havas interreton

La stato diras, ke la tunelo estas supren, retumilo sur la enkursigilo mem ŝargas paĝojn, kaj ĉiu aparato malantaŭ ĝi ankoraŭ finiĝas per tempolimo. Tiu kombinaĵo mallarĝigas la problemon al tavolo, kiun plej multaj gvidiloj pri VPN neniam mencias: la enkursigilo ne estas la sola gastigo, kies pakaĵoj devas travivi la tunelon. Loke generita trafiko kaj plusendita trafiko iras malsamajn vojojn tra la sama skatolo. Testu de kliento kaj la diferenco ĉesas esti teoria.

Legu la fiaskon de LAN-gastigo

Komencu ĉe la aparato, kiu fiaskas, ĉar diagnozo sur la enkursigilo respondas alian demandon. Konfirmu, ke la implicita enirejo de la kliento estas ĉi tiu enkursigilo, notu ĝian fontan adreson kaj subreton, kaj poste rigardu, kio eliras la tunelan interfacon de la enkursigilo.

Se la adreso de la kliento estas tradukata, la malproksima flanko vidas la tunelan adreson, kaj de tie ĉio aspektas sana dum la kliento ankoraŭ fiaskas. Se ĝi ne estas tradukata, la malproksima flanko devas koni vojon reen al la klienta subreto, kaj multaj enirejoj ne havas tian vojon implicite. En ambaŭ kazoj la propra sukceso de la enkursigilo estas nerelevanta, ĉar ĝiaj pakaĵoj estis generitaj loke kaj neniam trapasis la plusendan vojon.

Loka trafiko kaj plusendita trafiko estas malsamaj

Linux kaj plej multaj enkursigilaj firmprogramoj traktas pakaĵojn originitajn de la skatolo mem malsame ol pakaĵojn pasantajn tra ĝi. La ĉeno output vidas la unuan specon, la ĉeno forward vidas la duan, kaj politiko adaptita al la propra trafiko de la enkursigilo povas lasi la plusendadon netuŝita.

sysctl net.ipv4.ip_forward
ip -4 address show br-lan
ip route get 203.0.113.9
nft list ruleset | grep -A 6 'chain forward'

Kontrolu, ĉu plusendado entute estas ŝaltita, poste legu la ĉenon forward anstataŭ la ĉenon output. Regulo, kiu permesas la ĉifritan eksteran konekton, ne estas regulo, kiu permesas plusendi malĉifritajn pakaĵojn, kaj konfuzi la du produktas ĝuste ĉi tiun simptomon. Tio, ke la tunelo estas supren, pruvas nur la unuan.

La revena vojo ankaŭ devas ekzisti

Fonta traduko decidas, ĉu revena vojo necesas. Kun maskado sur la tunela interfaco, respondoj revenas al la tunela adreso kaj la enkursigilo malŝarĝas la tradukon. Sen ĝi, la malproksima enirejo bezonas eksplicitan vojon al la klienta subreto, kaj ĝia propra politiko devas permesi tiun direkton.

Notu, kiun el la du dezajnoj la deplojo uzas antaŭ ol ŝanĝi ion ajn, ĉar la riparoj montras en malajn direktojn. Aldoni tradukon kaŝas mankantan revenan vojon kaj rompas aplikaĵojn, kiuj bezonas la originan fontan adreson. Aldoni revenan vojon sen traduko silentas fiaskas, kiam la malproksima fajroŝirmilo forĵetas la nekonatan fonton. Elektu unu, dokumentu ĝin kaj akordigu la alian flankon.

Klienta DNS apartenas al la sama revizio. La solvilo de la enkursigilo povas respondi dum kliento direktita al alia servilo tute ricevas nenion.

Kontrolu unu permesitan kaj unu rifuzitan fluon

Post la korekto, testu novan konekton de kliento anstataŭ ekzistantan seancon de la enkursigilo. Poste konfirmu, ke segmento, kiu ne devus uzi la tunelon, ankoraŭ ne uzas ĝin.

curl -sS --max-time 8 https://api.ipify.org
ip route get 203.0.113.9
dig +short intranet.example.net

Kontrolu la observitan fontan adreson ĉe la malproksima fino, ĉar ĝi diras al vi, kiun dezajnon efektive funkcias. Kontrolu ankaŭ nomserĉon same kiel adreson, ĉar la konduto de la solvilo estas aparta vojo tra la sama skatolo.

Tenu regulojn limigitaj al la klientaj retoj, kiuj bezonas la tunelon, kaj rezistu la tenton malŝalti la plusendan filtron por ke unu testo sukcesu. Tiu ŝanĝo riparas la teston kaj forigas la limon, kiun la tunelo devintus provizi. Skribu la fontan adreson, la tradukan decidon kaj la revenan vojon en unu noton, kun dato.