Maršrutēts VPN klients sasniedz serveri, bet ne LAN resursdatorus

Tunelis paceļas, klients pingē VPN serveri, un koplietotā mape mašīnā vienu lēcienu tālāk nekad neatbild. Nekas klienta konfigurācijā to neizskaidro, jo pieprasījums tiešām atstāja klientu un tiešām ieradās. Neizdevās atgriešanās ceļš, un neizdevusies ierīce parasti ir LAN vārteja, nevis VPN resursdators. Atbildes paketes izsekošana izskaidro visu šo simptomu klasi.

Sekojiet atbildei, nevis pieprasījumam

VPN serveris atšifrē klienta paketi un pārsūta to uz LAN, atstājot klienta adresi avota laukā. Galamērķa resursdators atbild uz šo adresi, un tagad visu izšķir tā paša maršrutēšanas tabula. Tā noklusējuma vārteja neko nezina par tuneļa baseinu, tāpēc atbilde dodas interneta pakalpojumu sniedzēja virzienā un kaut kur šajā ceļā tiek izmesta.

Klientā simptoms ir kluss taimauts: nav atteikuma, nav atiestatīšanas, vienkārši nekas. Koplietotās mapes pārlūkošana iestājas, ping ziņo, ka atbildes nav, un servera žurnāli izskatās veseli, jo serveris izdarīja savu darbu.

Novietojiet atgriešanās maršrutu tur, kur skatās resursdatori

Katrs LAN resursdators konsultējas ar savu noklusējuma vārteju, tāpēc vārteja ir vienīgā ierīce, kurai jāzina, kur atrodas tuneļa baseins. Pievienojiet tur statisku maršrutu, un katrs resursdators manto pareizo ceļu, tam nepiekļūstot.

Ja vārteja izplata savu adresi kā DHCP opciju, izplatiet maršrutu tādā pašā veidā, lai jaunas mašīnas to uzņemtu automātiski. Citādi maršruts dzīvo vienā konfigurācijas failā un pazūd nākamajā pārbūvē.

# on the LAN gateway; tunnel pool 172.20.5.0/24, VPN server 10.60.4.10
ip route add 172.20.5.0/24 via 10.60.4.10
ip route get 172.20.5.14

Kāpēc šķiet, ka avota NAT to izlabo

Klientu baseina maskēšana aiz VPN servera adreses novērš problēmu, noņemot klienta adresi no paketes. Tad atbildes atgriežas serverī, kas jau zina, kā sasniegt tuneli, un viss darbojas. Cena ir tā, ka iekšējie resursdatori vairs neredz, kas ir klients, un katrs savienojums izskatās kā nākošs no vienas mašīnas.

Šī apmaiņa dažreiz ir pareiza, piemēram, kad piegādātāja ierīcei nevar piešķirt statisku maršrutu. Neveidojiet noteikumu platāku par pašreizējo baseinu, jo noteikums, kas rakstīts /24 tīklam, pārstāj atbilst tajā dienā, kad baseins tiek pārnumurēts uz /16, un pirmā pazīme ir jaunu klientu grupa, kas pieslēdzas un neko nesasniedz.

iptables -t nat -A POSTROUTING -s 172.20.5.0/24 -o ens18 -j MASQUERADE
iptables -t nat -L POSTROUTING -n -v

Mākoņa ceļam vajadzīgi trīs iestatījumi

VPC gadījumā tā pati nepilnība atgriežas citā formā, jo apakštīklam vispār nav maršruta klientu diapazonam. Maršrutēšanas tabulai vajag ierakstu tuneļa baseinam, kas vērsts uz instances tīkla saskarni, un saskarnē jābūt izslēgtai avota un galamērķa pārbaudei, lai platforma pieņemtu paketes, kuru avots nav tās pašas adrese. Drošības grupas un tīkla ACL arī jāpielaiž baseins abos virzienos.

Katra izlaišana rada atsevišķu daļēju kļūmi. Izlaidiet maršrutēšanas tabulas ierakstu, un privātās instances atbild apakštīklā, kas nespēj aiznest atbildi atpakaļ uz baseinu. Ja pārbaude joprojām ir ieslēgta, platforma izmet atbildi pēc tam, kad instance to jau nosūtījusi. Bez drošības grupas noteikuma pats pieprasījums nekad neierodas, un klients taimautu redz vienu slāni agrāk.

Veiciet pārbaudes šādā secībā

Pirms vainot maršrutēšanu, apstipriniet pāradresāciju un filtrēšanas politiku, jo resursdators, kas nepāradresēs, neizdodas tāpat klusi. Pēc tam nolasiet spēkā esošo atgriešanās ceļa iestatījumu saskarnē, kas pārvadā tuneli, jo stingrs filtrs var izmest atbildes, kas nāk no negaidīta virziena.

Pabeidziet ar uzņemtu ierakstu LAN resursdatorā, kamēr klients to pingē. Pieprasījums, kas ierodas bez atbilstošas atbildes, pierāda atgriešanās ceļu, un pieprasījums, kas nekad neierodas, vainu atgriež serverim vai tunelim.

sysctl net.ipv4.ip_forward net.ipv4.conf.all.rp_filter
tcpdump -ni any host 172.20.5.14 and icmp

Avota un galamērķa pārbaude ir dokumentēta elastīgās tīkla saskarnes rokasgrāmatā. Iestatiet to saskarnē, kas patiešām pārvadā tuneļa datplūsmu, nevis nesaistītā adapterī, kas pievienots tai pašai instancei.