Hindi dumadaan sa tunnel ang sagot ng site-to-site VPN
Ang sagot na lumalaktaw sa tunnel ay desisyon sa routing sa kabilang dulo. Suriin ang host table, ang mga selector at rp_filter, pagkatapos pumili ng ruta o NAT.
Ginugol ko ang isang umaga sa isang tunnel na malinis na umangat at naghatid ng trapiko sa eksaktong isang direksyon: naabot ng sangay ang file server sa punong tanggapan, at bawat koneksyong binuksan mula sa punong tanggapan papasok sa sangay ay namatay sa unang SYN. Nakataas ang mga SA, tumataas ang mga counter ng tunnel, at ang handshake ay hindi kailanman naging problema. Ang sagot ay niruruta sa lugar na hindi sakop ng tunnel, at ang pagpiling iyon ay pag-aari ng kabilang dulo. Ang site-to-site VPN ay nagdadala lamang ng mga packet na iniaabot ng host sa gateway, at bawat host ay gumagawa ng pagpiling iyon nang hiwalay, sa bawat direksyon, mula sa sarili nitong routing table.
Hiwalay na niruruta ang dalawang direksyon
Walang natatandaan ang IP tungkol sa direksyon ng usapan. Bawat host na nagpapadala ng packet ay gumagawa ng sarili nitong paghahanap ng pinakamahabang prefix, pumipili ng isang susunod na hop at nakakalimutan ang desisyon. Ang hiling at ang sagot ay dalawang packet na walang kaugnayan na nagkataong kabilang sa iisang koneksyon, at ang tunnel ay isang hop na maaaring gamitin o hindi ng alinman sa dalawa. Walang anuman sa pagpapalitan ng IKE ang nagtuturo sa malayong server kung paano maabot ang iyong subnet; ang negosasyon ay sumasang-ayon lamang kung aling mga prefix ang maaaring i-encrypt.
Ang kasunduang iyon ang ikalawang pintuan. Sa strongSwan ang mga traffic selector ay leftsubnet at rightsubnet, at ang packet na ang pinagmulan o destinasyon ay nasa labas ng napagkasunduang pares ay hindi naka-encrypt, anuman ang sabihin ng routing table. Ang prefix na niruruta papasok sa tunnel pero wala sa mga selector ay isang tahimik na isang-direksyong pagpalya: mukhang tama ang ruta, lumalabas pa rin nang lantad ang packet o itinatapon ito, at ang log lamang ng charon ang nagrereklamo.
Walang alam ang malayong host tungkol sa iyong tunnel
Sa loob ng malayong LAN ang sagot ay ordinaryong packet na naka-address sa iyong client. Walang nakikitang IPsec header ang destinasyong host at wala itong dahilan para unahin ang VPN gateway; hinahanap nito ang iyong prefix, walang natagpuang mas partikular kaysa sa default route nito at sinusundan iyon. Kung ang default ay tumuturo sa isang pangunahing firewall, may ruta pabalik sa tunnel ang firewall o wala. Kapag wala, makakakuha ka ng tahimik na pagtatapon, ICMP unreachable, o sagot na lumalabas sa interface na nakaharap sa internet at namamatay.
Sapat na ang ikalawang interface para basagin ito kahit may ruta. Isang NAS na may management link sa ibang VLAN, isang server na may backup uplink, isang patakaran sa policy na nagpapadala ng isang saklaw ng pinagmulan sa ikalawang table: alinman sa mga ito ay makakahuli ng sagot. Sa Linux, ipinapakita ng ip rule show at ip route show table all ang mga patakaran at table na itinatago ng default na listahan.
Basahin ang desisyon sa makinaryang nagpapadala ng sagot
Tanungin ang kernel bago magbago ng anuman, at ibigay dito ang source address, dahil binabago ng mga patakarang nakadepende sa pinagmulan ang sagot.
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 )"Pinapangalanan ng output ang papalabas na interface at ang susunod na hop. Kung ang interface ay hindi ang nakaharap sa VPN gateway, natagpuan mo ang depekto, at ang natitirang gawain ay pumili kung saan dapat naroon ang ruta. Kaunti ang pinapatunayan ng ping mula sa gateway dito: sumasagot ito gamit ang address na maipupuwesto ng malayong host, hindi ang address ng iyong laptop.
Sa Windows ang mga katumbas ay Find-NetRoute -RemoteIPAddress 10.10.5.10 para sa desisyon at Get-NetRoute para sa table. Ang rutang idinagdag gamit ang New-NetRoute at may mas mataas na metric kaysa default ay tahimik na natatalo, kaya basahin ang column ng metric, hindi ang entry. Pagkatapos ay kumpirmahin gamit ang mga packet: ipinapakita ng tcpdump -ni any "host 10.10.5.10 and tcp port 445" sa malayong LAN interface ang hiling, at ang parehong filter sa dulo ng tunnel ay nagpapakita kung may sagot na bumalik. Nakikitang hiling na walang sagot ay nangangahulugang niruta ang sagot sa ibang lugar o itinapon; ang sagot sa maling interface ay nagbibigay sa iyo ng salarin bago mo hawakan ang isang ruta.
Kapag ang gateway ng server ay hindi ang dulo ng VPN
Maraming site ang naglalagay ng firewall sa pagitan ng mga server at ng concentrator. Ipinapasa ng firewall na iyon ang sagot, kaya kailangan nito ng ruta para sa iyong client prefix na tumuturo sa VPN gateway, at patakaran sa pagpapasa sa dalawang direksyon. Mas pinapalala ito ng mga device na may state: tumawid ang hiling sa firewall mula sa isang LAN host na pinayagan nito, dumarating ngayon ang sagot mula sa ibang direksyon, at hindi na tumutugma ang entry ng connection tracking, kaya itinatapon ang packet bilang di-wasto sa halip na tinatanggihan. Ito ang dahilan kung bakit mukhang walang laman ang log ng policy habang nawawala ang trapiko.
May sariling ikalawang filter ang gateway. Itinatapon ng reverse-path filtering ng Linux ang mga packet na ang pinagmulan ay hindi maabot sa pamamagitan ng interface kung saan sila dumating, at iyon ay eksaktong hugis ng isang lehitimong asimetrikong daan pabalik. ang gabay sa pagpapasa ng strongSwan ay humihingi ng net.ipv4.ip_forward at ng luwag na net.ipv4.conf.all.rp_filter dahil mismo doon. Ang mahigpit na halagang 1 sa alinman sa mga gateway ay tahimik na sumisira ng tamang ruta, at ipinapakita ng nstat -az ang mga pagtatapon kung alam mo kung saan titingin.
| 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 |
Iruta o isalin, pagkatapos ay i-verify sa dalawang direksyon
Hindi pantay ang dalawang pag-aayos. Ang pagdaragdag ng ruta ay nagpapanatili sa address ng client, kaya patuloy na gumagana ang mga patakarang nakabatay sa pinagmulan, mga audit log at mga app na nagtatala ng tumatawag; ang halaga ay kailangan ng ruta ang bawat hop na gumagawa ng desisyon, ibig sabihin mas maraming lugar para magkamali. Maskarada sa malayong gateway pinipiga ang daan pabalik sa isang hop, dahil ang sagot ay naka-address na ngayon sa gateway mismo, at itinatago kung sinong client ang gumawa ng ano.
iptables -t nat -A POSTROUTING -o eth1 -s 10.20.30.0/24 -j MASQUERADEPiliin ito nang sadya: kapag lumitaw na ang mga client bilang address ng gateway, hindi na sila natatanging makilala ng mga ACL na nakabatay sa pinagmulan, at kailangang hawakan ng conntrack ang mapping para maisulat pabalik ang sagot sa tunnel. Kung ibinubukod pa rin ng mga selector ang client prefix, walang binabago ang NAT, dahil hindi kailanman pumasok sa tunnel ang hiling.
Bago mo sabihing naayos na ito, kumpirmahin ang apat na bagay sa pagkakasunod-sunod: ang ruta sa host na nagpapadala ng sagot, ang ruta sa bawat hop na nagpapasa nito, ang mga selector na sumasaklaw sa dalawang prefix, at isang pagkuha na nagpapakita ng sagot na pumapasok sa tunnel kasama ang pinagmulang inaasahan mo. Pagkatapos ay ulitin ang pagsubok mula sa kabilang site. Ang isang direksyong pumapasa ay kalahating-bukas na disenyo, at ang ikalawang direksyon ay kadalasang pumapalya sa dahilang iba sa karara mo lang inayos.