Werf-tot-werf-VPN: watter rigting het regtig 'n reël nodig?

Beide kante rapporteer 'n gevestigde tonnel, die verre tak antwoord vanaf die gateway, en die toepassing hou vir gebruikers aan een kant steeds uit. Die gewone raad sê om 'n vuurmuurreël in beide rigtings by te voeg. Soms is dit reg, soms dupliseer dit 'n reël wat reeds bestaan, en soms is dit die tweede reël wat die toestand breek. Watter geval geld, hang af van waar die vuurmuur die pakket sien.

Toestandsvolle terugkeerverkeer verander die telling

'n Toestandsvolle vuurmuur registreer die versoek en laat die antwoord sonder 'n tweede reël deur, so 'n ontwerp wat net een reël nodig het, is normaal. 'n Toestandlose toegangslys het nie sulke geheue nie, en die antwoord moet uitdruklik toegelaat word. Albei is korrek op hul eie platform, en daarom bots die advies.

Lees die deurstuur-dokumentasie vir die platform voor jou, en kyk of die beleid wat jy wysig toestandsvol is waar dit die pakket sien. 'n Uitdruklike weiering vir gevestigde verkeer, of 'n reëlorde wat die antwoord voor die toestandtabel evalueer, maak 'n werkende ontwerp raaiselagtig. Die aantal reëls is 'n implementeringsbesonderheid, terwyl die vereiste is dat beide rigtings van 'n toegelate gesprek kan voltooi.

Waar die vuurmuur ontsyferde pakkette sien

In 'n beleidsgebaseerde tonnel kan die vuurmuur die geënkripteerde pakket voor ontsyfering evalueer en die ontsyferde pakket daarna, op verskillende koppelvlakke. 'n Reël wat vir die verkeerde een geskryf is, is teenwoordig, korrek en word nooit getref nie. Dis hoe 'n reëlstel wat uit 'n werkende ontplooiing gekopieer is, op identiese hardeware kan faal.

Roetegebaseerde IPsec en die meeste moderne implementerings bied 'n tonnelkoppelvlak, so die ontsyferde pakket kom daar aan en gewone koppelvlakreëls geld. Bevestig watter model die ontplooiing gebruik voordat jy 'n reëlstel uit 'n gids kopieer wat vir die ander een geskryf is. Die tonnelkoppelvlak is ook die plek om te kyk wanneer jy wil weet of 'n pakket hoegenaamd ontsyfer is.

Asimmetriese roetering breek die aanname

Toestandsvolle vuurmuur aanvaar dat hy beide helftes van die gesprek sien. As die antwoord deur 'n ander gateway terugkeer, hou daardie toestel geen toestand vir die versoek nie en laat val dit volgens sy eie beleid. Die simptoom is 'n eenrigtingfout wat geen reël aan die sturende kant kan herstel nie. Volg die antwoordroete voordat jy enigiets wysig.

Kontroleer die antwoordroete voordat jy 'n breë toelatingsreël aan beide kante byvoeg. Om alles op elke koppelvlak te duld, verberg die roeteringsfout en verbreed terselfdertyd toegang, wat die slegste kombinasie is wat beskikbaar is.

Kontroleer beide rigtings met werklike bronadresse

Toets met die adres wat die verre kant werklik sien, want vertaling kan 'n bronreël heeltemal niks laat pas nie. Voer die opname op beide gateways op dieselfde tyd uit.

tcpdump -ni any 'host 10.30.8.15 and tcp port 443'
nft list ruleset | grep -A 8 'chain forward'
ip route get 10.30.8.15
conntrack -L | grep 10.30.8.15

'n Versoek wat met 'n onverwagte bronadres op die verre gateway verskyn, verduidelik 'n reël wat nooit pas nie, en 'n antwoord wat op die verkeerde koppelvlak aankom, verduidelik 'n toestandwanstuur. Toets dan een bestemming binne die goedgekeurde omvang en een daarbuite, sodat die grens gedemonstreer word eerder as aangeneem.

Teken die bronadres ná vertaling aan, die koppelvlak wat die ontsyferde pakket gebruik het, en die reël wat gepas het. Daardie drie feite beantwoord die volgende tiket sonder om die hele ondersoek te herhaal.