Kuram paketei ir jāatbilst VPN politikai ar diviem WAN?

Pieprasījumi maršrutēt VPN pa otro augšupielādes līniju apraksta vismaz divus dažādus darbus, un politika, kas salabo vienu, neaizskar otru. Pirmajā darbā šifrētais transports starp diviem galapunktiem pārvietojas uz citu WAN adresi. Otrajā pieslēgta lietotāja atšifrētā lietotnes plūsma iziet uz citu nākamo lēcienu. Abi ir likumīgi, abi izmanto maršrutēšanu, un katram nepieciešama atbilstība paketei, kas pastāv tajā punktā, kur tiek pieņemts lēmums. Veiciet zemāk minētās pārbaudes secīgi, jo pirmā nosaka, kuru paketi vēlākajiem noteikumiem jānosauc.

Nosauciet abas sarunas

Iedomājieties attālinātu darbinieku, kas pieslēgts biroja vārtejai un atver HTTPS uz iekšēju lietotņu serveri. Uz līnijas ir divas neatkarīgas sarunas, un tām katrā galā ir atšķirīgas adreses. Ārējā saruna notiek starp diviem VPN galapunktiem: no vārtejas adreses uz partnera adresi, ar to protokolu un portu, par ko vienojusies ieviešana. Iekšējā saruna notiek no klientam piešķirtās adreses uz lietotnes servera adresi portā 443.

Lietotnes galamērķa ports nav VPN transporta ports, un nekāds politikas daudzums uz TCP 443 nepārvietos tuneli. Tāpat noteikums, kas pāradresē partnera transporta adresi, neko nepasaka par to, kur pēc atšifrēšanas aiziet šī lietotāja HTTP pieprasījums. Pierakstiet abas sarunas ar to patiesajām adresēm pirms noteikuma aizskaršanas, jo lielākā daļa neskaidrību šajā jomā rodas no tā, ka vienu nosauc, bet otru konfigurē.

Atrodiet, kur jūsu politika patiešām redz paketi

Atbilstība ir jānovērtē tajā ķēdē un nosaukumtelpā, kur pakete joprojām ir jūsu aprakstītajā formā. Noteikums, kas piesaistīts LAN ieejai, redz iekšējo paketi nešifrētu, pirms tā tiek maršrutēta uz tuneli. Noteikums, kas piemērots lokāli ģenerētam trafikam, redz paketes, ko ģenerē pati vārteja, un tas automātiski neaptver trafiku, ko vārteja tikai pārsūta. Iekapsulētā izvade atkal ir trešais gadījums, ko parasti apstrādā saskarnē, kas nes tuneli, nevis LAN pusē.

Tāpēc viens un tas pats konfigurācijas fragments divās platformās uzvedas atšķirīgi: piesaistes punkti atšķiras, un piegādātāja politikas āķis var atrasties pirms šifrēšanas soļa vai pēc tā. Lasiet paketes ceļu konkrētajam produktam, nevis pieņemiet secību no cita piegādātāja diagrammas.

Apstipriniet transportu, par kuru vienojāties

UDP iekapsulētam IPsec, RFC 3948 ievieto ESP UDP iekšpusē un izmanto ne ESP marķieri, lai IKE paliktu atšķirams kopīgajā portā. Vienkāršs ESP ir IP protokols, nevis TCP vai UDP ports, tāpēc ugunsmūra noteikums, kas rakstīts pēc porta numura, to nemaz nesaskaņos. Šī atšķirība nosaka, vai jūsu WAN politikai vajag UDP noteikumu, protokola noteikumu vai abus.

Vienotās vērtības pārspēj atcerētās. Lasiet pašreizējos asociācijas portus un adreses no ierīces, nevis pievienojiet TCP 4500 vai vecu piegādātāja portu drošības pēc, jo tas noķer nesaistītu trafiku un slēpj īsto klasifikācijas problēmu.

Pārbaudiet atgriešanās ceļu pirms saistību uzņemšanās

Panākumi izejošajā virzienā pierāda pusi no projekta. Pakete, kas atgriežas uz attālo klientu peldbaseinu, vairs nav redzama zem klienta adreses, tiklīdz iekapsulēšana to aizstāj: ārējais galamērķis ir partnera transporta adrese. Ja otrā augšupielādes līnija sasniedz šo partneri caur citu operatoru, tās tulkošana un filtrēšana var nesaskanēt ar pirmo, un asociācija var būt jāpārbuiltē, nevis jāmigrē.

Tīkla adrešu tulkošanas stāvoklis ir ierastais WAN maiņas upuris. Pierakstiet izvēlēto augšupielādes līniju, gaidīto ārējo avota adresi, izmantoto tulkojumu un partnera sasniedzamību atpakaļ uz to, pēc tam turiet transportu sasniedzamu, nesūtot to tunelī, ko tas nes.

Pārbaudiet abus slāņus ar diviem ierakstiem

Viens ieraksts WAN saskarnē un viens tuneļa iekšpusē atrisina jautājumu ātrāk nekā jebkurš konfigurāciju salīdzinājums. Palaidiet tos no vārtejas, kamēr apstiprināts klients izpilda vienu pieprasījumu, un saglabājiet abus failus.

sudo tcpdump -ni wan1 'udp port 4500' -c 20
sudo tcpdump -ni tun0 'tcp port 443 and host 203.0.113.10' -c 20
ip route get 203.0.113.10 from 10.8.0.6

Pirmajam ierakstam vajadzētu parādīt ārējo sarunu, kas atstāj saskarni, kuru bijāt domājis, ar gaidīto avota adresi. Otrajam vajadzētu parādīt iekšējo sarunu vienu reizi, bez dublēšanās, ar klienta adresi kā avotu un lietotnes serveri kā galamērķi. Maršruta meklēšana apstiprina, kuru tabulu maršrutētājs izmantotu šim avota un galamērķa pārim, un tieši tur parasti parādās politikas kļūda. Ja kāds no ierakstiem neparādās, lēmuma punkts ir citur, nevis tur, kur noteikums tika piesaistīts, un labojums pieder tur, nevis plašākai atbilstībai.