VPN ferbynt, mar LAN-apparaten binne net berikber: wat te kontrolearjen

Ferkeer giet de tunnel yn, de gateway antwurdet op syn eigen adres, en neat efter him antwurdet. Dat patroan is gewoan en it is gjin tsjinspraak: in antwurd fan de gateway bewist dat de tunnel einige is, en it bewist neat oer wat der bart mei in pakket dat efter him adressearre is. De beide tests brûke ferskillende kodepaden op deselde masine.

Test fan no ôf eat oan de oare kant fan de gateway. It eigen adres fan de gateway sil trochgean mei antwurdzjen, hoe brutsen de trochstjoering ek is.

De gateway antwurdet út syn eigen steapel

In pakket dat oan de gateway adressearre is, wurdt oan syn lokale ynfiertrajekt levere, wêr't de kearn beslút oft in harkjende socket it akseptearret. In pakket dat oan in host efter de gateway adressearre is, wurdt ynstee oan it trochstjoertrajekt levere, wêr't in oare set kontrôles jildt. Trochstjoering kin hielendal útskeakele wêze, of troch de kearn ynskeakele en dan troch in filterregel wegere wurde dy't de tunnel nea neamt. Neat dêrfan beynfloedet it eigen antwurd fan de gateway, dêrom misliedt it symptoom sa betrouber.

Bestjoerssiden dy't troch de tunnel berikt wurde, hearre ek ta de earste kategory. Se binne bewiis oer de tunnel, net oer it netwurk dêrefter.

Folgje de stream oant de earste grins dy't him falle lit

Begjin by de klant en befêstigje de rûte en it boarneadres dat de stream brûke sil. Besjoch dan de gateway foar it oankommen fan krekt dy stream, en wer foar deselde stream dy't nei de LAN fuortgiet. As er nea oankomt, is it probleem oan de klantkant of yn de tastiene prefiksen fan de tunnel. As er oankomt en nea fuortgiet, is it probleem yn de trochstjoering of yn in filter fan it foarútpaad, en de opname hat al sein hokker.

Deselde test fan de gateway út útfiere ferberget de nijsgjirrige helte, want in pakket dat fan de gateway ôfkomstich is, hat in oare boarne en in oare weromkearfoarde. Brûk de stream fan de klant, mei syn eigen boarneadres, by elke stap. In opname op de ferkearde ynterface leveret selsbetrouwe ûnsin.

Weromrûtes en host-firewalls mislearje apart

Sadree't it pakket de host berikt, moatte noch trije dingen jilde. De tsjinst moat harkje op it adres dêr't it pakket hinne stjoerd is, de firewall fan de host moat it akseptearje, en it antwurd moat in rûte werom nei de klantpool hawwe. Dat lêste mislearret faak, want de standertrûte fan de host wiist nei in router dy't nea fan it tunnelberik heard hat. It resultaat is in ferbining dy't út it eachpunt fan de host ta stân komt en yn de oare rjochting stil stjert.

Test it werompaad opsetlik troch fan de klant te stjoeren en op de weromkear te achtsjen. In ienrjochtingsopname beslist yn sekonden wat in oere spekulaasje net beslisse sil.

Befêstigje elke hop mei it boarneadres fan de klant

Fier de kontrôles yn folchoarder út en bewarje elke útfier, want de wearde sit yn de fergeliking, net yn ien inkelde rigel. De opdrachten hjirûnder fêstigje it boarneadres, litte de keazen rûte sjen en nimme beide kanten fan de trochstjoering op. Ferfang dyn eigen LAN-host en tunnel-ynterface.

ip route get 192.168.50.20 from 10.8.0.2
ping -I 10.8.0.2 -c 3 192.168.50.20
sudo tcpdump -ni tun0 host 192.168.50.20
sudo tcpdump -ni br0 host 192.168.50.20

De rûtefrage lit sjen oft de klant dat pakket ea de tunnel yn stjoere soe, en de ping lit sjen oft der eat fan de host weromkaam. It fergelykjen fan de twa opnames skiedt oankomst fan útgong, want in ramt op de tunnel-ynterface sûnder wjergea op de LAN-ynterface is in trochstjoerbeslissing, gjin tsjinstfout. As beide opnames it fersyk litte sjen en mar ien it antwurd, is de weromrûte de oerbleaune fertochte.

Skriuw op hokker adres antwurde en hokker trochstjoerde bestimming mislearre. Dy sin makket it rapport útfierber ynstee fan in bewearing dat de server net berikber is.