VPN-grendel het IP-doorstuur nodig: wat om te kontroleer

Jou kliënt kan die grendel se adres ping terwyl elke hulpbron daaragter onbereikbaar bly. Daardie paar waarnemings beskryf 'n gasheer wat met jou praat en 'n roeteerder wat nie roeteer nie, wat 'n ander rol op dieselfde masjien is. Doorstuur is die skakelaar tussen hulle.

Die twee rolle is onafhanklik, en so ook die twee adresfamilies.

Om sy eie adres te antwoord bewys niks

Wanneer 'n pakkie aan die grendel self geadresseer word, verbruik die plaaslike stapel dit en geen doorstuur-besluit vind plaas nie. Daarom sê 'n suksesvolle ping na die tonneladres of 'n bestuurskoppelvlak vir jou dat die daemon leef en die tonnel op is, terwyl dit niks sê oor verkeer wat vir 'n netwerk agter die boks bestem is nie. Die kernel raadpleeg net sy doorstuurpad vir pakkies wat nie aan hom geadresseer is nie.

Lees die vereiste as 'n rol, nie 'n instelling nie: hierdie gasheer moet pakkies tussen twee koppelvlakke beweeg. 'n Skootrekenaar wat net 'n afgeleë netwerk hoef te bereik, neem nooit daardie rol nie, en 'n werf-tot-werf-eindpunt altyd. Om die vereiste so te lees verduidelik waarom 'n werkende kliëntkonfigurasie misluk wanneer dit na 'n grendel verskuif word.

Dieselfde sin geld vir die brandmuur voor die doorstuur-besluit, wat sy eie beleid het oor wat deurgestuur mag word.

Kontroleer elke adresfamilie afsonderlik

IPv4-doorstuur is een skakelaar, en IPv6-doorstuur is 'n ander een met sy eie gedrag per koppelvlak. Om die eerste te aktiveer sê niks oor die tweede nie, en 'n dubbelstapel-kliënt kan die helfte van 'n netwerk bereik terwyl die res donker bly. Twee kliënte van verskillende families kan dus oor dieselfde grendel verskil. Vra watter familie die falende kliënt gebruik het voordat jy enige instelling wysig. Bevestig albei voordat jy tot die gevolgtrekking kom dat die roeteringontwerp verkeerd is.

sysctl net.ipv4.ip_forward
sysctl -a --pattern 'net.ipv6.conf.(all|default).forwarding'
nft list ruleset | head -n 40

Op baie verspreidings is die waarde wat jy tydens looptyd lees, daar geplaas deur 'n diens of 'n konfigurasielêer, so 'n verandering wat met 'n eenmalige opdrag gemaak is, kan by herstarting verdwyn. Vind die lêer wat die instelling besit voordat jy die looptydwaarde wysig.

Doorstuur is een van vier vereistes

'n Werkende deurgestuurde vloei het vier dinge gelyktydig nodig: die kliënt moet weet die bestemming is agter die tonnel, die grendel moet 'n roete verder hê, antwoorde moet 'n pad terug hê, en die brandmuur moet die verkeer toelaat. Bronvertaling hoort by daardie ontwerp as 'n opsie eerder as 'n reël, want 'n privaat geroteerde netwerk met simmetriese paaie het dit nie nodig nie en 'n asimmetriese een gewoonlik wel. Elk van die vier misluk onafhanklik, en daarom verskuif die herstel van een selde die simptoom. Skryf al vier neer voordat jy enige van hulle verander.

Wolkplatforms voeg 'n vyfde oorweging by. Sommige handhaaf bron- en bestemmingskontroles op instansies, wat deurgestuurde pakkies laat val ongeag wat die gas se kernel ingestel is om te doen. Die platform se eie netwerkdokumentasie is daar die gesag, nie die sysctl-uitset binne die VM nie.

Toets vanaf die kliënt, nie die grendel nie

'n Toets wat in die grendel se eie dop uitgevoer word, deurkruis niks van die doorstuurpad wat jy pas geaktiveer het nie. Genereer die verkeer vanaf die kliënt met die probleem, en bevestig dat dit iets agter die grendel bereik eerder as die grendel self. Dit is die enigste toets wat die rol uitoefen wat jy verander het.

Hou luisteraarreëls en doorstuur-reëls afsonderlik in jou kop en in die veranderingsrekord. Om die VPN-poort oop te maak, laat kliënte tot die diens toe; dit gee hulle niks op die netwerk daaragter nie, en die twee lyk identies in 'n brandmuurlys wat oor jare gegroei het.

As pakkies aankom en die diens dan die gebruiker verwerp, het jy verby netwerking beweeg. Gaan voort met toepassingmagtiging in plaas daarvan om die doorstuurbeleid weer te verbreed.