Werf-tot-werf teenoor afstandtoegang-VPN: wat die twee verbind

Beide ontwerpe word ’n VPN genoem en hulle los verskillende probleme op. ’n Werf-tot-werf-tonnel verbind twee gateways, sodat elke gasheer daar agter toegang kan kry tot toegelate adresse aan die ander kant sonder om enigiets te installeer. ’n Afstandtoegang-tonnel verbind individuele toestelle aan ’n netwerk, een kliënt op ’n slag. Die vergelyking is belangrik, want die meeste ontplooiingsfoute kom daarvan dat ’n mens die een opset configureer terwyl jy die gedrag van die ander verwag, en die simptoom is gewoonlik ’n tydsverstreke op ’n diens wat die tonnel wel bereik het.

Twee ontwerpe, twee grense

Nie een van die ontwerpe brei ’n LAN-uitsaai-domein uit nie. Toestelle aan die anderkant verskyn nie in ’n plaaslike ontdekkingslys nie, en om te verwag dat hulle dit sou doen, is die eerste aanname om te laat vaar. Privaat DNS-name wat jy doelbewus publiseer, is meer voorspelbaar as enige ontdekkingsprotokol, en hulle oorleef ’n verandering van verskaffer.

Neem 10.10.0.0/24 by die een werf en 10.20.0.0/24 by die ander. Gateway A het ’n roete of ’n verkeerskeurder nodig wat die 10.20.0.0/24-voorvoegsel in die tonnel instuur, en gateway B het die spieëlbeeld daarvan nodig. Gashere aan weerskante gebruik dan gewone IP-konneksie en leer nooit dat daar ’n tonnel bestaan nie. Daardie onsigbaarheid is die eienskap, en dit is ook hoekom mislukkings soos gewone netwerkfoute lyk eerder as tonnelfoute.

Beleidsgebaseerd en roetegebaseerd is nie dieselfde tonnel nie

In ’n beleidsgebaseerde IPsec-ontplooiing bepaal die bedingde verkeerskeurders presies watter bron- en bestemmingspare beskerm word. As ’n nuwe subnet agter een gateway verskyn en geen keurder dek dit nie, bly die tonnel aan en word die nuwe subnet bloot nie gedra nie. In ’n roetegebaseerde ontwerp ontvang ’n koppelvlak die verkeer en die roetetabel besluit daaroor, wat beteken dat die byvoeg van ’n voorvoegsel ’n roeteverandering is eerder as ’n heronderhandeling van die tonnel.

StrongSwan wys albei sienings direk, en om hulle saam te lees, is hoe jy agterkom watter model jy werklik ontplooi het.

swanctl --list-sas
ip xfrm policy
ip -4 route show table all | grep -E '10\.(10|20)\.'

’n Keurderlys wat die voorvoegsel wat jy nodig het weglaat, verduidelik die mislukking sonder enige pakketopname, en ’n roete wat na die verkeerde koppelvlak wys, verduidelik die spieëlbeeld-mislukking op die terugpad. Lees albei voordat jy iets heronderhandel, want ’n herleuteling sal nie ’n keurder byvoeg wat jy nooit geconfigureer het nie.

Beplan die adressering voor die tonnel

Oorvleuelende reekse is die ontwerpfout wat nie met konfigurasie reggemaak kan word nie. As albei werwe 192.168.1.0/24 gebruik, het ’n gasheer wat 192.168.1.50 nodig het twee kandidate en geen manier om te kies nie. Die tonnel sal verifieer, die sekuriteitsassosiasies sal tot stand kom, en die roetebesluit sal nietemin verkeerd of dubbelsinnig wees.

Kies een van drie eerlike opsies: nommer een werf oor, vertaal die oorvleuelende reeks by die gateway sodat elke kant ’n afsonderlike voorvoegsel sien, of gee op met direkte roeteverkeer vir daardie gashere en publiseer die diens op ’n ander manier. Elkeen het ’n koste, en die eerste is gewoonlik die goedkoopste oor ’n tweejaar-horison. Besluit voordat die tonnel bestaan, want agterna raak die verandering elke toestel wat die ou adres het.

Maak ook die MTU-vraag vroeg reg. ’n Tonnel verminder die bruikbare loonvrag, en ’n ontwerp wat op fragmentering staatmaak, gedra hom anders as een wat die MSS by die gateways vaspen.

Deurvoer en beleid sit buite die tonnel

Die gateway moet bereid wees om pakkette tussen die tonnelkoppelvlak en die LAN-koppelvlak deur te voer, en albei rigtings het beleid nodig wat die diens toelaat. Op Linux is dit twee afsonderlike instellings, plus die brandmuurreëls wat besluit of die deurgevoerde vloei hoegenaamd toegelaat word.

sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -s 10.20.0.0/24 -d 10.10.0.0/24 -j ACCEPT
iptables -A FORWARD -s 10.10.0.0/24 -d 10.20.0.0/24 -j ACCEPT

Die ontvangende gasheer voeg ’n derde laag by: sy eie brandmuur moet steeds ’n kliënt van die afgeleë subnet aanvaar. ’n Lêerbediener wat net sy plaaslike /24 toelaat, sal deurgevoerde verkeer van 10.20.0.7 verwerp, maak nie saak hoe gesond die tonnel lyk nie, en daardie verwerping word maklik as ’n roetefout gelees.

Toets vanaf ’n gasheer, nie vanaf die gateway nie

’n Ping wat deur die gateway self gestuur word, kan ’n ander bronadres en ’n ander beleid volg as deurgevoerde gebruikersverkeer. Dit maak dit ’n swak toets en soms ’n misleidende een: dit slaag terwyl die toepassing faal, of dit faal terwyl die toepassing werk.

ip route get 10.10.0.5 from 10.20.0.7
ping -I 10.20.0.7 10.10.0.5
curl -sv --max-time 5 http://files.10-10.internal/ -o /dev/null

Gebruik ’n werklike gasheer, ’n werklike bronadres en die werklike protokol wat die toepassing gebruik. Lees dan die antwoordpad afsonderlik, want ’n werkende voorwaartse rigting sonder ’n terugroete lewer ’n tydsverstreke op wat identies lyk aan ’n geblokkeerde diens.

Kies die ontwerp volgens die vraag wat jy beantwoord: verbind jy netwerke, of laat jy toestelle toe? Alles anders, insluitende watter verskaffer jy configureer, volg uit daardie antwoord.