Kāpēc pilna tuneļa maršruts nogriež serveri, kas to nēsā

Ieslēdziet pilnu tuneli, un tagad katrs galamērķis pieder VPN saskarnei, tostarp mašīna, kas to pabeidz. Ārējās paketes, kas nēsā tuneli, ir adresētas šai mašīnai, tāpēc maršruts galu galā patērē pārraidi, no kuras tas pats ir atkarīgs. Viens papildu konkrēts maršruts to atrisina, un iemeslu ir vērts saprast. Bez šī iemesla nākamā pārbūve atkal ieviesīs defektu.

Maršruts, kas apēd savu pārraidi

Iekapsulēšana ietin katru paketi otrā galvenē. Ārējā ir adresēta no vietējās fiziskās adreses uz servera publisko adresi, un tai jāšķērso fiziskā saite, pirms var pastāvēt jebkurš tunelis.

Tagad ļaujiet šīs publiskās adreses meklējumam izvēlēties tuneli. Lai nosūtītu paketi, mašīnai tā jāiekapsulē, kas prasa maršrutu uz to pašu adresi, un tas atgriež tuneli. Klienti to risina vienā no diviem veidiem. Uzmanīgais atsakās instalēt noklusējuma maršrutu un ziņo par kļūdu, bet mazāk uzmanīgais ziņo par panākumiem un pēc tam neko nepārvieto. Klusā neveiksme ir tā, kas izmaksā pēcpusdienu.

Garākā prefiksa atbilstība nosaka meklēšanu pirms jebkuras metrikas apskates, tāpēc vienas adreses maršruts pārspēj katru noklusējuma maršrutu mašīnā. Tas ir viss mehānisms aiz labojuma.

Instalējiet izņēmumu pirms noklusējuma

Izveidojiet vienas adreses maršrutu serverim ar fizisko vārteju kā nākamo lēcienu, pirms noklusējuma maršruts pārvietojas. Secība ir svarīga: instalēšana pēc tam nozīmē dzīvot ar salauztu tuneli, kamēr rakstāt.

Lielākā daļa klientu to dara bez lūguma. OpenVPN meklē attālo adresi un piesprauž to pirms noklusējuma vārtejas pārrakstīšanas, un tā opcija route-delay pastāv platformām, kur šī secība sacenšas. wg-quick iet pavisam citu ceļu, atzīmējot paketes un konsultējoties ar politikas noteikumu tā vietā, lai pievienotu izņēmumu. Dažādi mehānismi, viena prasība: ārējai paketei jāizbēg no tuneļa, ko tā rada.

ip route add 203.0.113.10/32 via 192.168.1.1 dev eth0
ip route get 203.0.113.10

Meklēšanas izvade ir pieņemšanas tests. Tai jānosauc fiziskā ierīce un fiziskais nākamais lēciens. Tuneļa ierīce šajā atbildē nozīmē, ka izņēmums trūkst vai tas ievietots pēc kaut kā, kas to pārspēj.

Spoguļattēls uz servera

Tie paši slazdi gaida otrā pusē, apgriezti. Dodiet serverim noklusējuma maršrutu caur citu tuneli vai iespiediet tam maršrutu, kas aptver klientu publiskās adreses, un tā atbildes iegūs nepareiza virziena ieradumu.

Iedomājieties klientu, kas pieslēdzas un nosūta pieprasījumu. Atbilde ir adresēta šī klienta publiskajai adresei, kas tagad atbilst tuneļa maršrutam, tāpēc tā iziet no citas saskarnes, nesot avotu, kuru klients nekad nav izvēlējies. Klients var saņemt šo paketi un tomēr to izmest, jo nekas to nesaista ar nosūtīto pieprasījumu. Sāciet no servera maršrutēšanas lēmuma, nevis no klienta taimauta, jo tikai viens no tiem parāda faktisko izvēli.

ip route get 198.51.100.44 from 10.90.0.1
ip rule show
sudo tcpdump -ni any host 198.51.100.44

Pastāv trīs labojumi, un tie nav vienlīdzīgi. Pakalpojuma piesaiste fiziskajai adresei vai avota tulkošana abi slēpj maršrutēšanas lēmumu, nevis to izlabo. Atbilžu trafika sūtīšana tuneļa pūlam caur īpašu tabulu izlabo cēloni, un pārējie divi ir pieņemami tikai tikmēr, kamēr maršrutēšanas dizains ir iesaldēts.

Izņēmumi, ko tunelis turpina zagt

Dažiem darbiem ir vajadzīgs atvērts internets pat tad, kad tunelim pieder noklusējuma maršruts, un katram vajadzīgs savs izņēmums. Dinamiskā DNS atjauninātājs parasti salūzt pirmais.

Tas atrisina pakalpojumu sniedzēju, atver savienojumu un atklāj, ka tā paša paketes ceļo pa tuneli, kura adrese mainījās pirms sekundēm, tāpēc atjauninājums neizdodas vai publicē nepareizo adresi. Trīs izejas: piespraudiet pakalpojumu sniedzēju ar resursdatora maršrutu caur fizisko vārteju, palaidiet atjauninājumu pirms tuneļa pacelšanas vai dodiet atjauninātājam politikas tabulu, kurai tunelis nekad nepieskaras. Laika sinhronizācijai ir tāda pati ietekme ierīcē, kas startē bez atrisinātāja, un sertifikātu validācijas galapunkti to pašu iemeslu dēļ ietilpst sarakstā.

Izņēmums, ko neviens nav pierakstījis, ir izņēmums, ko nākamā pārbūve klusi izmetīs.

Pierādiet to pēc atkārtotas savienošanas, nevis pirms tam

Pārbaudiet trīs galamērķus, nevis vienu: galapunktu, privāto adresi aiz tuneļa un publisko adresi aiz tā. Viens veiksmīgs meklējums gandrīz neko nepasaka par pārējiem diviem.

ip route get 203.0.113.10
traceroute -n 203.0.113.10
ip route get 10.90.0.5
ip route get 1.1.1.1

Pēc tam restartējiet savienojumu, jo klients, kas atkārtotas savienošanas laikā pārbūvē savu tabulu, izmetīs ar roku ierakstītu maršrutu. Ja darbojas kill switch, pārbaudiet, vai galapunkts ir atļauts, citādi tunelis pēc tīkla maiņas nevarēs atgriezties un simptoms izskatīsies kā pārtraukums. Glabājiet izņēmumu profilā vai unit failā, nevis shell vēsturē, lai atkārtota savienošana to atjaunotu, nevis izdzēstu.