Kurį paketą turi atitikti dviejų WAN VPN politika?

Prašymai maršrutizuoti VPN per antrąją uplink liniją apibūdina bent dvi skirtingas užduotis, ir vieną sutvarkanti politika neliečia kitos. Pirmoje užduotyje šifruotas transportas tarp dviejų galinių taškų persikelia į kitą WAN adresą. Antroje prisijungusio naudotojo iššifruotas programos srautas išeina kito kito šuolio link. Abi yra teisėtos, abi naudoja maršrutizavimą, ir kiekvienai reikia atitikmens paketui, kuris egzistuoja tame taške, kuriame priimamas sprendimas. Atlikite žemiau nurodytus patikrinimus iš eilės, nes pirmasis nustato, kurį paketą turi įvardyti vėlesnės taisyklės.

Įvardykite du pokalbius

Įsivaizduokite nuotolinį darbuotoją, prisijungusį prie biuro tarpinės, kuris atidaro HTTPS į vidinį programos serverį. Laide yra du nepriklausomi pokalbiai, ir jie abiejuose galuose turi skirtingus adresus. Išorinis pokalbis vyksta tarp dviejų VPN galinių taškų: nuo tarpinės adreso iki partnerio adreso, tuo protokolu ir prievadu, dėl kurių susitarė diegimas. Vidinis pokalbis vyksta nuo klientui suteikto adreso iki programos serverio adreso 443 prievade.

Programos paskirties prievadas nėra VPN transporto prievadas, ir jokia politika per TCP 443 nepajudins tunelio. Taip pat taisyklė, peradresuojanti partnerio transporto adresą, nieko nesako apie tai, kur po iššifravimo nueina to naudotojo HTTP užklausa. Užrašykite abu pokalbius su jų tikraisiais adresais prieš liesdami taisyklę, nes didžioji dalis painiavos šioje srityje kyla iš to, kad vienas įvardijamas, o kitas konfigūruojamas.

Raskite, kur jūsų politika iš tikrųjų mato paketą

Atitikmuo turi būti vertinamas toje grandinėje ir vardų srityje, kur paketas dar yra jūsų aprašytos formos. Taisyklė, prikabinta prie LAN įėjimo, mato vidinį paketą nešifruotą, prieš jam nukreipiant į tunelį. Taisyklė, taikoma vietoje sugeneruotam srautui, mato paketus, kuriuos sukuria pati tarpinė, ir ji automatiškai neapima srauto, kurį tarpinė tik persiunčia. Inkapsuliuota išeiga yra dar trečias atvejis, paprastai tvarkomas sąsajoje, kuri neša tunelį, o ne LAN pusėje.

Štai kodėl ta pati konfigūracijos ištrauka dviejose platformose elgiasi skirtingai: tvirtinimo taškai skiriasi, o tiekėjo politikos kablys gali būti prieš šifravimo žingsnį arba po jo. Skaitykite paketo kelią konkrečiam produktui, o ne spėkite tvarką iš kito tiekėjo diagramos.

Patvirtinkite transportą, dėl kurio susitarėte

UDP inkapsuliuotam IPsec, RFC 3948 įdeda ESP į UDP ir naudoja ne ESP žymę, kad IKE liktų atskiriamas bendrame prievade. Paprastas ESP yra IP protokolas, o ne TCP ar UDP prievadas, todėl ugniasienės taisyklė, parašyta pagal prievado numerį, jo visiškai neatitiks. Šis skirtumas nulemia, ar jūsų WAN politikai reikia UDP taisyklės, protokolo taisyklės, ar abiejų.

Susitarti vertės nugali prisimintas. Skaitykite dabartinius asociacijos prievadus ir adresus iš įrenginio, o ne pridėkite TCP 4500 ar seną tiekėjo prievadą dėl visa ko, nes tai pagauna nesusijusį srautą ir paslepia tikrąją klasifikavimo problemą.

Patikrinkite grįžimo kelią prieš įsipareigodami

Sėkmė išorinėje kryptimi įrodo pusę projekto. Paketas, grįžtantis link nuotolinių klientų baseino, nebėra matomas po kliento adresu, kai inkapsuliavimas jį pakeičia: išorinė paskirtis yra partnerio transporto adresas. Jei antroji uplink linija pasiekia tą partnerį per kitą operatorių, jos vertimas ir filtravimas gali nesutapti su pirmąja, ir asociaciją gali tekti perstatyti, o ne perkelti.

Tinklo adresų vertimo būsena yra įprasta WAN pakeitimo auka. Užrašykite pasirinktą uplink liniją, laukiamą išorinį šaltinio adresą, naudojamą vertimą ir partnerio pasiekiamumą atgal į jį, tada palaikykite transportą pasiekiamą nesiųsdami jo į tunelį, kurį jis neša.

Patikrinkite abu sluoksnius dviem įrašais

Vienas įrašas WAN sąsajoje ir vienas tunelio viduje išsprendžia klausimą greičiau nei bet koks konfigūracijų palyginimas. Paleiskite juos iš tarpinės, kol patvirtintas klientas atlieka vieną užklausą, ir išsaugokite abu failus.

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

Pirmasis įrašas turėtų rodyti išorinį pokalbį paliekant sąsają, kurią turėjote omenyje, su laukiamu šaltinio adresu. Antrasis turėtų parodyti vidinį pokalbį vieną kartą, be dubliavimo, su kliento adresu kaip šaltiniu ir programos serveriu kaip paskirtimi. Maršruto paieška patvirtina, kurią lentelę maršrutizatorius naudotų tai šaltinio ir paskirties porai, ir būtent ten paprastai pasirodo politikos klaida. Jei kuris nors įrašas nepasirodo, sprendimo taškas yra kitur, o ne ten, prie ko buvo prikabinta taisyklė, ir pataisymas priklauso ten, o ne platesniam atitikmeniui.