Rûtearre VPN-klant berikt de tsjinner mar net de LAN-hosts

De tunnel komt omheech, de klant pinget de VPN-tsjinner, en in dielde map op in masine ien sprong fierder antwurdet nea. Neat yn 'e konfiguraasje fan 'e klant ferklearret dat, want it fersyk hat de klant wol ferlitten en is wol oankommen. Wat mislearre is de weromreis, en it apparaat dat mislearre is meastentiids de LAN-gateway en net de VPN-host. It antwurdpakket folgje ferklearret de hiele klasse fan symptomen.

Folgje it Antwurd, Net it Fersyk

De VPN-tsjinner ûntsiferet it pakket fan 'e klant en stjoert it nei de LAN troch mei it adres fan 'e klant noch yn it boarnefjild. De bestimming-host antwurdet op dat adres, en no beslút syn eigen rûtetabel alles. Syn standertgateway wit neat fan 'e tunnelpool, dat it antwurd giet rjochting de ynternetprovider en wurdt earne op dy wei fuortgoaid.

By de klant is it symptoom in stil tiidferrin: gjin wegering, gjin reset, gewoan neat. It blêdzjen troch in dielde map hinget, in ping meldt gjin antwurd, en de tsjinnerlogboeken sjogge sûn út om't de tsjinner syn wurk dien hat.

Set de Weromrûte Dêr't de Hosts Sjogge

Elke LAN-host rieplachtet syn standertgateway, dat de gateway is it iene apparaat dat witte moat wêr't de tunnelpool wennet. Foegje dêr in statyske rûte ta en elke host erft it krekte paad sûnder oanrekke te wurden.

As de gateway syn eigen adres as DHCP-opsje útdielt, ferspriedt de rûte op dy wize sadat nije masines it automatysk oernimme. Oars wennet de rûte yn ien konfiguraasjebestân en ferdwynt by de folgjende weropbou.

# 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

Wêrom't Boarne-NAT it liket te reparearjen

It kliïntpool efter it adres fan 'e VPN-tsjinner ferstopje hellet it probleem fuort troch it adres fan 'e klant út it pakket te heljen. Antwurden komme dan werom by de tsjinner, dy't al wit hoe't er de tunnel berikke moat, en alles wurket. De priis is dat ynterne hosts net mear sjen kinne wa't de klant is, en elke ferbining liket fan ien masine te kommen.

Dy ruil is soms korrekt, bygelyks as in apparaat fan in leveransier gjin statyske rûte krije kin. Meitsje de regel net breder as de hjoeddeiske pool, want in regel skreaun foar in /24 hâldt op te passen op 'e dei dat de pool omnummerearre wurdt nei in /16, en it earste teken is in kloft nije klanten dy't ferbine en neat berikke.

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

It Wolkepaad Hat Trije Ynstellings Nodich

Yn in VPC komt deselde leechte yn in oare foarm werom, want it subnet hat hielendal gjin rûte foar it klantberik. De rûtetabel hat in ynskriuwing nedich foar de tunnelpool dy't op 'e netwurkynterface fan 'e ynstânsje rjochte is, en de ynterface moat kontrôle fan boarne en bestimming útskeakele hawwe sadat it platfoarm pakketten akseptearret wêrfan't de boarne net syn eigen adres is. Feiligensgroepen en netwurk-ACL's moatte de pool ek yn beide rjochtingen talitte.

Elke weglitting jout in aparte foar in part mislearring. Slop de ynskriuwing fan 'e rûtetabel oer en partikuliere ynstânsjes antwurdzje yn in subnet dat it antwurd net werom nei de pool drage kin. Mei de kontrôle noch oan lit it platfoarm it antwurd falle nei't de ynstânsje it al stjoerd hat. Sûnder de regel fan 'e feiligensgroep komt it fersyk sels nea oan, en de klant sjocht it tiidferrin ien laach earder.

Doch de Kontrôles yn Dizze Oarder

Befêstigje troerstjoering en it filterbelied foardatst it rûtsjen de skuld jout, want in host dy't net troerstjoere sil mislearret op deselde stille wize. Lês dan de effektive ynstelling foar de weromwei op 'e ynterface dy't de tunnel draacht, want in strang filter kin antwurden fuortsmite dy't út in ûnferwachte rjochting komme.

Einigje mei in opname op 'e LAN-host wylst de klant dy pinget. In fersyk dat oankomt sûnder byhearrend antwurd bewiist it werompaad, en in fersyk dat nea oankomt ferpleatst de skuld werom nei de tsjinner of de tunnel.

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

De kontrôle fan boarne en bestimming is dokumintearre yn 'e hânlieding foar elastyske netwurkynterfaces. Set dy op 'e ynterface dy't it tunnelferkear echt draacht, net op in net besibbe adapter oan deselde ynstânsje.