VPN klients LAN serverī: kāpēc atbildes iziet nepareizajā ceļā

Simptomi seko vienam modelim: resursdators strādā, pēc tam tas kā klients pieslēdzas VPN, un tagad LAN klienti to sasniedz, kamēr tā atbildes pazūd. Uz resursdatora veikts ieraksts parāda, ka atbildes iziet caur tuneļa ierīci, nevis caur LAN saskarni. Tunelī nekas nav salūzis, un labojums ir maršruts, nevis atkārtota pievienošanās. Veiciet četras pārbaudes zemāk pēc kārtas un apstājieties pie pirmās, kas neizdodas.

Atbilde ir jauns pakets, nevis ceļa apgriešana

Palīdz atteikties no domas, ka atbilde atgriežas pa to pašu ceļu, pa kuru gāja pieprasījums. Maršrutēšana tiek izlemta katram paketam un katram virzienam uz sūtošā resursdatora. Pieprasījums, kas ienāca no 10.64.0.23 tuneļa iekšienē, neveido atgriešanās ceļu; kad resursdators atbild, šī atbilde tiek salīdzināta ar tabulu kā jauns pakets un iziet pa maršrutu, kas uzvar.

Tāpēc pilna tuneļa klients mašīnā, kas apkalpo arī LAN, rada tik mulsinošu kļūmi. Klients instalē noklusējuma maršrutu vai divus pusnoklusējuma maršrutus, ko dod priekšroku daži klienti, un atbilde LAN klientam tagad atbilst tunelim. Tā dodas pie pakalpojumu sniedzēja, kuram nav pamata to pārsūtīt, un LAN klients redz taimautu, lai gan resursdators darbojas un atbild lokāli. Ieraksts to padara acīmredzamu, un maršrutēšanas tabula to izskaidro.

Lasot pārējo, paturiet prātā divus apakštīklus. Viens ir VPN adrešu pūls, no kura nāk attālinātie klienti, šajā piemērā 10.64.0.0/24. Otrs ir LAN, kam jāturpina strādāt, 172.16.24.0/24 ar tā maršrutētāju 172.16.24.1. Kļūda ir tā, ka satiksmi starp tiem izlemj noklusējuma maršruts.

Pierādiet to ar ierakstu un vaicājumu

Pirms kaut ko mainīt, apstipriniet, kuru ierīci izmantos atbilde. Vaicājums ir ātrāks par ierakstu un atbild uz tieši to pašu jautājumu, uz kuru atbildēs kodols, kad pakets tiks būvēts.

ip route get 10.64.0.23 from 172.16.24.10
tcpdump -ni any -c 6 icmp

Lasiet atbildi divās daļās. Ja tajā norādīts dev tun0, resursdators iekapsulēs atbildi un nodos to pakalpojumu sniedzējam, un LAN klients to nekad neredzēs. Ja norādīts dev eth0, bet klients joprojām saņem taimautu, maršruts jau ir pareizs un pakets tiek izmests vēlāk, kas ir cita problēma ar citu labojumu.

Tā paša soļa ieraksts atrisina šaubas, ko ping nevar. LAN klientu sasniedzošā atbalss atbilde pierāda, ka kāds ceļš strādā, nevis kura saskarne to nesa, tāpēc veiciet ierakstu pašā resursdatorā un vērojiet, no kurienes iziet kadri. Tā paša apakštīkla printeris turpina atbildēt, jo tā tiešais maršruts ir konkrētāks par tuneļa noklusējuma maršrutu. Pārsūtītais ports neizdodas tieši tāpat kā jebkura cita plūsma, jo saskarni izvēlas tabula, nevis savienojums.

Instalējiet šaurāko maršrutu, kas pārspēj tuneli

Izšķir prefiksa garums, nevis metrika, tāpēc klientu pūla maršruts caur LAN maršrutētāju uzvar jebkuru noklusējuma maršrutu, ko instalē VPN klients. Metrikas ķirurģija nav vajadzīga, un noklusējuma maršruts var palikt tieši tur, kur klients to ievietoja.

ip route replace 10.64.0.0/24 via 172.16.24.1 dev eth0
ip route get 10.64.0.23 from 172.16.24.10

Izmantojiet replace, nevis add, jo klients, kas pievienosies atkārtoti, jau būs instalējis savu ierakstu, un otrais add neizdodas ar kļūdu par esošu maršrutu, kas lasās kā atļauju problēma. Windows resursdatorā ekvivalents ir route add 10.64.0.0 mask 255.255.255.0 172.16.24.1 -p, kur -p saglabā ierakstu starp pārstartēšanām, jo klients var pārbūvēt tabulu, kad tunelis atkal paceļas. Mūsdienu Windows resursdatorā atbalstītais ekvivalents ir New-NetRoute -DestinationPrefix 10.64.0.0/24 -NextHop 172.16.24.1 -InterfaceAlias Ethernet -PolicyStore PersistentStore, un vecākā route komanda tiek saglabāta kā mantota forma.

Viena detaļa izšķir, vai tas ir pareizi vai tikai ticami: nākamajam lēcienam jābūt maršrutētājam, kas patiešām pārvalda ceļu atpakaļ pie klientiem. Maršruta vēršana uz adresi, kas pati sasniedzama caur tuneli, rada cilpu, kas izpaužas kā periodisks zudums, nevis tīra kļūme. Pirms apstiprināt rindu, pārliecinieties, ka nākamais lēciens ir LAN apakštīklā.

Saglabājiet atbildi pēc atkārtotas pievienošanās

Ar roku pievienots maršruts labākajā gadījumā saglabājas līdz nākamajai atkārtotajai pievienošanās reizei. Ja klientu pūls ir dinamisks, piespraudiet to servera konfigurācijā, lai prefikss, ko maršrutējāt, paliktu prefikss, ko saņem klienti; pretējā gadījumā ieraksts norāda uz tukšu diapazonu un simptoms atgriežas pēc nedēļām bez acīmredzama iemesla. Maršruta ierakstīšana paša klienta up skriptā ir otra uzticamā iespēja, jo tas tiek izpildīts pēc tam, kad klients ir pārrakstījis tabulu.

Stāvokļa ugunsmūris joprojām var uzvarēt pareizu maršrutu. Ja ieraksts tagad rāda, ka atbilde iziet caur eth0, un klients joprojām saņem taimautu, pārbaudiet, vai resursdators neizmet paketu pirms nosūtīšanas. Stingra apgrieztā ceļa filtrēšana un net.ipv4.conf.all.rp_filter, kas iestatīts uz 1, izmet paketus, kuru avots netiktu maršrutēts atpakaļ pa saskarni, pa kuru tie ienāca, un tas ir tieši tas asimetriskais gadījums, ko tikko izveidojāt un pēc tam izlabojāt, un conntrack stāvoklis stāsta to pašu stāstu pārsūtītajiem portiem.

Pēdējā pārbaude ir tā, ko cilvēki izlaiž: atkārtojiet vaicājumu pēc tam, kad tunelis ir bijis lejā un atkal augšā. Četrām vērtībām jāatbilst tam, ko pierakstījāt: galamērķis, nākamais lēciens, ierīce un izvēlētais avots. Ja kāda no tām ir pārvietojusies, klients ir pārrakstījis tabulu un labojums pieder tā āķiem, nevis shell vēsturei.