Kdo v resnici odgovarja na namenskem naslovu VPN?

Naslov, ki leži neuporabljen v dodelitvi organizacije, ni poslušalec, in dodajanje v požarni zid ne ustvari nobenega. Nekaj mora na tem naslovu končati IKE, mehanizem pa se razlikuje glede na to, ali ima naslov prehod ali ga prevaja naprava višje na poti. Prav pot paketa oba primera loči, in določa, katero funkcijo platforme potrebujete, preden kdo odpre zahtevo za spremembo. Najprej modelirajte pot, nato izbirajte.

Pot paketa za naslovom

Sogovornik pošlje IKE na naslov, ki ga je dobil, na UDP 500 ali na UDP 4500, kadar je v igri prehod skozi NAT. Naprava, ki ima ta naslov na poti, datagram bodisi sprejme lokalno in nanj odgovori, bodisi ga posreduje drugam. To sta edini dve možnosti, in vse ostalo v tem članku izhaja iz tega, katera je resnična.

Lokalni sprejem pomeni, da na tej napravi obstaja vtičnica, vezana na ta naslov. Posredovanje pomeni, da se datagram prepiše in pošlje naprej na drugo končno točko, ki ima nato vtičnico. Pravilo požarnega zidu, ki dovoljuje UDP 500, vam ne pove nič o tem, katera od obeh stvari se dogaja.

Zapišite zapis, preden se česar koli dotaknete: naslov, s katerim se povezujejo sogovorniki, kako ga dostavi nadrejeno omrežje, lokalni vmesnik ali logično končno točko, ki ga sprejme, in proces, ki odgovori na IKE. Štiri vrstice in vsako je mogoče preveriti. Ko je katera neznana, je ta neznanka delo pri zasnovi in ne podrobnost izvedbe, ki jo boste rešili kasneje. Izpolnjevanje po odobritvi zahteve za spremembo je način, kako pravilo prevajanja pride na napačno napravo.

Model A: naslov ima prehod

V prvem modelu ima naslov sam prehod, bodisi kot sekundarni naslov na obstoječem vmesniku, kot naslov na namenskem vmesniku, bodisi kot povratna zanka, ki jo platforma podpira kot končno točko tunela. To so tri različne funkcije s tremi različnimi potmi konfiguracije, in platforma, ki podpira eno, morda ne podpira drugih.

Preden zasnujete okoli tega, potrdite, da platforma in izdaja podpirata točno takšno razporeditev. Usmerjen blok, dodatni naslov na vmesniku in končna točka povratne zanke niso zamenljivi, in dokumentacija ene izdaje ne obljublja, da se bo naslednja obnašala enako.

ip -br addr show
ss -lunp | grep -E ':500|:4500'
sudo tcpdump -ni eth0 'udp port 500 or udp port 4500'

Dokaz je vtičnica, ki posluša. Če na naslov ni vezano nič, prehod ni zaključevalec ne glede na to, kaj pravi usmerjevalna tabela, in zajem paketov bo pokazal datagrame, ki prihajajo, medtem ko nanje nič ne odgovarja.

Drugega vmesnika ne postavljajte v podmrežo, ki že obstaja drugje v topologiji, in ne predpostavljajte, da bo platforma to uredila. Prekrivajoče se podmreže vmesnikov povzročijo dvoumno izbiro vira in na mnogih platformah popolno zavrnitev konfiguracije.

Model B: naprava višje na poti ga prevaja

V drugem modelu ima namenski naslov požarni zid višje na poti in promet posreduje na drug prehod VPN. To je prevod cilja s povratno potjo in povsem veljavna zasnova, dokler je tako dokumentirana.

Kar pa ni, je dokaz, da je naprava višje na poti pridobila lokalno vtičnico VPN. Prevod posreduje pakete; iz zgornje škatle ne naredi odgovarjalca na IKE. Če pravilo višje na poti odstranimo ali se njegova povratna pot prekine, se VPN ustavi, čeprav je prehod zdrav in so njegovi poslušalci nedotaknjeni.

Zabeležite oba naslova: tistega, s katerim se povezujejo sogovorniki, in tistega, ki ga prehod dejansko vidi. Nato zabeležite prenos in povratno pot, ker se bo prevod, ki deluje za UDP 500, ne pa za zapakiran ESP, povezal in nato ne bo mogel prenašati prometa, kar je zmedena okvara za kasnejše odpravljanje napak.

Identiteta ni zunanji naslov

IPsec loči končno točko tunela od prometa, ki ga ščiti, in arhitektura te odločitve hrani na različnih mestih. Sprememba naslova, s katerim se povezujejo sogovorniki, samodejno ne spremeni, kateri notranji prefiksi so dovoljeni, katere poti so nameščene ali do katerih virov lahko seja dostopa.

Preverjena identiteta je spet ločena. IKEv2 nosi identitetno koristno obremenitev in izmenjavo preverjanja, ki se jima ni treba ujemati z zunanjim naslovom paketa, in prav zato se prevedena zasnova še vedno lahko pravilno preveri.

Ta neodvisnost je koristna in hkrati past. Dve imeni DNS, ki se razrešita na enega običajnega poslušalca, ne izbereta različnih zaledij VPN, in potrdilo, ki poimenuje eno identiteto, ne bo zadovoljilo sogovornika, ki pričakuje drugo. Potrdite, kaj sogovornik preverja, preden predpostavite, da to odloča samo naslov.

Zasnovo sprejmite z opazovanjem ene povezave

Preverite, kam se nova pooblaščena povezava dejansko dostavi, katera identiteta odgovori in kateri zasebni tok je nato dovoljen. Tri opažanja, tri različne plasti, in uspešno javno iskanje naslova ne preveri nobenega od njih.

Ohranite tudi negativni primer: sogovornika, ki ne bi smel biti sprejet, ali notranji prefiks, ki ne bi smel biti dosegljiv, preverjeno po spremembi. Zapis, ki ste ga napisali na začetku, je tisto, kar ta preizkus omogoči brez ponovnega sestavljanja zasnove iz spomina.

Smisel vsega tega je omogočiti lastniku omrežja, da izbere podprto metodo dodeljevanja, namesto da bi se zanašal na splošno trditev o tem, kaj zmore vsak požarni zid z dodatnim naslovom. Prav ta trditev je mesto, kjer se te zasnove zalomijo, ker zveni verjetno na vsaki platformi in na nobeni splošno ne drži. Zapis iz štirih vrstic to za vašo platformo razreši v desetih minutah.