Tunelo staras, interreto mankas: kie haltas la plusendado

La kliento konektiĝas, la tunelo portas pingojn al la enirejo, kaj nenio preter ĝi respondas. Tiu stato estas normala por enirejo, kiu ĉiam celis nur doni aliron al protektitaj retoj, kaj ĝi estas paneo por enirejo anoncita kiel eliro de plena tunelo. Antaŭ ol ŝanĝi regulojn, konfirmu, kiu servo estis promesita. Poste sekvu unu publikan peton tra la kvar lokoj, kie ĝi povas halti. Unu peto kaj unu paketa registraĵo solvas pli ol paĝo da konjektoj.

Konfirmu, ĉu eliro al interreto iam estis la dezajno

Profilo de dividita tunelo direktas al la VPN nur la protektitajn subretojn, do publika retumado daŭras laŭ la loka ligilo kaj neniam tuŝas la enirejon. Profilo de plena tunelo instalas defaŭltan itineron en la tunelon, kio igas la enirejon respondeca pri la tuta vojo. Ambaŭ estas legitimaj dezajnoj, kaj konfuzi ilin kreas panean raporton tie, kie ĝi ne ekzistas. Legu la itinerojn anoncitajn de la kliento antaŭ ol testi ion alian, ĉar la itinera tabelo respondas la demandon, kiun la bileto kutime starigas malĝuste.

Tio, kion instalas la kliento, ne ĉiam estas tio, kion celas la profilo. Puŝitan itineron povas superi loka itinero kun pli malalta mezuro, kaj kliento, kiu konservas sian LAN-itineron dum ĝi aldonas defaŭltan itineron, kondutas kiel dividita tunelo por tiu subreto.

Sekvu unu publikan peton

Elektu unu celon kaj sekvu ĝin de la kliento eksteren. Sur la kliento kontrolu, ĉu la paketo vere elektas la tunelon kaj kiun lokan adreson ĝi uzas kiel fonton. Poste kontrolu la enirejon: ĉu la paketo alvenas kaj ĉu ĝi forlasas la publikan interfacon. Ĉiu el tiuj respondoj forigas tutan kategorion de kaŭzoj.

ip route get 1.1.1.1
ip -4 addr show tun0
conntrack -L | grep 1.1.1.1
tcpdump -ni any host 1.1.1.1

Se la enirejo neniam vidas la paketon, la itinero de la kliento aŭ la elekto de la tunelo estas malĝusta. Se ĝi alvenas kaj ne foriras, la problemo estas sur la enirejo, kaj validas la tri ceteraj kontroloj.

Kontrolu plusendadon, itineron kaj tradukon

La plusendada gvidilo liverata kun strongSwan validas por enirejo de ajna tunela tipo: la kerno devas rajtis movi paketojn inter interfacoj, kaj uzebla itinero devas montri al interreto. La fajroŝirma politiko poste devas permesi la trafikon, kaj la fonta adreso devas esti tia, al kiu la publika flanko povas respondi. Privata klienta adreso plusendita senŝanĝe al interreto neniam ricevas respondon.

sysctl net.ipv4.ip_forward
ip route get 1.1.1.1
nft list ruleset | grep -A6 forward
sysctl net.ipv4.conf.all.rp_filter

Fonta traduko estas la kutima mankanta peco. Kun ĝi la enirejo reskribas la klientan fonton al sia publika adreso kaj spuras la fluon; sen ĝi la respondo havas nenie por iri. Nubaj platformoj aldonas duan limon, kie la itinera tabelo aŭ sekureca grupo de la instanco povas forĵeti trafikon, kiun la gastiga fajroŝirmilo permesas. Tiun limon facile pretervidi, ĉar la gastiga sistemo ŝajnas ĝuste agordita interne.

Filtrado de la inversa vojo en nesimetria agordo ankaŭ povas forĵeti validajn paketojn. Legu la nombrilon de tiu regulo anstataŭ supozi, ke ĝi estas en ordo, ĉar severa agordo sur la publika interfaco malakceptas trafikon, kiu alvenas per alia vojo ol tiu, kiun antaŭdiras la itinera tabelo.

Responda vojo kaj solvilo estas du malsamaj respondoj

Observu ankaŭ la respondon, ne nur la peton. Se la peto eliras tradukita kaj la respondo revenas al la tradukita fluo, plusendado funkcias eĉ kiam la aplikaĵo ankoraŭ malsukcesas, kaj la sekva esploro apartenas al la aplikaĵo aŭ al DNS.

Retejo, kiu resendas HTTP-eraron, estas pruvo, ke plusendado al interreto funkcias. Nomo, kiu ne solviĝas dum aliro per adreso funkcias, estas problemo de solvilo, ne de NAT.

Post preciza korekto retestu la klienton kaj ĉiun intence limigitan privatan rimedon. Doni aliron al interreto ne rajtas silente vastigi aliron al ĉiu reto ligita al la enirejo.