VPN-klient op in LAN-tsjinner: wêrom't antwurden de ferkearde kant út geane

De symptomen folgje ien patroan: in host wurket, dan ferbynt dy him as klient mei in VPN, en no berikke LAN-klanten him wylst syn antwurden ferdwine. In opname op 'e host lit sjen dat de antwurden troch it tunnelapparaat fuortgeane yn plak fan troch de LAN-ynterface. Oan 'e tunnel is neat stikken, en de oplossing is in rûte, gjin werferbining. Wurkje de fjouwer kontrôles hjirûnder yn oarder ôf en stop by de earste dy't mislearret.

In antwurd is in nij pakket, gjin omkearing

It helpt om it idee los te litten dat in antwurd werom reizget oer it paad dat in fersyk naam. Routing wurdt besletten per pakket, per rjochting, op 'e stjoerende host. In fersyk dat fan 10.64.0.23 yn 'e tunnel kaam, makket gjin werompaad; as de host antwurdet, wurdt dat antwurd as nij pakket tsjin 'e tabel hifke en ferlit it troch hokker rûte dan ek wint.

Dêrom makket in foltunnel-klient op in masine dy't ek in LAN betsjinnet sa'n betiizjende fout. De klient ynstallearret in standertrûte, of de twa heale standertrûtes dy't guon klienten ferkieze, en it antwurd oan in LAN-klant past no by de tunnel. It giet nei de provider, dy't gjin reden hat om it troch te stjoeren, en de LAN-klant sjocht in tiidferrinnen wylst de host oan is en lokaal antwurdet. De opname makket it dúdlik, en de routingstabel ferklearret it.

Hâld twa subnetten yn 't holle wylst jo de rest lêze. It iene is de VPN-adrespoule dêr't de fiere klanten wei komme, yn dit foarbyld 10.64.0.0/24. It oare is it LAN dat wurkje moat bliuwe, 172.16.24.0/24 mei syn router op 172.16.24.1. De fout is dat ferkear tusken harren troch de standertrûte besletten wurdt.

Bewiis it mei de opname en de opfrega

Foardat jo wat feroarje, befêstigje hokker apparaat it antwurd brûke sil. In opfrega is flugger as in opname en beantwurdet krekt de fraach dy't de kernel beantwurdzje sil as it pakket boud wurdt.

ip route get 10.64.0.23 from 172.16.24.10
tcpdump -ni any -c 6 icmp

Lês it antwurd yn twa dielen. As it dev tun0 neamt, sil de host it antwurd ynkapselje en oan de provider jaan, en de LAN-klant sil it nea sjen. As it dev eth0 neamt mar de klant krijt noch altyd in tiidferrinnen, is de rûte al goed en wurdt it pakket letter weilitten, wat in oar probleem is mei in oare oplossing.

De opname yn deselde stap besljochtet de twifel dy't in ping net kin. In eko-antwurd dat by de LAN-klant oankomt, bewiist dat ien of oar paad wurket, net hokker ynterface it droech, dus rin de opname op 'e host sels en sjoch wêr't de frames fuortgeane. In printer op itselde subnet bliuwt antwurdzje, want syn direkte rûte is spesifiker as de standertrûte fan 'e tunnel. In trochstjoerde poarte mislearret krekt as elke oare stream, want de tabel kiest de ynterface en de ferbining docht dat net.

Ynstallearje de nauste rûte dy't de tunnel oertroeft

De lingte fan it foarheaksel beslút, net de metryk, dus in rûte foar de klantpoule fia de LAN-router wint fan elke standertrûte dy't de VPN-klient ynstallearret. Metrykkirurgy is net nedich, en de standertrûte kin krekt bliuwe wêr't de klient him set hat.

ip route replace 10.64.0.0/24 via 172.16.24.1 dev eth0
ip route get 10.64.0.23 from 172.16.24.10

Brûk replace yn plak fan add, want in klient dy't wer ferbynt hat syn eigen ynfier al ynstallearre en in twadde add mislearret mei in flater oer in besteande rûte dy't as in rjochtenprobleem lêst. Op in Windows-host is it ekwivalint route add 10.64.0.0 mask 255.255.255.0 172.16.24.1 -p, wêr't -p de ynfier oer werstarts hâldt, om't de klient de tabel opnij bouwe kin as de tunnel wer omheech komt. Op in hjoeddeiske Windows-host is it stipe ekwivalint New-NetRoute -DestinationPrefix 10.64.0.0/24 -NextHop 172.16.24.1 -InterfaceAlias Ethernet -PolicyStore PersistentStore, wylst it âldere route-kommando as âlde foarm beholden bliuwt.

Ien detail beslút oft dit korrekt is of allinne leauweardich: de folgjende hop moat de router wêze dy't echt it paad werom nei de klanten besit. De rûte nei in adres wize dat sels troch de tunnel berikt wurdt, makket in lus dy't as tuskenskoftich ferlies ferskynt yn plak fan in skjinne fout. Befêstigje dat de folgjende hop op it LAN-subnet is foardat jo de rigel fêstlizze.

Hâld it antwurd nei in werferbining

In mei de hân tafoege rûte oerlibbet op syn bêst oant de folgjende werferbining. As de klantpoule dynamysk is, pin him dan yn 'e tsjinnerkonfiguraasje sadat it foarheaksel dat jo routed hawwe it foarheaksel bliuwt dat klanten krije; oars wiist de ynfier nei in leech berik en komt it symptoom wiken letter werom sûnder dúdlike oarsaak. De rûte yn it eigen up-skript fan 'e klient skriuwe is de oare betroubere opsje, om't it rint neidat de klient de tabel oerskreaun hat.

In steatbewuste firewall kin in korrekte rûte noch altyd ferslaan. As de opname no lit sjen dat it antwurd troch eth0 fuortgiet en de klant krijt noch altyd in tiidferrinnen, kontrolearje dan oft de host it pakket foar it ferstjoeren weilit. Strikt filterjen fan 'e omkearde rûte en net.ipv4.conf.all.rp_filter set op 1 litte pakketten weilitten wêrfan't de boarne net weromrûte wurde soe troch de ynterface dêr't se oankamen, wat krekt it asymmetryske gefal is dat jo krekt makken en doe reparearren, en de conntrack-steat fertelt itselde ferhaal foar trochstjoerde poarten.

De lêste kontrôle is dy't minsken oerslaan: werhelje de opfrega neidat de tunnel del west hat en wer omheech kaam. Fjouwer wearden moatte oerienkomme mei wat jo opskreaun hawwe: de bestimming, de folgjende hop, it apparaat en de keazen boarne. As ien fan harren ferhuze is, hat de klient de tabel oerskreaun en heart de oplossing yn syn hooks, net yn in shell-skiednis.