Enkursigita VPN-kliento atingas la servilon sed ne la LAN-gastigantojn

La tunelo supreniĝas, la kliento pingsendas al la VPN-servilo, kaj kunhavigita dosierujo sur maŝino unu salton pli fore neniam respondas. Nenio en la klienta agordo tion klarigas, ĉar la peto ja forlasis la klienton kaj ja alvenis. Malsukcesis la revena vojo, kaj la malsukcesinta aparato estas kutime la LAN-enirejo, ne la VPN-gastiganto. Spurado de la responda pakaĵo klarigas la tutan klason de simptomoj.

Sekvu la respondon, ne la peton

La VPN-servilo malĉifras la klientan pakaĵon kaj plusendas ĝin al la LAN kun la klienta adreso ankoraŭ en la fonta kampo. La celloka gastiganto respondas al tiu adreso, kaj nun ĝia propra enkursig-tabelo decidas ĉion. Ĝia implicita enirejo scias nenion pri la tunela baseno, do la respondo foriras al la interreta provizanto kaj estas forĵetata ie survoje.

Ĉe la kliento la simptomo estas silenta tempolimo: neniu rifuzo, neniu restarigo, simple nenio. Foliumado de kunhavigita dosierujo haltas, ping raportas neniun respondon, kaj la servilaj protokoloj aspektas sanaj ĉar la servilo faris sian taskon.

Metu la returnan itineron tien, kien rigardas la gastigantoj

Ĉiu LAN-gastiganto konsultas sian implicitajn enirejon, do la enirejo estas la sola aparato, kiu devas scii, kie troviĝas la tunela baseno. Aldonu tie senŝanĝan itineron kaj ĉiu gastiganto heredas la ĝustan vojon sen esti tuŝita.

Se la enirejo disdonas sian propran adreson kiel DHCP-opcion, disdonu la itineron tiel, ke novaj maŝinoj aŭtomate prenu ĝin. Alie la itinero loĝas en unu agorda dosiero kaj malaperas ĉe la sekva rekonstruo.

# on the LAN gateway; tunnel pool 172.20.5.0/24, VPN server 10.60.4.10
ip route add 172.20.5.0/24 via 10.60.4.10
ip route get 172.20.5.14

Kial Fonto-NAT ŝajnas ripari la aferon

Maskado de la klienta baseno malantaŭ la adreso de la VPN-servilo forigas la problemon forigante la klientan adreson el la pakaĵo. La respondoj tiam revenas al la servilo, kiu jam scias kiel atingi la tunelon, kaj ĉio funkcias. La kosto estas, ke internaj gastigantoj ne plu povas vidi, kiu estas la kliento, kaj ĉiu konekto aspektas kvazaŭ ĝi originus el unu maŝino.

Tiu interŝanĝo foje estas ĝusta, ekzemple kiam vendista aparato ne povas ricevi senŝanĝan itineron. Faru la regulon ne pli larĝa ol la nuna baseno, ĉar regulo skribita por /24 ĉesas kongrui la tagon, kiam la baseno renumeriĝas al /16, kaj la unua signo estas aro da novaj klientoj, kiuj konektiĝas kaj atingas nenion.

iptables -t nat -A POSTROUTING -s 172.20.5.0/24 -o ens18 -j MASQUERADE
iptables -t nat -L POSTROUTING -n -v

La nuba vojo bezonas tri agordojn

En VPC la sama manko revenas en alia formo, ĉar la subreto tute ne havas itineron por la klienta gamo. La enkursig-tabelo bezonas eron por la tunela baseno celantan la retinterfacon de la instanco, kaj la interfaco bezonas malŝaltitan kontrolon de fonto kaj celo, por ke la platformo akceptu pakaĵojn, kies fonto ne estas ĝia propra adreso. Sekurecgrupoj kaj retaj ACL-oj ankaŭ devas enlasi la basenon en ambaŭ direktojn.

Ĉiu preterlaso kreas apartan partan fiaskon. Preterlasu la eron de la enkursig-tabelo kaj privataj instancoj respondas en subreton, kiu ne povas porti la respondon reen al la baseno. Kun la kontrolo ankoraŭ ŝaltita, la platformo forĵetas la respondon post kiam la instanco jam sendis ĝin. Sen la regulo de la sekurecgrupo la peto mem neniam alvenas, kaj la kliento vidas la tempolimon unu tavolon pli frue.

Rulu la kontrolojn laŭ ĉi tiu ordo

Konfirmu plusendadon kaj la filtran politikon antaŭ ol kulpi la enkursigadon, ĉar gastiganto, kiu ne plusendos, fiaskas same silente. Poste legu la efikan agordon de la inversa vojo sur la interfaco, kiu portas la tunelon, ĉar strikta filtro povas forĵeti respondojn alvenantajn el neatendita direkto.

Finu per kaptaĵo farita sur la LAN-gastiganto dum la kliento pingsendas al ĝi. Peto, kiu alvenas sen kongrua respondo, pruvas la revenan vojon, kaj peto, kiu neniam alvenas, movas la kulpon reen al la servilo aŭ la tunelo.

sysctl net.ipv4.ip_forward net.ipv4.conf.all.rp_filter
tcpdump -ni any host 172.20.5.14 and icmp

La kontrolo de fonto kaj celo estas dokumentita en la gvidilo pri elastaj retinterfacoj. Agordu ĝin sur la interfaco, kiu efektive portas la tunelan trafikon, ne sur nerilata adaptilo ligita al la sama instanco.