VPN-klient LAN-serveris: miks vastused väljuvad vale teed

Sümptomid järgivad üht mustrit: host töötab, seejärel ühendub see kliendina VPN-iga ja nüüd jõuavad LAN-kliendid selleni, samal ajal kui selle vastused kaovad. Hostil tehtud püüdmine näitab, et vastused väljuvad tunneli seadmest, mitte LAN-liidesest. Tunnelis pole midagi katki ja parandus on marsruut, mitte taasühendus. Käige allolevad neli kontrolli järjekorras läbi ja peatuge esimesel, mis ebaõnnestub.

Vastus on uus pakett, mitte tagasipööramine

Aitab loobuda ideest, et vastus rändab tagasi mööda teed, mille päring läbis. Marsruutimine otsustatakse iga paketi ja iga suuna kohta saatval hostil. Päring, mis saabus tunnelis 10.64.0.23 aadressilt, ei loo tagasiteed; kui host vastab, võrreldakse seda vastust tabeliga uue paketina ja see väljub marsruudil, mis võidab.

Seetõttu tekitab täistunneli klient masinas, mis teenindab ka LAN-i, nii segadust tekitava tõrke. Klient paigaldab vaikimisi marsruudi või kaks poolvaikimisi marsruuti, mida mõned kliendid eelistavad, ja vastus LAN-kliendile sobib nüüd tunneliga. See läheb teenusepakkujale, kellel pole põhjust seda edasi saata, ja LAN-klient näeb ajalõppu, kuigi host on üleval ja vastab kohapeal. Püüdmine teeb selle ilmselgeks ja marsruutimistabel selgitab seda.

Hoidke lugemise ajal mõttes kahte alavõrku. Üks on VPN-i aadressibassein, kust kaugkliendid tulevad, selles näites 10.64.0.0/24. Teine on LAN, mis peab töötama jääma, 172.16.24.0/24 oma ruuteriga aadressil 172.16.24.1. Viga on selles, et nendevahelise liikluse otsustab vaikimisi marsruut.

Tõestage seda püüdmise ja päringuga

Enne kui midagi muudate, kinnitage, millist seadet vastus kasutab. Päring on püüdmisest kiirem ja vastab täpselt sellele küsimusele, millele tuum vastab paketi koostamisel.

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

Lugege vastust kahes osas. Kui see nimetab dev tun0, kapseldab host vastuse ja annab selle teenusepakkujale ning LAN-klient ei näe seda kunagi. Kui see nimetab dev eth0, aga klient saab ikkagi ajalõpu, on marsruut juba õige ja pakett visatakse hiljem ära, mis on teine probleem ja teistsugune parandus.

Sama sammu püüdmine lahendab kahtluse, mida ping ei suuda. LAN-kliendini jõudev kaja vastus tõestab, et mõni tee töötab, mitte milline liides seda kandis, seega tehke püüdmine hostil endal ja jälgige, kust kaadrid väljuvad. Samas alavõrgus olev printer vastab edasi, sest selle otsetee on täpsem kui tunneli vaikimisi marsruut. Edasisaadetud port ebaõnnestub täpselt nagu iga teine voog, sest liidese valib tabel, mitte ühendus.

Paigaldage kitsaim marsruut, mis tunnelist üle käib

Otsustab prefiksi pikkus, mitte mõõdik, seega LAN-ruuteri kaudu kliendibasseini marsruut võidab iga vaikimisi marsruudi, mille VPN-klient paigaldab. Mõõdikukirurgiat pole vaja ja vaikimisi marsruut võib jääda täpselt sinna, kuhu klient selle pani.

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

Kasutage replace add asemel, sest uuesti ühenduv klient on juba oma kirje paigaldanud ja teine add ebaõnnestub olemasoleva marsruudi veaga, mis loeb nagu õiguste probleem. Windowsi hostis on vaste route add 10.64.0.0 mask 255.255.255.0 172.16.24.1 -p, kus -p hoiab kirjet üle taaskäivituste, sest klient võib tabeli uuesti üles ehitada, kui tunnel tagasi tuleb. Praeguses Windowsi hostis on toetatud vaste New-NetRoute -DestinationPrefix 10.64.0.0/24 -NextHop 172.16.24.1 -InterfaceAlias Ethernet -PolicyStore PersistentStore, kusjuures vanem käsk route säilib pärandvormina.

Üks detail otsustab, kas see on õige või ainult usutav: järgmine hüpe peab olema ruuter, mis tegelikult omab teed tagasi klientideni. Marsruudi suunamine aadressile, mis on ise tunnelist saavutatav, loob ahela, mis ilmneb vahelduva kao, mitte puhta tõrkena. Enne rea sisestamist kinnitage, et järgmine hüpe on LAN-alavõrgus.

Hoidke vastus pärast taasühendust

Käsitsi lisatud marsruut püsib parimal juhul järgmise taasühenduseni. Kui kliendibassein on dünaamiline, kinnitage see serveri konfiguratsiooni, et teie marsruuditud prefiks jääks prefiksiks, mille kliendid saavad; vastasel juhul osutab kirje tühjale vahemikule ja sümptom naaseb nädalaid hiljem ilma ilmse põhjuseta. Marsruudi kirjutamine kliendi enda up-skripti on teine usaldusväärne valik, sest see jookseb pärast seda, kui klient on tabeli ümber kirjutanud.

Olekupõhine tulemüür võib õige marsruudi siiski alistada. Kui püüdmine näitab nüüd, et vastus väljub eth0 kaudu, ja klient saab ikkagi ajalõpu, kontrollige, kas host viskab paketi enne saatmist ära. Range pöördtee filtreerimine ja net.ipv4.conf.all.rp_filter väärtusele 1 seatuna viskavad ära paketid, mille allikat ei marsruuditaks tagasi välja liidesest, millelt need saabusid, mis on täpselt see asümmeetriline juhtum, mille te just lõite ja siis parandasite, ning conntracki olek räägib sama lugu edasisaadetud portide puhul.

Viimane kontroll on see, mille inimesed vahele jätavad: korrake päringut pärast seda, kui tunnel on olnud maas ja uuesti üleval. Neli väärtust peaksid vastama sellele, mille üles kirjutasite: sihtkoht, järgmine hüpe, seade ja valitud allikas. Kui mõni neist liikus, kirjutas klient tabeli ümber ja parandus kuulub selle konksudesse, mitte shelli ajalukku.