Miks OpenVPN-i UDP-vastus lahkub valelt aadressilt

OpenVPN klient helistab ühele aadressile, server vastab teiselt ja tunnel ei tõuse kunagi. Serveri logi näitab paketi saabumist ja salvestis näitab vastuse lahkumist, seega pannakse viga kliendi süüks. Hostis, millel on mitu liidest või ühel liidesel mitu aadressi, ei ole kaks poolt lihtsalt ühel meelel, millist aadressi kasutatakse. Vastus on IP-kihis korrektne, kuid paljud kliendid viskavad kõrvale datagrammi, mille allikas ei ole aadress, millega nad ühendust võtsid.

Mida klient näeb, kui allikas muutub

UDP-pesal, mis ei ole seotud konkreetse kohaliku aadressiga, ei ole kindlat allikat, seega valib tuum selle saatmise hetkel. See valik tuleb marsruudipäringust kliendi aadressi suunas ja allikaks saab liidese aadress, mille päring valib. Ühe liidesega masinas on valik nähtamatu; hostis, millel on haldusaadress, avalik aadress ja samal võrgukaardil teisene aadress, sõltub see marsruudimõõdikutest ja -poliitikast. Poliitikal põhinev marsruutimine teeb lahknevuse tõenäolisemaks, mitte vähem tõenäoliseks, sest reegel võib valida ühenduse, kuhu klient kunagi ei jõudnud. Piisab ühelt teenusepakkujalt õpitud vaikemarsruudist ja allikareeglist, mis osutab teisele.

Kliendid, kes filtreerivad vastuseid, ja ühenduste jälgimine, mis ootab täpset nelikut ja allikat, jätavad vastuse kasuliku teateta kõrvale. Siis aegub tunnel, nagu poleks midagi saabunud, ja seepärast peetakse seda ekslikult kliendipoolse tulemüüri probleemiks. Ainult serveris tehtud salvestis kinnitab viga, selle asemel et seda selgitada, sest vastus tõesti lahkub. Võrrelge vastuse allikat aadressiga, millele klient helistas, enne kui midagi muud muudate.

Mida valik multihome tegelikult teeb

Direktiiv kirjutatakse konfiguratsioonifailis kujul multihome ja käsureal kujul --multihome, ning see paneb UDP-serveri vastama aadressilt, kuhu kliendi pakett jõudis. Tuum edastab vastuvõtul algse sihtaadressi lisaandmetena ja OpenVPN kasutab seda väärtust vastuse allikana. Nii käitub server, mis kuulab metamärgiaadressil, local 0.0.0.0 IPv4 jaoks või selle IPv6-vaste, nii, nagu oleks iga klient jõudnud eraldi kuulajani. Avaliku aadressi kaudu tulnud kliendid saavad vastuseid avalikult aadressilt ja sisemisel aadressil olevad kliendid sellelt aadressilt. Midagi muud paketi teel ei liigu: marsruut, filtrite reeglid ja tunneli konfiguratsioon jäävad täpselt selliseks, nagu need olid.

Just see viimane omadus teeb valiku lisamise muidu töötavale serverile ohutuks ja on ka põhjus, miks see ei suuda parandada filtrit, mis lubab ainult ühte aadressi. Pakett tuleb ikka vastu võtta teel, mida mööda see läheb, seega allika parandus muudab vastuse päritolu ega midagi enamat. See on ka ainult UDP jaoks: TCP-kuulajal ei ole seda probleemi samal kujul, sest ühendus tuvastatakse neliku, mitte vastuse allikaaadressi järgi.

Millal on fikseeritud kohalik aadress vale vaikeväärtus

Enne kui valiku juurde asute, kontrollige, kas server seob ühe konkreetse kohaliku aadressi, sest seotud kuulaja vastab alati sellelt aadressilt. See on õige ühe liidesega juurutuse jaoks ja vale niipea, kui kliendid kasutavad seaduslikult rohkem kui ühte aadressi. Kui sidumine oli tahtlik, otsustage, kas server peaks üldse lisaadressidel liiklust vastu võtma. Sidumise eemaldamine suurendab kokkupuudet, seega peavad lubatud liidesed ja allikavõrgud kehtestama teenus ja filter, mitte ainult sidumisaadress.

OpenVPN-i viide piirab valiku UDP-serveritega, märgib täiendava töötlemise paketi teel ja loetleb platvormid, mis seda toetavad. Kinnitage seda paigaldatud väljalaskes enne, kui sellele plaanite tugineda. Kus see ei ole toetatud, on alternatiiviks konkreetse aadressi sidumine või tagasitee marsruudi parandamine, ja mõlemad on kitsamad muudatused, kui esmapilgul tundub. Metamärgil kuulamine mõjutab ka enam kui vastuseid: server kõigil aadressidel on kättesaadav igast võrgust, millega host on ühendatud, ja see ei pruugi olla see kokkupuude, mida keegi kavatses.

Tõestage vastuse allikas väljastpoolt

Testige väljastpoolt serverit ja kirjutage üles täpne aadress ja transport, mida klient kasutas, enne kui midagi salvestate. Kolm allolevat kontrolli vastavad kolmele erinevale küsimusele ja järjekord on oluline.

tcpdump -ni any udp port 1194
ss -lunp 'sport = :1194'
ip route get 203.0.113.10 from 198.51.100.20

Salvestis näitab vastuses allikaaadressi ja see on fakt, millel kogu artikkel põhineb. Pesade loend näitab, millega server tegelikult seoti, sest metamärk-kuulaja ja konkreetne kuulaja näevad konfiguratsioonifailis ühesugused välja ning käituvad võrgus erinevalt. Marsruudipäring näitab allikat, mille tuum selle voo jaoks valiks, ja see selgitab salvestist enne, kui midagi muudate. Korrake kõiki kolme IPv4 ja IPv6 jaoks eraldi, sest need on eraldi kuulajad ja eraldi päringud, ning ühe perekonna metamärk-kirje ei ütle teise kohta midagi.

Marsruutimine, avastamine ja filtreerimine jäävad eraldi

Vastuse allika hoidmine ei paigalda väljuvat marsruuti, ei uuenda dünaamilist DNS-i ega pane üht aadressiperekonda teist vastu võtma. Mitme ühendusega serveris tuleb iga allika tagasitee teadlikult kokku leppida, muidu lahkuvad vastused liidese kaudu, mida kliendi filter kunagi ei lubanud. Samamoodi peab uus aadress pärast eesliite muutust jõudma klientideni avastamise ja toetatud taasühenduse voo kaudu, mitte vana kirje kaudu.

Jätke serveri identiteedi kontrollid ja sertifikaatide valideerimine täpselt selliseks, nagu need on, sest muutunud aadress ei õigusta kinnitamata vastaspoole vastuvõtmist. Kui vastus lahkub nüüd ettenähtud allikalt ja tunnel ikka ei tööta, pidage allika probleemi lahendatuks ja liikuge edasi. Järgmine täheldatud viga kuulub marsruutimisele, filtreerimisele või autentimisele ning kuulaja veelkordne muutmine ei jõua selleni. Kirjutage vastuse allikas piletisse kliendi helistatud aadressi kõrvale, et järgmine inimene saaks sama fakti ühe käsuga kontrollida.