Respondo de reteja VPN ne trapasas la tunelon
Respondo, kiu preteriras la tunelon, estas enkursiga decido ĉe la malproksima flanko. Kontrolu la gastigan tabelon, la selektilojn kaj rp_filter, poste elektu itineron aŭ NAT.
Mi pasigis matenon ĉe tunelo, kiu ekfunkciis pure kaj movis trafikon precize en unu direkto: la filio povis atingi la dosierservilon en la ĉefsidejo, kaj ĉiu konekto malfermita de la ĉefsidejo al la filio mortis ĉe la unua SYN. La SA-oj estis aktivaj, la tunelaj nombriloj kreskis, kaj la manpremo neniam estis la problemo. La respondo estis enkursigata ie, kion la tunelo ne kovras, kaj tiu elekto apartenas al la malproksima flanko. Reteja VPN portas nur la paketojn, kiujn gastiganto transdonas al la enirejo, kaj ĉiu gastiganto faras tiun elekton aparte, en ĉiu direkto, el sia propra enkursiga tabelo.
Ambaŭ direktoj estas enkursigataj aparte
IP konservas nenian memoron pri la direkto de konversacio. Ĉiu gastiganto, kiu sendas paketon, faras sian propran serĉon de la plej longa prefikso, elektas unu sekvan salteton kaj forgesas la decidon. La peto kaj la respondo estas du ne rilataj paketoj, kiuj hazarde apartenas al la sama konekto, kaj la tunelo estas unu salteto, kiun ĉiu el ili povas uzi aŭ ne. Nenio en la IKE-interŝanĝo instruas al la malproksima servilo kiel atingi vian subreton; la intertraktado nur konsentas, kiuj prefiksoj rajtas esti ĉifritaj.
Tiu interkonsento estas la dua pordego. En strongSwan la trafikaj selektiloj estas leftsubnet kaj rightsubnet, kaj paketo, kies fonto aŭ celo falas ekster la intertraktita paro, ne estas ĉifrata, kion ajn diras la enkursiga tabelo. Prefikso, kiu estas enkursigata en la tunelon sed mankas en la selektiloj, estas silenta unudirekta malsukceso: la itinero aspektas ĝusta, la paketo tamen eliras malkaŝe aŭ estas forĵetata, kaj nur la protokolo de charon plendas.
La malproksima gastiganto scias nenion pri via tunelo
Ene de la malproksima loka reto la respondo estas ordinara paketo adresita al via kliento. La cela gastiganto vidas nenian IPsec-kapon kaj havas nenian kialon preferi la VPN-enirejon; ĝi serĉas vian prefikson, trovas nenion pli specifan ol sian defaŭltan itineron kaj sekvas ĝin. Se la defaŭlto montras al kern-fajroŝirmilo, la fajroŝirmilo aŭ havas itineron reen en la tunelon aŭ ne. Kiam ĝi ne havas, vi ricevas silentan forĵeton, ICMP-malatingeblecon aŭ respondon, kiu eliras tra la interreta interfaco kaj mortas.
Dua interfaco sufiĉas por rompi tion eĉ kiam itinero ekzistas. NAS kun administra ligilo en alia VLAN, servilo kun rezerva uplink, politika regulo, kiu sendas unu fontintervalon en duan tabelon: iu ajn el tiuj povas kapti la respondon. En Linux, ip rule show kaj ip route show table all malkaŝas regulojn kaj tabelojn, kiujn la defaŭlta listo kaŝas.
Legu la decidon sur la maŝino, kiu sendas la respondon
Demandu la kernon antaŭ ol ŝanĝi ion, kaj donu al ĝi la fontadreson, ĉar fontdependaj reguloj ŝanĝas la respondon.
ip route get 10.10.5.10 from 10.20.30.15
ip rule show
ip route show table all
ss -tn state established "( sport = :445 )"La eligo nomas la elirantan interfacon kaj la sekvan salteton. Se la interfaco ne estas la unu rigardanta al la VPN-enirejo, vi trovis la difekton, kaj la restanta laboro estas elekti, kien la itinero apartenas. Ping de la enirejo pruvas malmulte ĉi tie: ĝi respondas per adreso, kiun la malproksima gastiganto povas loki, ne per la adreso de via tekkomputilo.
En Windows la ekvivalentoj estas Find-NetRoute -RemoteIPAddress 10.10.5.10 por la decido kaj Get-NetRoute por la tabelo. Itinero aldonita per New-NetRoute, kiu portas pli altan metrikon ol la defaŭlta, malgajnas silente, do legu la metrikan kolumnon, ne la eron. Poste konfirmu per paketoj: tcpdump -ni any "host 10.10.5.10 and tcp port 445" sur la malproksima LAN-interfaco montras la peton, kaj la sama filtrilo ĉe la tunela flanko montras, ĉu respondo revenis. Videbla peto sen respondo signifas, ke la respondo estis enkursigata aliloken aŭ forĵetita; respondo sur la malĝusta interfaco donas al vi la kulpulon antaŭ ol vi tuŝos itineron.
Kiam la enirejo de la servilo ne estas la VPN-finpunkto
Multaj retejoj metas fajroŝirmilon inter la servilojn kaj la koncentrigilon. Tiu fajroŝirmilo plusendadas la respondon, do ĝi bezonas itineron por la prefikso de via kliento direktitan al la VPN-enirejo, kaj plusendan politikon en ambaŭ direktoj. Stato-konservaj aparatoj plimalbonigas ĝin: la peto trapasis la fajroŝirmilon de LAN-gastiganto, kiun ĝi permesis, la respondo nun alvenas el alia direkto, kaj la konektospura ero ne plu kongruas, do la paketo estas forĵetata kiel malvalida anstataŭ malpermesita. Tial la politika protokolo aspektas malplena dum la trafiko malaperas.
La enirejo havas sian propran duan filtrilon. La inversa voja filtrado de Linux forĵetas paketojn, kies fonto ne estas atingebla tra la interfaco, sur kiu ili alvenis, kaj tio estas ĝuste la formo de laŭleĝa malsimetria revena vojo. la plusenda gvidilo de strongSwan postulas net.ipv4.ip_forward kaj malfiksitan net.ipv4.conf.all.rp_filter ĝuste pro tio. Strikta valoro de 1 sur iu ajn enirejo silente rompas ĝustan itineron, kaj nstat -az montras la forĵetojn, se vi scias, kien rigardi.
| Symptom | Where the reply is most likely lost |
|---|---|
| Gateway ping works, LAN host silent | Source address the far host cannot place in its table |
| SYN arrives, no SYN-ACK, tunnel counters flat | No route to the client prefix on the far host or its gateway |
| Reply counted on the internet-facing interface | Default route or policy rule on the far host |
| Firewall reports invalid state | Asymmetric path through a stateful device |
| Worked until a link failed over | New path is asymmetric, or rp_filter now rejects it |
Enkursigu aŭ traduku, poste kontrolu en ambaŭ direktoj
La du riparoj ne estas ekvivalentaj. Aldoni itineron konservas la adreson de la kliento sendifekta, do fontbazitaj reguloj, reviziaj protokoloj kaj aplikoj, kiuj registras la alvokanton, daŭre funkcias; la prezo estas, ke ĉiu salteto faranta la decidon bezonas la itineron, do pli da lokoj por erari. Maskado sur la malproksima enirejo kuntiras la revenan vojon al unu salteto, ĉar la respondo nun estas adresita al la enirejo mem, kaj kaŝas, kiu kliento faris kion.
iptables -t nat -A POSTROUTING -o eth1 -s 10.20.30.0/24 -j MASQUERADEElektu ĝin konscie: post kiam klientoj aperas kiel la adreso de la enirejo, fontbazitaj ACL-oj ĉesas distingi ilin, kaj conntrack devas teni la mapadon, por ke la respondo estu reskribita reen en la tunelon. Se la selektiloj ankoraŭ ekskludas la prefikson de la kliento, NAT tute ne ŝanĝas ion, ĉar la peto neniam eniris la tunelon.
Antaŭ ol nomi ĝin riparita, konfirmu kvar aferojn laŭ ordo: la itineron sur la gastiganto, kiu sendas la respondon, la itineron sur ĉiu salteto, kiu plusendadas ĝin, la selektilojn kovrantajn ambaŭ prefiksojn, kaj registraĵon montrantan la respondon eniri la tunelon kun la fonto, kiun vi atendas. Poste ripetu la teston de la alia retejo. Unu pasanta direkto estas duonmalferma dezajno, kaj la dua direkto kutime malsukcesas pro alia kialo ol la ĵus riparita.