Maršrutēšanas tabula pret faktisko meklēšanu: kur aiziet VPN trafiks

Maršrutēšanas tabulas izdruka ir vismazāk noderīgā VPN problēmu diagnostika un visbiežāk ielīmētā. Četrdesmit rindas ar prefiksiem jums saka, ko iekārta varētu darīt, nevis ko tā darīja neizdevušajam pieprasījumam. Mehānisms, ko jūs patiešām vēlaties, ir meklēšana: ņemot vērā šo avotu un šo galamērķi, kurš noteikums atbilda, kura tabula tika konsultēta un kura saskarne un nākamais lēciens iznāca. Sāciet ar vienu galamērķi un vienu avotu, pēc tam lasiet tabulu ar šo jautājumu rokā, un tā pati izvade kļūst par pierādījumu trokšņa vietā.

Tabula ir kandidātu kopa, nevis lēmums

Katrs ieraksts apraksta prefiksu un to, ko darīt ar tam atbilstošo trafiku: sūtīt uz saskarni, nodot nākamajam lēcienam vai nomest. Nekas tajā sarakstā nav sakārtots pēc nodoma, un ieraksts, kas cilvēkam šķiet visspecifiskākais, ne vienmēr ir tas, ko izvēlas kodols, jo izvēle seko garākajai prefiksa atbilstībai un, starp vienādiem prefiksiem, metrikai.

Tāpēc pirmais solis ir jautāt kodolam, nevis lasīt sarakstu. Meklēšanas komanda atbild galamērķim, un ar avota argumentu tā atbild precīzajam pārim, ko izmantotu pārsūtīts vai piesaistīts savienojums:

ip route get 198.51.100.10
ip route get 198.51.100.10 from 10.80.0.25
ip -6 route get 2001:db8:10::40

Katra iepriekš minētā adrese ir dokumentācijas piemērs. Būtība ir atbildes forma: saskarne, izvēlētā avota adrese, vārteja un tabula, no kuras nāca ieraksts. Ja šī izvade neatbilst gaidītajai saskarnei, jūs vienā komandā lokalizējāt problēmu, un nekāds pilnas tabulas lasījums nebūtu pateicis, kurš kandidāts uzvarēja.

Meklēšana iet caur noteikumiem, pēc tam tabulām

Linux sistēmā lēmums ir divos posmos. Politikas noteikumi tiek novērtēti prioritātes secībā, un pirmais atbilstošais noteikums nosauc konsultējamo tabulu; šī tabula pēc tam veic garākā prefiksa atbilstību. Noteikums var atbilst pēc avota, galamērķa, ugunsmūra atzīmes, saskarnes vai to kombinācijas, tāpēc galvenās tabulas izdruka var būt pilnīgi precīza un pilnīgi nebūtiska izmeklējamajam paketam.

ip rule show
ip route show table all | head -40
ip route show table 100

Ja noteikums sūta trafiku no jūsu VPN pūla uz tabulu 100, tad svarīga ir tabula 100, un galvenā tabula ir ēsma. Tas ir arī avota balstītas maršrutēšanas mehānisms maršrutētājā: vienam un tam pašam galamērķim var būt divas dažādas atbildes atkarībā no tā, no kurienes nāca pakete, un tikai meklēšana ar avota argumentu atklāj, kura ir spēkā.

IPv6 ir savi noteikumi un tabulas. Dizainam, kas darbojas ar abām saimēm, vajadzīgas abas meklēšanas, un strādājoša IPv4 atbilde neko nepasaka par v6 ceļu, kuram divu steku klients var dot priekšroku.

Ko instalē VPN klients

Klienti parasti neaizstāj noklusējuma maršrutu, jo tas salauztu paša tuneļa ārējo ceļu. Viņi instalē kaut ko konkrētāku, kas uzvar pēc prefiksa garuma: pāris pusnoklusējuma maršrutu, kas aptver 0.0.0.0/1 un 128.0.0.0/1, ir klasiskais triks, jo abi ir garāki prefiksi nekā 0.0.0.0/0 un kopā aptver visu telpu. Citi instalē konkrētus privātos prefiksus plus politikas noteikumu, un daži pievieno atzīmi, lai tiktu uztverts tikai izvēlētais trafiks.

Tāpēc "VPN nemainīja manu noklusējuma maršrutu" nav neveiksmes pierādījums. Pārbaudiet, ko tas tomēr pievienoja, un vai attiecīgais galamērķis ietilpst šajos prefiksos:

ip route show | grep -E 'tun|wg|ppp|ipsec'
ip route get 10.20.30.40 from 10.80.0.25

Divus pusmaršrutus ir viegli palaist garām izdrukā, jo tie neizskatās kā noklusējuma maršruts. Split-tunnel konfigurācija, kas aizmirsa iekļaut prefiksu, rada tieši to simptomu, ko jūs vajājat: lietotne, kurai vajadzētu izmantot tuneli, tā vietā atrisina un savienojas lokāli. Salīdziniet instalētos prefiksus ar galamērķiem, kas lietotājam patiešām nepieciešami, nevis ar adresēm, ko nejauši pārbaudījāt. Split-tunnel saraksts, kas aptver failu serveri, bet ne tā atrisinātāju, rada savienojumu, kas tiek atrisināts uz publisku adresi un pēc tam neiztur autentifikāciju, kas izskatās pēc paroles problēmas un ir maršruta problēma.

Ārējam maršrutam arī jāizdzīvo

Tunelis pats ir trafiks. Paketes, kas pārvadā iekapsulēto kravu, dodas uz partnera adresi pa fizisko saskarni, un šo ceļu nedrīkst maršrutēt atpakaļ tunelī. Kad tas notiek, jūs iegūstat raksturīgo atteici, kad tunelis tiek izveidots un pēc tam pārstāj laist cauri trafiku, jo tuneļa transports tagad atrodas tuneļa iekšpusē.

Pārbaudiet partnera adresi tāpat, kā pārbaudījāt iekšējo galamērķi, un apstipriniet, ka tā tiek atrisināta uz fizisko saskarni, nevis uz tuneli:

ip route get 203.0.113.10
traceroute -n -m 5 203.0.113.10

Rekursīvs maršruts, politikas noteikums, kas noķer partneri, vai noklusējuma maršruts, ko aizstājis pilna tuneļa klients, ir trīs ierastie cēloņi. Visi trīs ir redzami ārējā meklēšanā, un neviens nav redzams galvenās tabulas izdrukā, kas uzņemta pēc fakta.

Ko maršrutēšanas izvade nevar pateikt

Pareiza meklēšana nozīmē, ka kodols nosūtītu paketi uz saprātīgu vietu. Tas nenozīmē, ka ugunsmūris to atļauj, IPsec politika to aptver, NAT noteikums to pārtulko vai attālajā pusē ir atgriešanās maršruts. Katrs no tiem ir vēlāks posms, un strongSwan pārsūtīšanas piezīmes apraksta ķēdi, kas paketei jāiziet abos galos.

Tas arī neņem vērā piesaisti lietotnes līmenī. Process var piesaistīties saskarnei, iestatīt atzīmi vai izmantot savu atrisinātāju un savienoties ar vārdu, kas tiek atrisināts citādi nekā jūs pārbaudījāt. Kad meklēšana ir pareiza un savienojums joprojām neizdodas, nākamais jautājums ir, kurš process to veic un vai tas process redz to pašu tabulu, ko jūs.

Tāpēc turiet diagnostiku sakārtotu: nosauciet galamērķi un avotu, palaidiet meklēšanu, lasiet tikai to tabulu un noteikumu, ko nosauca meklēšana, pēc tam pārbaudiet nākamo posmu. Šī secība notur maršrutēšanas izmeklēšanu dažu minūšu robežās un atstāj ierakstu, kam kāds cits var sekot, ko ielīmēta tabula nekad neizdara.