Svetainės-svetainės VPN atsakymas neina per tunelį

Rytą praleidau prie tunelio, kuris pakilo švariai ir siuntė srautą tiksliai viena kryptimi: filialas pasiekdavo pagrindinės būstinės failų serverį, o kiekvienas ryšys, atidarytas iš būstinės į filialą, mirdavo prie pirmojo SYN. SA buvo aktyvūs, tunelio skaitikliai kilo, o rankos paspaudimas niekada nebuvo problema. Atsakymas buvo maršrutizuojamas kažkur, ko tunelis neapima, ir tas pasirinkimas priklauso tolimajai pusei. Svetainės-svetainės VPN perduoda tik tuos paketus, kuriuos mazgas perduoda tinklų sietuvui, ir kiekvienas mazgas tą pasirinkimą daro atskirai, kiekviena kryptimi, iš savo maršrutizavimo lentelės.

Abi kryptys maršrutizuojamos atskirai

IP neatsimena pokalbio krypties. Kiekvienas mazgas, siunčiantis paketą, atlieka savo ilgiausio priešdėlio paiešką, pasirenka vieną kitą šuolį ir pamiršta sprendimą. Užklausa ir atsakymas yra du nesusiję paketai, kurie atsitiktinai priklauso tai pačiai jungčiai, o tunelis yra vienas šuolis, kurį bet kuris iš jų gali naudoti arba ne. Niekas IKE apsikeitime nemoko tolimojo serverio, kaip pasiekti jūsų potinklį; derybos tik susitaria, kuriuos priešdėlius galima šifruoti.

Tas susitarimas yra antrieji vartai. strongSwan srauto parinkikliai yra leftsubnet ir rightsubnet, o paketas, kurio šaltinis ar paskirtis patenka už suderintos poros, nėra šifruojamas, ką bedarytų maršrutizavimo lentelė. Priešdėlis, kuris maršrutizuojamas į tunelį, bet jo nėra parinkikliuose, yra tyli vienpusė klaida: maršrutas atrodo teisingas, paketas vis tiek išeina atviru arba numetamas, ir tik charon žurnalas skundžiasi.

Tolimasis mazgas nieko nežino apie jūsų tunelį

Tolimajame LAN atsakymas yra paprastas paketas, adresuotas jūsų klientui. Paskirties mazgas nemato jokios IPsec antraštės ir neturi pagrindo teikti pirmenybę VPN sietuvui; jis ieško jūsų priešdėlio, neranda nieko konkretesnio už savo numatytąjį maršrutą ir juo eina. Jei numatytasis nurodo pagrindinę užkardą, ta užkarda arba turi maršrutą atgal į tunelį, arba ne. Kai neturi, gaunate tylų numetimą, ICMP unreachable arba atsakymą, kuris išeina pro interneto pusės sąsają ir miršta.

Antrosios sąsajos pakanka tai sugriauti net kai maršrutas egzistuoja. NAS su valdymo ryšiu kitame VLAN, serveris su atsarginiu uplink, politikos taisyklė, siunčianti vieną šaltinio intervalą į antrą lentelę: bet kuris iš jų gali pagauti atsakymą. Linux ip rule show ir ip route show table all rodo taisykles ir lenteles, kurias numatytasis sąrašas slepia.

Skaitykite sprendimą mašinoje, kuri siunčia atsakymą

Paklauskite branduolio prieš ką nors keisdami ir duokite jam šaltinio adresą, nes nuo šaltinio priklausančios taisyklės pakeičia atsakymą.

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 )"

Išvestis nurodo išeinančią sąsają ir kitą šuolį. Jei sąsaja ne ta, kuri žiūri į VPN sietuvą, radote defektą, o likęs darbas yra pasirinkti, kur maršrutas turi būti. Ping iš sietuvo čia mažai ką įrodo: jis atsako adresu, kurį tolimasis mazgas gali įdėti į lentelę, o ne jūsų nešiojamojo kompiuterio adresu.

Windows ekvivalentai yra Find-NetRoute -RemoteIPAddress 10.10.5.10 sprendimui ir Get-NetRoute lentelei. Maršrutas, pridėtas su New-NetRoute ir turintis didesnį metrikos rodiklį nei numatytasis, tyliai pralaimi, todėl skaitykite metrikos stulpelį, o ne įrašą. Tada patvirtinkite paketais: tcpdump -ni any "host 10.10.5.10 and tcp port 445" tolimojoje LAN sąsajoje parodo užklausą, o tas pats filtras tunelio pusėje parodo, ar grįžo atsakymas. Užklausa matoma be atsakymo reiškia, kad atsakymas buvo maršrutizuotas kitur arba numestas; atsakymas ne toje sąsajoje duoda jums kaltininką prieš paliečiant maršrutą.

Kai serverio sietuvas nėra VPN galinis taškas

Daugybė vietų deda užkardą tarp serverių ir koncentratoriaus. Ta užkarda persiunčia atsakymą, todėl jai reikia maršruto jūsų kliento priešdėliui į VPN sietuvą ir persiuntimo politikos abiem kryptimis. Būseną saugantys įrenginiai tai blogina: užklausa perėjo užkardą iš LAN mazgo, kurį ji leido, atsakymas dabar ateina iš kitos krypties, o jungties sekimo įrašas nebeatitinka, todėl paketas išmetamas kaip negaliojantis, o ne atmetamas. Štai kodėl politikos žurnalas atrodo tuščias, kol srautas dingsta.

Sietuvas turi savo antrą filtrą. Linux atvirkštinio kelio filtravimas numeta paketus, kurių šaltinis nepasiekiamas per sąsają, kuria jie atėjo, ir tai yra tiksliai teisėto asimetrinio grįžimo kelio forma. strongSwan persiuntimo vadovas būtent dėl to reikalauja net.ipv4.ip_forward ir atlaisvinto net.ipv4.conf.all.rp_filter. Griežta reikšmė 1 bet kuriame sietuve tyliai sugriauna teisingą maršrutą, o nstat -az parodo numetimus, jei žinote, kur žiūrėti.

Maršrutizuokite arba išverskite, tada patikrinkite abiem kryptimis

Du taisymai nėra lygiaverčiai. Maršruto pridėjimas palieka kliento adresą nepaliestą, todėl šaltiniu pagrįstos taisyklės, audito žurnalai ir programos, fiksuojančios skambintoją, toliau veikia; kaina yra tai, kad kiekvienam sprendimą priimančiam šuoliui reikia maršruto, o tai daugiau vietų suklysti. Maskavimas tolimajame sietuve sutraukia grįžimo kelią į vieną šuolį, nes atsakymas dabar adresuotas pačiam sietuvui, ir paslepia, kuris klientas ką padarė.

iptables -t nat -A POSTROUTING -o eth1 -s 10.20.30.0/24 -j MASQUERADE

Rinkitės sąmoningai: kai klientai pradeda rodytis kaip sietuvo adresas, šaltiniu pagrįsti ACL nebesuskirsto jų, o conntrack turi išlaikyti atitikimą, kad atsakymas būtų perrašytas atgal į tunelį. Jei parinkikliai vis dar neįtraukia kliento priešdėlio, NAT nieko nekeičia, nes užklausa niekada nepateko į tunelį.

Prieš skelbdami tai sutvarkytu, patvirtinkite keturis dalykus iš eilės: maršrutą mazge, kuris siunčia atsakymą, maršrutą kiekviename jį persiunčiančiame šuolyje, parinkiklius, apimančius abu priešdėlius, ir įrašą, rodantį atsakymą įeinant į tunelį su tuo šaltiniu, kurio tikitės. Tada pakartokite bandymą iš kitos vietos. Vienos krypties veikimas yra pusiau atviras projektas, o antroji kryptis paprastai žlunga dėl kitos priežasties nei ta, kurią ką tik sutvarkėte.