Vietņu VPN atbilde neiet caur tuneli

Pavadīju rītu pie tuneļa, kas pacēlās tīri un pārvietoja datplūsmu tieši vienā virzienā: filiāle sasniedza galvenā biroja failu serveri, un katrs savienojums, kas tika atvērts no galvenā biroja uz filiāli, nomira pie pirmā SYN. SA bija aktīvi, tuneļa skaitītāji auga, un rokas spiediens nekad nebija problēma. Atbilde tika maršrutēta kaut kur, ko tunelis neaptver, un šī izvēle pieder tālajai pusei. Vietņu VPN pārvadā tikai tās paketes, ko resursdators nodod vārtejai, un katrs resursdators šo izvēli izdara atsevišķi, katrā virzienā, no savas maršrutēšanas tabulas.

Abi virzieni tiek maršrutēti atsevišķi

IP neatur atmiņā sarunas virzienu. Katrs resursdators, kas sūta paketi, veic savu garākā prefiksa meklēšanu, izvēlas vienu nākamo lēcienu un aizmirst lēmumu. Pieprasījums un atbilde ir divas nesaistītas paketes, kas nejauši pieder vienam savienojumam, un tunelis ir viens lēciens, ko jebkura no tām var izmantot vai neizmantot. Nekas IKE apmaiņā nemāca tālajam serverim, kā sasniegt jūsu apakštīklu; sarunas vienojas tikai par to, kurus prefiksus drīkst šifrēt.

Šī vienošanās ir otrie vārti. strongSwan datplūsmas selektori ir leftsubnet un rightsubnet, un pakete, kuras avots vai galamērķis atrodas ārpus saskaņotā pāra, netiek šifrēta, lai ko teiktu maršrutēšanas tabula. Prefikss, kas tiek maršrutēts tunelī, bet trūkst selektoros, ir klusa vienvirziena kļūda: maršruts izskatās pareizs, pakete joprojām iziet atklāti vai tiek izmesta, un tikai charon žurnāls sūdzas.

Tālais resursdators neko nezina par jūsu tuneli

Tālajā LAN atbilde ir parasta pakete, kas adresēta jūsu klientam. Galamērķa resursdators neredz nevienu IPsec galveni un tam nav iemesla dot priekšroku VPN vārtejai; tas meklē jūsu prefiksu, neatrod neko konkrētāku par savu noklusējuma maršrutu un seko tam. Ja noklusējums norāda uz kodola ugunsmūri, ugunsmūrim vai nu ir maršruts atpakaļ tunelī, vai nav. Ja nav, jūs saņemat klusu nomešanu, ICMP unreachable vai atbildi, kas iziet pa interneta puses saskarni un mirst.

Otra saskarne ir pietiekama, lai to salauztu arī tad, kad maršruts pastāv. NAS ar pārvaldības saiti citā VLAN, serveris ar rezerves uplink, politikas noteikums, kas vienu avota diapazonu sūta otrajā tabulā: jebkurš no šiem var notvert atbildi. Linux ip rule show un ip route show table all parāda noteikumus un tabulas, ko noklusējuma saraksts slēpj.

Lasiet lēmumu mašīnā, kas sūta atbildi

Pajautājiet kodolam, pirms kaut ko maināt, un dodiet tam avota adresi, jo no avota atkarīgi noteikumi maina atbildi.

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

Izvade nosauc izejošo saskarni un nākamo lēcienu. Ja saskarne nav tā, kas vērsta uz VPN vārteju, jūs esat atradis defektu, un atlikušais darbs ir izvēlēties, kur maršrutam jāatrodas. Ping no vārtejas šeit maz ko pierāda: tas atbild ar adresi, ko tālais resursdators spēj novietot, nevis ar jūsu portatīvā datora adresi.

Windows ekvivalenti ir Find-NetRoute -RemoteIPAddress 10.10.5.10 lēmumam un Get-NetRoute tabulai. Maršruts, kas pievienots ar New-NetRoute un kam ir augstāks metrikas rādītājs nekā noklusējumam, klusi zaudē, tāpēc lasiet metrikas kolonnu, nevis ierakstu. Pēc tam pārbaudiet ar paketēm: tcpdump -ni any "host 10.10.5.10 and tcp port 445" tālajā LAN saskarnē parāda pieprasījumu, un tas pats filtrs tuneļa pusē parāda, vai atbilde atgriezās. Pieprasījums redzams bez atbildes nozīmē, ka atbilde tika maršrutēta citur vai nomesta; atbilde nepareizajā saskarnē dod jums vainīgo, pirms pieskaraties maršrutam.

Kad servera vārteja nav VPN galapunkts

Daudzas vietas liek ugunsmūri starp serveriem un koncentratoru. Šis ugunsmūris pārsūta atbildi, tāpēc tam vajag maršrutu jūsu klienta prefiksam uz VPN vārteju un pārsūtīšanas politiku abos virzienos. Stāvokli glabājošas ierīces to pasliktina: pieprasījums šķērsoja ugunsmūri no LAN resursdatora, ko tas atļāva, atbilde tagad nāk no cita virziena, un savienojuma izsekošanas ieraksts vairs neatbilst, tāpēc pakete tiek izmesta kā nederīga, nevis noraidīta. Tāpēc politikas žurnāls izskatās tukšs, kamēr datplūsma pazūd.

Vārtejai ir savs otrais filtrs. Linux apgrieztā ceļa filtrēšana izmet paketes, kuru avots nav sasniedzams pa to saskarni, pa kuru tās ieradās, un tā ir tieši likumīga asimetriska atgriešanās ceļa forma. strongSwan pārsūtīšanas rokasgrāmata tieši tāpēc prasa net.ipv4.ip_forward un atslābinātu net.ipv4.conf.all.rp_filter. Stingra vērtība 1 jebkurā no vārtejām klusi salauž pareizu maršrutu, un nstat -az parāda nomešanas, ja zināt, kur skatīties.

Maršrutējiet vai tulkojiet, pēc tam pārbaudiet abos virzienos

Divi labojumi nav līdzvērtīgi. Maršruta pievienošana saglabā klienta adresi neskartu, tāpēc uz avotu balstīti noteikumi, audita žurnāli un lietojumprogrammas, kas reģistrē zvanītāju, turpina darboties; cena ir tā, ka katram lēmumu pieņemošajam lēcienam vajag maršrutu, kas ir vairāk vietu, kur kļūdīties. Maskēšana tālajā vārtejā sarauj atgriešanās ceļu līdz vienam lēcienam, jo atbilde tagad ir adresēta pašai vārtejai, un slēpj, kurš klients ko izdarīja.

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

Izvēlieties to apzināti: tiklīdz klienti parādās kā vārtejas adrese, uz avotu balstīti ACL vairs nespēj tos atšķirt, un conntrack ir jāsaglabā kartējums, lai atbilde tiktu pārrakstīta atpakaļ tunelī. Ja selektori joprojām izslēdz klienta prefiksu, NAT neko nemaina, jo pieprasījums nekad nav iegājis tunelī.

Pirms pasludināt to salabotu, pēc kārtas apstipriniet četras lietas: maršrutu resursdatorā, kas sūta atbildi, maršrutu katrā to pārsūtošajā lēcienā, selektorus, kas aptver abus prefiksus, un ierakstu, kas rāda atbildi ieejam tunelī ar gaidīto avotu. Tad atkārtojiet testu no otras vietas. Viena virziena iziešana ir pusatvērts projekts, un otrais virziens parasti neizdodas cita iemesla dēļ, nevis tā, ko tikko salabojāt.