Antwurd fan side-nei-side-VPN giet net troch de tunnel
In antwurd dat de tunnel oerslacht is in rûtebeslissing oan de oare kant. Kontrolearje de hosttabel, de selekteurs en rp_filter, en kies dan rûte of NAT.
Ik brocht in moarn troch oan in tunnel dy’t skjin omheech kaam en ferkear krekt ien kant út ferplaatste: de filiaal koe de bestânssearfer yn it haadkertier berikke, en elk ferbining dy’t fan it haadkertier nei de filiaal iepene waard, stoar by de earste SYN. De SA’s stiene, de tunneltellers klommen, en de hânskodding wie nea it probleem. It antwurd waard rûte nei earne dêr’t de tunnel it net dekt, en dy kar heart by de fiere kant. In side-nei-side-VPN ferfiert allinnich de pakketten dy’t in host oan de gateway jout, en elk host makket dy kar apart, yn elke rjochting, út syn eigen rûtetabel.
Beide rjochtingen wurde apart rûte
IP hâldt gjin ûnthâld fan ’e rjochting fan in petear. Elk host dat in pakket stjoert, docht syn eigen syktocht nei it langste foarheaksel, kiest ien folgjende hop en ferjit de beslissing. It fersyk en it antwurd binne twa ûnferbûne pakketten dy’t tafallich by deselde ferbining hearre, en de tunnel is ien hop dy’t elk fan beide brûke kin of net. Neat yn ’e IKE-útwikseling leart de fiere searfer hoe’t er jo subnet berikt; de ûnderhanneling komt allinnich oerien hokker foarheaksels fersifere wurde meie.
Dy oerienkomst is de twadde poarte. By strongSwan binne de ferkearsselekteurs leftsubnet en rightsubnet, en in pakket wêrfan’t de boarne of de bestimming bûten it ûnderhannele pear falt, wurdt net fersifere, wat de rûtetabel ek seit. In foarheaksel dat de tunnel yn rûte wurdt mar yn ’e selekteurs mist, is in stil ienrjochtingsfalen: de rûte liket goed, it pakket giet noch altyd iepen fuort of wurdt weilitten, en allinnich it charon-log kleit.
De fiere host wit neat fan jo tunnel
Binnen it fiere LAN is it antwurd in gewoan pakket dat oan jo klant rjochte is. De bestimmingshost sjocht gjin IPsec-kop en hat gjin reden om de VPN-gateway foar te lûken; hy siket jo foarheaksel op, fynt neat spesifiker as syn standertrûte en folget dy. As de standert nei in kearn-firewall wiist, hat de firewall óf in rûte werom de tunnel yn óf net. As er dy net hat, krije jo in stil weilitten, in ICMP ûnberikber, of in antwurd dat troch de ynternetrjochte interface fuortgiet en stjert.
In twadde interface is genôch om dit te brekken sels as der in rûte bestiet. In NAS mei in behearferbining op in oar VLAN, in searfer mei in reserve-uplink, in beliedsregel dy’t ien boarnerik nei in twadde tabel stjoert: elk fan dizze kin it antwurd pakke. Op Linux litte ip rule show en ip route show table all regels en tabellen sjen dy’t de standertlist ferberget.
Lês de beslissing op ’e masine dy’t it antwurd stjoert
Freegje de kernel foardat jo wat feroarje, en jou him it boarneadres, want boarneôfhinklike regels feroarje it antwurd.
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 )"De útfier neamt de útgonginterface en de folgjende hop. As de interface net dy is dy’t nei de VPN-gateway rjochte is, hawwe jo it mank fine, en it oerbliuwende wurk is kieze wêr’t de rûte heart. In ping fan ’e gateway bewurdt hjir wat in bytsje: it antwurdet mei in adres dat de fiere host pleatse kin, net mei it adres fan jo laptop.
Op Windows binne de ekwivalinten Find-NetRoute -RemoteIPAddress 10.10.5.10 foar de beslissing en Get-NetRoute foar de tabel. In rûte tafoege mei New-NetRoute dy’t in hegere metryske wearde as de standert hat, ferliest stil, lês dus de metrykkolom, net de ynskriuwing. Befêstigje dan mei pakketten: tcpdump -ni any "host 10.10.5.10 and tcp port 445" op ’e fiere LAN-interface lit it fersyk sjen, en deselde filter oan ’e tunnelkant lit sjen oft der in antwurd weromkaam. Fersyk sichtber sûnder antwurd betsjut dat it antwurd earne oars rûte is of weilitten; in antwurd op ’e ferkearde interface jout jo de skuldige foardat jo in rûte oanreitsje.
As de gateway fan ’e searfer net it VPN-einpunt is
In protte sites sette in firewall tusken de searfern en de konsintrator. Dy firewall stjoert it antwurd troch, dus hy hat in rûte foar jo klantfoarheaksel nei de VPN-gateway nedich, en trochstjoerbelied yn beide rjochtingen. Tastânapparaten meitsje it slimmer: it fersyk stuts de firewall oer fan in LAN-host dy’t it taliet, it antwurd komt no fan in oare rjochting, en de ferbiningsfolchynskriuwing past net mear, dus it pakket wurdt as ûnjildich weilitten yn stee fan wegere. Dêrom liket it beliedslog leech wylst it ferkear ferdwynt.
De gateway hat syn eigen twadde filter. Linux syn omkearde-paadfiltering lit pakketten wei wêrfan’t de boarne net berikber is fia de interface dêr’t se op oankamen, en dat is krekt de foarm fan in legitime asymmetryske weromwei. de trochstjoerlieding fan strongSwan freget net.ipv4.ip_forward en in fersloppe net.ipv4.conf.all.rp_filter krekt dêrom. In strikte wearde fan 1 op ien fan beide gateways brekt stil in goede rûte, en nstat -az lit de weilittings sjen as jo witte wêr’t jo sjen moatte.
| 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 |
Rûte of oersette, en ferifiearje dan yn beide rjochtingen
De twa reparaasjes binne net gelykweardich. In rûte tafoegje hâldt it klantadres yntakt, dus boarnebasearre regels, auditlogs en applikaasjes dy’t de opropper fêstlizze bliuwe wurkjen; de priis is dat elke hop dy’t de beslissing nimt de rûte nedich hat, wat mear plakken is om mis te wêzen. Maskeraasje op ’e fiere gateway krimpt de weromwei ta ien hop, want it antwurd is no oan ’e gateway sels rjochte, en ferberget hokker klant wat dien hat.
iptables -t nat -A POSTROUTING -o eth1 -s 10.20.30.0/24 -j MASQUERADEKies it bewust: sadree’t klanten as it gatewayadres ferskine, hâlde boarnebasearre ACL’s op mei se fan elkoar te ûnderskieden, en conntrack moat de mapping hâlde sadat it antwurd werom de tunnel yn skreaun wurdt. As de selekteurs it klantfoarheaksel noch útslute, feroaret NAT neat, want it fersyk is nea de tunnel yn kommen.
Foardat jo it reparearre neame, befêstigje fjouwer dingen yn folchoarder: de rûte op ’e host dy’t it antwurd stjoert, de rûte op elke hop dy’t it trochstjoert, de selekteurs dy’t beide foarheaksels dekke, en in opname dy’t lit sjen dat it antwurd de tunnel yngiet mei de boarne dy’t jo ferwachtsje. Werhelje dan de test fan ’e oare site. Ien rjochting dy’t slagget is in heal-iepen ûntwerp, en de twadde rjochting mist wurket ornaris om in oare reden as dy’t jo krekt reparearre hawwe.