Koha-kohta VPN-i vastus ei läbi tunnelit
Tunnelist mööda minev vastus on marsruutimisotsus kaugemal poolel. Kontrollige hostitabelit, selektoreid ja rp_filterit, seejärel valige marsruut või NAT.
Vedasin hommiku tunneliga, mis tuli puhtalt üles ja liigutas liiklust täpselt ühes suunas: haru pääses peakontori failiserverile ligi ja iga peakontorist harru avatud ühendus suri esimese SYN-i juures. SA-d olid üleval, tunneli loendurid kasvasid ja kätlemine ei olnud kunagi probleem. Vastust marsruuditi kuhugi, kuhu tunnel ei ulatu, ja see valik kuulub kaugemale poolele. Koha-kohta VPN kannab ainult pakette, mille host lüüsile üle annab, ja iga host teeb selle valiku eraldi, igas suunas, oma marsruutimistabelist.
Mõlemat suunda marsruuditakse eraldi
IP ei hoia vestluse suuna kohta mingit mälu. Iga host, mis paketi saadab, teeb oma pikima prefiksi otsingu, valib ühe järgmise hüppe ja unustab otsuse. Päring ja vastus on kaks seostamata paketti, mis juhtumisi kuuluvad samasse ühendusse, ja tunnel on üks hüpe, mida kumbki neist võib kasutada või mitte. Miski IKE-vahetuses ei õpeta kaugserverile, kuidas teie alamvõrku jõuda; läbirääkimine lepib kokku ainult selles, milliseid prefikseid võib krüpteerida.
See kokkulepe on teine värav. strongSwanis on liiklusselektorid leftsubnet ja rightsubnet ning paketti, mille allikas või sihtkoht jääb läbiräägitud paarist välja, ei krüpteerita, mida iganes marsruutimistabel ütleb. Prefiks, mis marsruuditakse tunnelisse, kuid puudub selektoritest, on vaikne ühesuunaline tõrge: marsruut näib õige, pakett väljub siiski krüpteerimata või visatakse ära, ja kurdab ainult charoni logi.
Kaugem host ei tea teie tunnelist midagi
Kaugema kohtvõrgu sees on vastus tavaline pakett, mis on adresseeritud teie kliendile. Sihtkoha host ei näe ühtegi IPsec-päist ja tal pole põhjust VPN-lüüsi eelistada; ta otsib teie prefiksi, ei leia midagi täpsemat kui oma vaikemarsruut ja järgib seda. Kui vaikemarsruut osutab tuum-tulemüürile, on tulemüüril kas tunnelisse tagasi viiv marsruut või mitte. Kui pole, saate vaikse mahaviskamise, ICMP kättesaamatuse või vastuse, mis lahkub internetipoolsest liidesest ja sureb.
Teisest liidesest piisab, et see katki teha ka siis, kui marsruut on olemas. NAS, mille halduslink on teises VLAN-is, varu-uplinkiga server, poliitikareegel, mis saadab ühe allikavahemiku teise tabelisse: ükskõik milline neist võib vastuse kinni püüda. Linuxis näitavad ip rule show ja ip route show table all reegleid ja tabeleid, mida vaikeloend varjab.
Lugege otsust masinal, mis vastuse saadab
Küsige tuumalt enne, kui midagi muudate, ja andke sellele allikaaadress, sest allikast sõltuvad reeglid muudavad vastust.
ip route get 10.10.5.10 from 10.20.30.15
ip rule show
ip route show table all
ss -tn state established "( sport = :445 )"Väljund nimetab väljuva liidese ja järgmise hüppe. Kui liides ei ole see, mis vaatab VPN-lüüsi poole, olete vea leidnud, ja ülejäänud töö on valida, kuhu marsruut kuulub. Lüüsist tehtud ping tõestab siin vähe: see vastab aadressiga, mille kaugem host suudab paigutada, mitte teie sülearvuti aadressiga.
Windowsis on ekvivalendid Find-NetRoute -RemoteIPAddress 10.10.5.10 otsuse jaoks ja Get-NetRoute tabeli jaoks. Marsruut, mis on lisatud käsuga New-NetRoute ja mille mõõdik on vaikeväärtusest kõrgem, kaotab vaikselt, seega lugege mõõdiku veergu, mitte kirjet. Seejärel kinnitage pakettidega: tcpdump -ni any "host 10.10.5.10 and tcp port 445" kaugema kohtvõrgu liidesel näitab päringut ja sama filter tunneli poolel näitab, kas vastus tuli tagasi. Nähtav päring ilma vastuseta tähendab, et vastus marsruuditi mujale või visati ära; vastus valel liidesel annab süüdlase enne, kui marsruuti puutute.
Kui serveri lüüs ei ole VPN-i lõpp-punkt
Paljud kohad panevad serverite ja kontsentraatori vahele tulemüüri. See tulemüür edastab vastuse, seega vajab see teie kliendi prefiksile marsruuti, mis osutab VPN-lüüsile, ja edastuspoliitikat mõlemas suunas. Olekut säilitavad seadmed teevad asja hullemaks: päring läbis tulemüüri kohtvõrgu hostist, mille see lubas, vastus saabub nüüd teisest suunast ja ühenduse jälgimise kirje ei sobi enam, mistõttu pakett visatakse ära kehtetuna, mitte keelatuna. Sellepärast näeb poliitikalogi tühi välja, samal ajal kui liiklus kaob.
Lüüsil on oma teine filter. Linuxi pöördtee filtreerimine viskab ära paketid, mille allikas ei ole kättesaadav selle liidese kaudu, kuhu nad saabusid, ja see on täpselt seadusliku asümmeetrilise tagasitee kuju. strongSwani edastusjuhend nõuab just sel põhjusel net.ipv4.ip_forward ja lõdvendatud net.ipv4.conf.all.rp_filter. Range väärtus 1 kummalgi lüüsil rikub vaikselt korrektse marsruudi ja nstat -az näitab mahaviskamisi, kui teate, kuhu vaadata.
| Symptom | Where the reply is most likely lost |
|---|---|
| Gateway ping works, LAN host silent | Source address the far host cannot place in its table |
| SYN arrives, no SYN-ACK, tunnel counters flat | No route to the client prefix on the far host or its gateway |
| Reply counted on the internet-facing interface | Default route or policy rule on the far host |
| Firewall reports invalid state | Asymmetric path through a stateful device |
| Worked until a link failed over | New path is asymmetric, or rp_filter now rejects it |
Marsruutige või tõlkige, seejärel kontrollige mõlemas suunas
Kaks parandust ei ole samaväärsed. Marsruudi lisamine hoiab kliendi aadressi puutumatuna, nii et allikapõhised reeglid, auditi logid ja rakendused, mis kutsujat kirja panevad, töötavad edasi; hind on see, et iga otsust tegev hüpe vajab marsruuti, mis on rohkem kohti, kus eksida. Maskeerimine kaugemal lüüsil surub tagasitee ühele hüppele kokku, sest vastus on nüüd adresseeritud lüüsile endale, ja varjab, milline klient mida tegi.
iptables -t nat -A POSTROUTING -o eth1 -s 10.20.30.0/24 -j MASQUERADEValige see teadlikult: kui kliendid hakkavad paistma lüüsi aadressina, lakkavad allikapõhised ACL-id neid eristamast ja conntrack peab vastendust hoidma, et vastus kirjutataks tunneli tagasi. Kui selektorid jätavad kliendi prefiksi endiselt välja, ei muuda NAT midagi, sest päring ei sisenenud kunagi tunnelisse.
Enne kui nimetate selle parandatuks, kinnitage neli asja järjekorras: marsruut hostil, mis vastuse saadab, marsruut igal hüppel, mis seda edastab, selektorid, mis katavad mõlemad prefiksid, ja salvestus, mis näitab vastuse sisenemist tunnelisse oodatud allikaga. Seejärel korrake testi teisest kohast. Üks läbiv suund on poollahtine lahendus ja teine suund ebaõnnestub tavaliselt teistsugusel põhjusel kui see, mille just parandasite.