Millise paketiga peab kahe WAN-iga VPN-poliitika sobima?
Site-to-site transport ja kasutaja dekrüpteeritud voog väljuvad eri otsustuspunktide kaudu. Leidke see, mida teie WAN-poliitika tegelikult näeb, ja testige seda.
Taotlused suunata VPN teise üleslingi kaudu kirjeldavad vähemalt kahte erinevat tööd, ja poliitika, mis parandab ühe, ei puuduta teist. Esimeses töös liigub kahe lõpp-punkti vaheline krüpteeritud transport teisele WAN-aadressile. Teises väljub ühendatud kasutaja dekrüpteeritud rakendusevoog teise järgmise hüppe suunas. Mõlemad on legitiimsed, mõlemad kasutavad marsruutimist, ja kumbki vajab vastet paketil, mis eksisteerib otsuse tegemise punktis. Käige allolevad kontrollid järjekorras läbi, sest esimene määrab, millisele paketile peavad hilisemad reeglid viitama.
Nimetage kaks vestlust
Kujutage ette kaugtöötajat, kes on ühendatud kontori lüüsile ja avab HTTPS-i sisemise rakendusserveri vastu. Juhtmel on kaks sõltumatut vestlust ja neil on mõlemas otsas erinevad aadressid. Välimine vestlus kulgeb kahe VPN-i lõpp-punkti vahel: lüüsi aadressilt partneri aadressile, mis tahes protokollis ja pordis, mille juurutamine läbi rääkis. Sisemine vestlus kulgeb kliendile määratud aadressilt rakendusserveri aadressile pordil 443.
Rakenduse sihtport ei ole VPN-i transpordiport, ja ükski poliitika kogus TCP 443 peal ei liiguta tunnelit. Samamoodi ei ütle reegel, mis suunab partneri transpordiaadressi ümber, midagi selle kohta, kuhu selle kasutaja HTTP-päring pärast dekrüpteerimist läheb. Kirjutage mõlemad vestlused oma tegelike aadressidega üles enne, kui reeglit puudutate, sest suurem osa segadusest selles valdkonnas tuleb sellest, et üht nimetatakse ja teist seadistatakse.
Leidke, kus teie poliitika paketti tegelikult näeb
Vaste tuleb hinnata selles ahelas ja nimeruumis, kus pakett on veel kirjeldatud kujul. LAN-i sissepääsu külge kinnitatud reegel näeb sisemist paketti krüpteerimata, enne kui see tunnelile suunatakse. Kohapeal loodud liiklusele rakendatud reegel näeb pakette, mille lüüs ise loob, ja see ei hõlma automaatselt liiklust, mida lüüs ainult edastab. Kapseldatud väljund on jälle kolmas juhtum, mida tavaliselt käsitletakse tunnelit kandval liidesel, mitte LAN-i poolel.
Seepärast käitub sama konfiguratsioonilõik kahel platvormil erinevalt: kinnituspunktid erinevad ja tootja poliitikakonnake võib asuda enne või pärast krüpteerimissammu. Lugege paketi teekonda konkreetse toote puhul, selle asemel et eeldada järjekorda teise tootja diagrammi põhjal.
Kinnitage läbi räägitud transport
UDP-sse kapseldatud IPsec-i puhul asetab RFC 3948 ESP UDP sisse ja kasutab markerit, mis ei ole ESP, et hoida IKE jagatud pordil eristatav. Tavaline ESP on IP-protokoll, mitte TCP- või UDP-port, seega pordi numbri järgi kirjutatud tulemüürireegel ei sobi sellega üldse. See erinevus otsustab, kas teie WAN-poliitika vajab UDP-reeglit, protokollireeglit või mõlemat.
Läbiräägitud väärtused võidavad meenutatud väärtuste üle. Lugege seose praegused pordid ja aadressid seadmest, selle asemel et lisada TCP 4500 või vana tootja port igaks juhuks, mis püüab kinni mitteseotud liikluse ja peidab tegeliku klassifitseerimisprobleemi.
Kontrollige tagasiteed enne kohustumist
Edu väljuvas suunas tõestab pool projekti. Kaugklientide basseini poole tagasi liikuv pakett ei ole enam kliendi aadressi all nähtav, kui kapseldus selle asendab: välimine sihtkoht on partneri transpordiaadress. Kui teine üleslink jõuab selle partnerini teise sideoperaatori kaudu, võivad selle tõlge ja filtreerimine esimesega lahkneda, ja seost võib olla vaja pigem uuesti üles ehitada kui migreerida.
Võrguaadresside tõlke olek on WAN-i vahetuse tavaline ohver. Kirjutage üles valitud üleslink, oodatav välimine lähteaadress, kasutatav tõlge ja partneri kättesaadavus sinna tagasi, seejärel hoidke transport kättesaadav, ilma et saadaksite selle tunnelisse, mida see kannab.
Kontrollige mõlemat kihti kahe salvestusega
Üks salvestus WAN-liidesel ja üks tunneli sees lahendavad küsimuse kiiremini kui ükski konfiguratsioonivõrdlus. Käivitage need lüüsilt, kui heakskiidetud klient teeb ühe päringu, ja hoidke mõlemad failid alles.
sudo tcpdump -ni wan1 'udp port 4500' -c 20
sudo tcpdump -ni tun0 'tcp port 443 and host 203.0.113.10' -c 20
ip route get 203.0.113.10 from 10.8.0.6
Esimene salvestus peaks näitama välimist vestlust lahkumas liideselt, mida kavatsesite, oodatava lähteaadressiga. Teine peaks näitama sisemist vestlust üks kord, mitte dubleeritult, kliendi aadressiga allikana ja rakendusserveriga sihtkohana. Marsruudi otsing kinnitab, millist tabelit ruuter selle allika ja sihtkoha paari jaoks kasutaks, ja just seal tuleb poliitikaviga tavaliselt välja. Kui kumbki salvestus ei ilmu, on otsustuspunkt mujal kui see, kuhu reegel kinnitati, ja parandus kuulub sinna, mitte laiemasse vastesse.