Wie antwoord werklik op die VPN se toegewyde adres?

’n Adres wat ongebruik in die organisasie se toekenning lê, is nie ’n luisteraar nie, en om dit by ’n firewall by te voeg skep nie een nie. Iets moet IKE op daardie adres termineer, en die meganisme verskil na gelang van of die poort die adres besit of ’n stroomoptoestel dit vertaal. Die pakketpad is wat die twee onderskei, en dit bepaal watter platformfunksie jy nodig het voordat iemand ’n veranderingsversoek oopmaak. Modelleer eers die pad en kies dan.

Die pakketpad agter die adres

’n Eweknie stuur IKE na die adres wat dit gekry het, op UDP 500 of op UDP 4500 wanneer NAT-deurgang in die spel is. Watter toestel ook al daardie adres op die pad hou, ontvang die datagram plaaslik en antwoord dit, of stuur dit elders heen. Dit is die enigste twee moontlikhede, en alles anders in hierdie artikel volg uit watter een waar is.

Plaaslike ontvangs beteken daar bestaan ’n socket op daardie toestel, gebind aan daardie adres. Stuur aan beteken die datagram word herskryf en verder na ’n ander eindpunt gestuur, wat dan die socket het. ’n Firewallreël wat UDP 500 toelaat, sê jou niks oor watter van die twee gebeur nie.

Skryf die rekord voordat jy iets aanraak: die adres wat eweknieë kontak, hoe die stroomopnetwerk dit aflewer, die plaaslike koppelvlak of logiese eindpunt wat dit ontvang, en die proses wat IKE antwoord. Vier reëls, en elkeen kan nagegaan word. Wanneer een van hulle onbekend is, is daardie onbekende die ontwerpwerk eerder as ’n implementeringsdetail om later te besleg. Om hulle in te vul nadat die veranderingsversoek goedgekeur is, is hoe ’n vertaalreël by die verkeerde toestel gevoeg word.

Model A: die poort besit die adres

In die eerste model hou die poort die adres self, hetsy as ’n sekondêre adres op ’n bestaande koppelvlak, as ’n adres op ’n toegewyde koppelvlak, of as ’n loopback wat die platform as ’n tonneleindpunt ondersteun. Dit is drie verskillende funksies met drie verskillende konfigurasiepaaie, en ’n platform wat een ondersteun, ondersteun dalk nie die ander nie.

Bevestig dat die platform en vrystelling die presiese reëling ondersteun voordat jy daarom ontwerp. ’n Gerouteerde blok, ’n bykomende adres op ’n koppelvlak en ’n loopback-eindpunt is nie uitruilbaar nie, en dokumentasie vir een vrystelling belowe nie dat die volgende een dieselfde maak nie.

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

Die luistersocket is die bewys. As niks aan die adres gebind is nie, is die poort nie die termineerder nie ongeag wat die roeteringstabel sê, en ’n pakketopname sal wys dat die datagramme aankom met niks wat hulle antwoord.

Moenie ’n tweede koppelvlak in ’n subnet plaas wat reeds elders in die topologie bestaan nie en aanneem die platform sal dit oplos. Oorvleuelende koppelvlak-subnette veroorsaak dubbelsinnige bronkeuse en, op baie platforms, ’n weiering om hoegenaamd te konfigureer.

Model B: ’n stroomoptoestel vertaal dit

In die tweede model hou ’n stroomop-firewall die toegewyde adres en stuur die verkeer na ’n ander VPN-poort aan. Dit is ’n bestemmingsvertaling met ’n terugpad, en dit is ’n heeltemal geldige ontwerp solank dit as sodanig gedokumenteer is.

Wat dit nie is nie, is bewys dat die stroomoptoestel ’n plaaslike VPN-socket verkry het. Die vertaling stuur pakkette aan; dit maak nie die stroomop-boks ’n IKE-responder nie. As die stroomopreël verwyder word of sy terugpad breek, stop die VPN selfs al is die poort gesond en sy eie luisteraars ongeskonde.

Teken beide adresse aan: die een wat eweknieë kontak en die een wat die poort werklik sien. Teken dan die transport en die terugpad aan, want ’n vertaling wat vir UDP 500 werk maar nie vir ingekapselde ESP nie, sal verbind en dan versuim om verkeer te dra, wat ’n verwarrende fout is om later te ontfout.

Identiteit is nie die buitenste adres nie

IPsec skei die tonneleindpunt van die verkeer wat dit beskerm, en die argitektuur hou daardie besluite op verskillende plekke. Om die adres te verander wat eweknieë kontak, verander nie outomaties watter binneprefikse toegelaat word, watter roetes geïnstalleer word of watter hulpbronne die sessie mag bereik nie.

Die geauthentiseerde identiteit is weer apart. IKEv2 dra ’n identiteitslading en ’n stawingsuitruiling wat nie aan die buitenste pakketadres hoef te pas nie, en dit is juis waarom ’n vertaalde ontwerp steeds korrek kan authentiseer.

Daardie onafhanklikheid is nuttig en ook ’n strik. Twee DNS-name wat na een gewone luisteraar oplos, kies nie verskillende VPN-agterkante nie, en ’n sertifikaat wat een identiteit noem, sal nie ’n eweknie bevredig wat ’n ander verwag nie. Bevestig wat die eweknie valideer voordat jy aanneem die adres alleen bepaal dit.

Aanvaar die ontwerp deur een verbinding dop te hou

Ondersoek waar ’n nuwe gemagtigde verbinding werklik afgelewer word, watter identiteit antwoord en watter private vloei dan toegelaat word. Drie waarnemings, drie verskillende lae, en ’n suksesvolle openbare opsoek van die adres toets nie een van hulle nie.

Behou ook die negatiewe geval: ’n eweknie wat nie aanvaar moet word nie, of ’n binneprefiks wat nie bereikbaar moet wees nie, geverifieer ná die verandering. Die rekord wat jy aan die begin geskryf het, is wat daardie toets moontlik maak sonder om die ontwerp uit die geheue te rekonstrueer.

Die punt van dit alles is om die netwerkeienaar ’n ondersteunde toekenningsmetode te laat kies eerder as om op ’n algemene bewering te vertrou oor wat elke firewall met ’n ekstra adres kan doen. Daardie bewering is presies waar hierdie ontwerpe verkeerd loop, want dit klink op elke platform geloofwaardig en is in die algemeen op geen van hulle waar nie. Die vier-reël-rekord besleg dit vir jou platform in tien minute.