Fierbrûkers berikke it twadde plak net troch de VPN-hub

In fierbrûker ferbynt mei de hub, berikt de triemtsjinner op it eigen LAN fan de hub, en alles liket sûn. Dan iepenet hy in dielde map op 10.20.0.50 by it haadkantoar, dy’t de hub oer in aparte tunnel tusken lokaasjes berikt, en it rint ôf. Beide tunnels steane oan en beide tellers klimme, dus gjin tunnel is stikken. De hub oerstekke binne trije rûtebesluten op trije apparaten, en in tunnel draacht allinnich de prefiksen dêr’t er foar boud is. Hjir is de oarder dy’t ik kontrolearje, en it kommando dat sjen lit oft elke stap wier is.

Trochgong freget trije opsochten, net ien tunnel

Elk apparaat docht syn eigen oerienkomst fan it langste prefiks en ferjit dy. De laptop moat 10.20.0.50 de tunnel yn stjoere ynstee fan nei syn lokale router. De hub moat in pakket dat op de fierboartsjinst-ynterface oankaam oan de ynterface tusken lokaasjes oerjaan. It haadkantoar moat in antwurd foar it adres fan de brûker werom stjoere troch de tunnel. As ien fan de trije mist, sjocht dat der yn de browser itselde út: stilte.

Dêrom bewiist it testen fan elke tunnel apart sa weinig. In ping nei it LAN-adres fan de hub oefenet it earste beslút, en in ping nei de hub fan it haadkantoar oefenet it tredde. It pakket dat mist hat de brûkerspoel as boarne en it twadde plak as bestimming, dus skriuw dy prefiksen earst op. Hjir is de poel 10.80.0.0/24, it LAN fan de hub 10.10.0.0/24 en it haadkantoar 10.20.0.0/24.

Stjoer it fiere prefiks nei de fiere klant

Op in OpenVPN fierboartsjinst-tsjinner leart de klant rûtes by it ferbinen. Sûnder push stjoert in klant mei in split-tunnel 10.20.0.50 nei syn eigen gateway en komt it pakket nea de tunnel yn.

push "route 10.20.0.0 255.255.255.0"

In pushte rûte jildt as de klant ferbynt, dus in brûker dy’t online bliuwt sjocht neat oant er wer ferbynt. Kontrolearje op de klant: ip route get 10.20.0.50 op Linux, route print op Windows. De útfier moat de tunnel-ynterface neame.

De push helpt de hub net. It is in berjocht oan de klant, gjin rûte op de tsjinner en gjin tastimming om troch te stjoeren, dus in hub mei de perfekte push-rigel lit de stream dochs in hop letter falle. Dat is de gewoane reden wêrom’t minsken konkludearje dat de push mislearre.

Jou de hub in echte útgongsrûte

De hub hat syn eigen folgjende hop nedich foar it prefiks fan it haadkantoar. Op in rûtearre tunnel is dat in gewoane rûte troch de ynterface tusken lokaasjes, en ien kommando lit sawol de keazen rûte as de keazen boarne sjen:

ip route get 10.20.0.50 from 10.80.0.25
sudo ip route add 10.20.0.0/24 via 172.30.0.2 dev s2s0

As it skaai tusken lokaasjes sels OpenVPN is, kin de rûte yn dy konfiguraasje libje mei it tunneladres fan de partner as gateway: route 10.20.0.0 255.255.255.0 172.30.0.2. De gateway is net opsjoneel. Lit it wei en de folgjende hop falt nei in ymplemintaasje-standert, dy’t ferskilt tusken in klant mei ien partner en in hub mei mear partners.

IPsec op basis fan belied is oars: de kernel fan de hub stjoert it pakket nei syn gewoane LAN-gateway en it belied fangt it op de wei nei bûten, dus in tunnelrûte docht óf neat óf liedt ferkear by it belied lâns. Sjoch nei de boarne yn it kommando hjirboppe, want 10.10.0.1 ynstee fan it poeladres betsjut dat de kernel in adres keas dat de fiere kant wegerje sil. iroute is ek net it antwurd; it fertelt de tsjinner hokker klant in subnet efter syn eigen tunnel besit, net wêr’t ferkear foar in tredde plak hinne moat.

Wreidzje de fiere kant út nei de brûkerspoel

It haadkantoar dekt al it LAN fan de hub, 10.10.0.0/24. De brûkerspoel is in twadde prefiks en moat ek yn de selektors stean, oars dekt gjin belied in antwurd dat oan 10.80.0.25 rjochte is. Elke partner neamt itselde pear prefikssets fan syn eigen kant:

# strongSwan swanctl.conf, on the hub
local_ts  = 10.10.0.0/24, 10.80.0.0/24
remote_ts = 10.20.0.0/24

# on the headquarters peer
local_ts  = 10.20.0.0/24
remote_ts = 10.10.0.0/24, 10.80.0.0/24

De local_ts fan it iene apparaat is de remote_ts fan it oare. Kopiearje it hubblok nei it haadkantoar en it pear is omkeard, dus de child SA komt nea omheech.

De âldere ipsec.conf syntaksis brûkt in komma-skieden leftsubnet. De rinnende befeiligingsassosjaasje hâldt de selektors dy’t er ûnderhannele hat, dus meitsje de tunnel op ’e nij nei de wiziging. In selektor feroare om 10:00 en testen tsjin in SA dy’t om 09:40 omheech kaam, mist noch, wylst it konfiguraasjebestân de hiele tiid korrekt liket.

Kontrolearje dan de lêste hop. ip route get 10.80.0.25 op it fiere einpunt moat de tunnel yn wize. As de tsjinst in LAN-router as standertgateway brûkt, hat dy router ek de weromrûte nedich, oars stjert it antwurd dêr. tcpdump -ni eth1 host 10.80.0.25 op dat segmint lit sjen oft it antwurd it einpunt hielendal ferlitten hat.

Tastean it stream op de hub

Trochstjoeren moat oan stean en it paad tastean. Behein de regels ta de twa prefiksen ynstee fan alles tusken de ynterfaces te akseptearjen.

sysctl -w net.ipv4.ip_forward=1
iptables -I FORWARD -i tun0 -o s2s0 -s 10.80.0.0/24 -d 10.20.0.0/24 -j ACCEPT
iptables -I FORWARD -i s2s0 -o tun0 -s 10.20.0.0/24 -d 10.80.0.0/24 -j ACCEPT

Filtering fan it werompaad is de stille flater dernaast: as de beide skaaien op ferskate ynterfaces steane, kin rp_filter=1 it antwurd falle litte wylst de teller fan de akseptregel nea beweecht. Ferlykje iptables -vnL FORWARD foar en nei in besykjen. In regel dy’t nea omheech giet, wurdt net berikt, dus sjoch in laach leger ynstee fan him oer te skriuwen.

As mar ien groep trochgong nedich hat, set de rûte yn in bestân per klant ûnder client-config-dir ynstee fan de globale push te wreidzjen. Boarne-NAT op de hub hellet ek de needsaak foar in fiere weromrûte wei, mar it ferberget it adres fan de brûker, dus de logs fan it fiere plak en adresbasearre regels hâlde op mei brûkers te ûnderskieden.

Kontrolearje fan de klant, en draai dan yn omkearde oarder werom

Test in TCP-poarte, net allinnich ICMP, want in ping kin trochgean wylst de tsjinst blokkearre bliuwt. nc -vz 10.20.0.50 445 en traceroute -n 10.20.0.50 fan de klant litte sjen oft de twadde hop it tunneladres fan de hub is. Op de hub tcpdump -ni tun0 host 10.20.0.50 en deselde filter op de ynterface tusken lokaasjes: in fersyk op beide sûnder antwurd op ien fan beide ferpleatst it probleem nei de fiere kant.

Test dan eat dat blokkearre bliuwe moat. As in host dy’t de poel nea berikke mei ek antwurdet, hawwe jo mear as trochgong iepene en moatte jo de regels ferkringe. In hub dy’t alles nei elke tûke trochstjoert, slagget foar de earste test en mist de twadde.

Hâld in weromdraailist by, want fjouwer objekten binne feroare en trije binne maklik te ferjitten: de pushte rûte, de rûte fan de hub, de selektors en de firewallregels. Draai se yn omkearde oarder werom, meitsje de SA op ’e nij en lit ien brûker wer ferbine. In partiele weromdraai lit in rûte efter dy’t nei in tunnel wiist dy’t net mear past, wat hurder te lêzen is as de oarspronklike stilte. It OpenVPN 2.6-hânboek dokumintearret push, route en iroute foar jo ferzje.