Kven svarar eigentleg på den dedikerte adressa til VPN-en?

Ei adresse som ligg ubrukt i tildelinga til organisasjonen, er ikkje ein lyttar, og å leggje henne til ein brannmur skapar ingen. Noko må avslutte IKE på den adressa, og mekanismen varierer etter om gatewayen eig adressa eller ei oppstraums eining set henne om. Pakkestien er det som skil dei to, og han avgjer kva plattformfunksjon du treng før nokon opnar ein endringsførespurnad. Modeller stien først, og vel deretter.

Pakkestien bak adressa

Ein partnar sender IKE til adressa han har fått, på UDP 500 eller på UDP 4500 når NAT-traversering er i spel. Den eininga som held adressa på stien, tek anten imot datagrammet lokalt og svarar på det, eller sender det vidare ein annan stad. Det er dei einaste to høva, og alt anna i denne artikkelen følgjer av kva som er sant.

Lokal mottak tyder at det finst ein socket på den eininga, bunden til den adressa. Vidaresending tyder at datagrammet blir skrive om og sendt vidare til eit anna endepunkt, som då har socketen. Ein brannmurregel som tillèt UDP 500, fortel deg ingenting om kven av dei to som skjer.

Skriv registreringa før du rører noko: adressa partnarane kontaktar, korleis oppstraumsnettet leverer henne, det lokale grensesnittet eller det logiske endepunktet som tek imot henne, og prosessen som svarar på IKE. Fire linjer, og kvar av dei kan kontrollerast. Når éi av dei er ukjend, er det ukjende designarbeidet og ikkje ein implementasjonsdetalj som blir avgjord seinare. Å fylle dei ut etter at endringsførespurnaden er godkjend, er korleis ein omsetjingsregel hamnar på feil eining.

Modell A: gatewayen eig adressa

I den første modellen held gatewayen adressa sjølv, anten som sekundæradresse på eit eksisterande grensesnitt, som adresse på eit dedikert grensesnitt, eller som loopback som plattforma støttar som tunnelendepunkt. Det er tre ulike funksjonar med tre ulike konfigurasjonsvegar, og ei plattform som støttar éin, støttar kanskje ikkje dei andre.

Stadfest at plattforma og utgåva støttar nøyaktig denne ordninga før du designar rundt henne. Ein ruta blokk, ei ekstra adresse på eit grensesnitt og eit loopback-endepunkt kan ikkje bytast om, og dokumentasjonen for éi utgåve lovar ikkje at den neste oppfører seg likt.

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

Den lyttande socketen er provet. Om ingenting er bunde til adressa, er ikkje gatewayen terminatoren uansett kva rutetabellen seier, og ein pakkefangst vil vise datagramma kome utan at noko svarar dei.

Ikkje set eit andre grensesnitt inn i eit subnett som allereie finst andre stader i topologien, og ikkje gå ut frå at plattforma ordnar det. Overlappande grensesnitt-subnett gir tvitydig kjeldeval og, på mange plattformer, ei blank avvising av å konfigurere.

Modell B: ei oppstraums eining set henne om

I den andre modellen held ein oppstraums brannmur den dedikerte adressa og sender trafikken vidare til ein annan VPN-gateway. Det er ei målomsetjing med ein returveg, og det er eit fullt gyldig design så lenge det blir dokumentert som slikt.

Det ho ikkje er, er prov for at den oppstraums eininga har fått ein lokal VPN-socket. Omsetjinga sender pakkar vidare; ho gjer ikkje den øvste boksen til ein IKE-respondar. Om den oppstraums regelen blir fjerna eller returvegen bryt, stoppar VPN-en sjølv om gatewayen er sunn og hans eigne lyttarar er intakte.

Registrer begge adressene: den partnarane kontaktar, og den gatewayen faktisk ser. Registrer deretter transporten og returvegen, fordi ei omsetjing som verkar for UDP 500 men ikkje for innkapsla ESP, vil kopla til og deretter ikkje klare å bera trafikk, noko som er ein forvirrande feil å feilsøkje seinare.

Identitet er ikkje den ytre adressa

IPsec skil tunnelendepunktet frå trafikken det vernar om, og arkitekturen held desse avgjerdene på ulike stader. Å endre adressa partnarane kontaktar, endrar ikkje automatisk kva indre prefiks som er tillatne, kva ruter som blir installerte, eller kva ressursar sesjonen kan nå.

Den autentiserte identiteten er igjen separat. IKEv2 ber ein identitetsnyttelast og ein autentiseringsutveksling som ikkje treng å samsvare med den ytre pakkeadressa, og nettopp difor kan eit omsett design framleis autentisere rett.

Den uavhengigheita er nyttig og samstundes ei felle. To DNS-namn som løyser til éin vanleg lyttar, vel ikkje ulike VPN-bakendar, og eit sertifikat som nemner éin identitet, vil ikkje tilfredsstille ein partnar som ventar ein annan. Stadfest kva partnaren validerer før du går ut frå at adressa åleine avgjer det.

Godta designet ved å sjå på éi tilkopling

Undersøk kvar ei ny autorisert tilkopling faktisk blir levert, kva identitet som svarar, og kva privat flyt som deretter blir tillaten. Tre observasjonar, tre ulike lag, og eit vellukka offentleg oppslag av adressa testar ingen av dei.

Hald òg på det negative tilfellet: ein partnar som ikkje skal godtakast, eller eit indre prefiks som ikkje skal vere nåbart, verifisert etter endringa. Registreringa du skreiv i starten, er det som gjer den testen mogleg utan å byggje designet opp att frå minnet.

Poenget med alt dette er å la netteigaren velje ein støtta tildelingsmetode i staden for å stole på ein generell påstand om kva kvar brannmur kan gjere med ei ekstra adresse. Det er nettopp den påstanden som er staden der desse designa går gale, fordi han høyrest truverdig ut på kvar plattform og generelt ikkje er sann på noka av dei. Registreringa på fire linjer avgjer det for plattforma di på ti minutt.