Leverer upstream-rutaren verkeleg inngåande VPN-portar?

Tre vilkår avgjer om ei portvideresending på laboratorierutaren publiserer noko: kva oppstraumsranda leverer, kva politikk ho nyttar, og om svar kjem tilbake same veg. Ei adresse som ser offentleg ut svarar på ingen av dei. Det gjer heller ikkje eit /30-prefiks eller ei fungerande utgåande samband. Sorter desse vilkåra før du endrar NAT, elles vil den lokale regelen sjå øydelagd ut medan blokkeringa sit to hopp unna.

Tre svar avgjer kven du eskalerer til

Eigaren av oppstraumsranda kan skildre overleveringa på ein av tre måtar. Destinasjonen blir levert direkte til grensesnittet ditt, eit eige prefiks blir ruta til neste hopp, eller noko framom omset adressa før ho når deg. Kvart svar namngjev ein annan eining som må tillate den inngåande sambandet, og eit anna team som skal ringjast når det ikkje skjer.

Filtrering er den fjerde variabelen og er uavhengig av alle tre. Eit nettverk kan filtrere trafikk som held på den offentlege adressa si, og ein omsetjar er ikkje automatisk policygrensa. Spør om tillatne kjeldeadresser, transport og portar samstundes med leveringa, fordi ein videresend port som randa droppar aldri når regelen din.

Les overleveringa som ein tenestekontrakt

Skriv ned fem verdiar før du tar på laboratorierutaren: den tildelte grensesnittadressa, prefikslengda, neste hopp, destinasjonsadressa eksterne klientar vil bruke, og den nøyaktige protokollen og porten. Destinasjonen er den interessante, fordi ho kanskje ikkje er ei adresse som er konfigurert på eininga di i det heile. Viss oppstraumsranda ventar at klientar når ei omsett adresse, må lokal DNAT samsvare med den kontrakten og ikkje med grensesnittadressa du ser.

IETF-diskuusjonen om brannmuråtferd er ei nyttig påminning om at filtrering og omsetjing er separate funksjonar. Han forklarar kvifor ein ruter kan handheve inngåande politikk utan å skjule adresser, og kvifor NAT ein stad oppstraums ikkje beviser at filtreringa skjer der. Behandle overleveringa som ei tenesteskildring med ein eigar og ein endringsprosess.

Observer eitt forsøk ved begge grensene

Eitt smalt, godkjend forsøk korrelert på to punkt erstattar ein haug med gjettingar. Køyr eit opptak på WAN-grensesnittet til laboratoriet for den nøyaktige tuple, og be eigaren av oppstraumsranda om å observere same tuple ved randa. Hald destinasjon, protokoll, port, kjelde og tidsstempel identiske mellom dei to visingane.

tcpdump -ni wan0 'tcp port 1194 and host 203.0.113.10'

Les paret av resultat som ei avgjerd. Sett ved randa og sett på laboratoriet sin WAN tyder at både levering og randpolitikk passerer, så hald fram med lyttaren eller DNAT. Sett ved randa men ikkje på laboratoriet sin WAN peikar på levering eller ein mellomliggjande politikk, og neste samtale er til eigaren av oppstraumsranda. Ikkje sett nokon stad tyder at test-tuplen, kjelda eller vegen er feil før noko brannmursspørsmål i det heile.

Fråvær av bevis i eitt opptak er ikkje bevis for ein brannmur. Det er eit grenseresultat som fortel deg kva eining du skal undersøkje neste gong.

Ikkje la lokal NAT skjule svaret

Den lokale regelen blir først interessant etter at inngangen er stadfesta. Stadfest at DNAT-målet er den faktiske adressa og porten til VPN-lyttaren, at videresending er slått på for den relevante familien, og at svaret går ut gjennom grensesnittet førespurnaden kom inn på. Ein regel som skriv om destinasjonen men ikkje returvegen, gir same tidsavbrot som ein droppa pakke.

Hald på porttryggleik og produksjonsoverleveringa medan du undersøkjer. Å byte ut rutaren eller forfalske MAC-adressa for å omgå tilkoplingskontrollar byter ein diagnose mot eit avbrot. Ein speglport eller eit godkjend opptak gir same synlegheit utan å kople frå tenester som deler lenkja.

Avslutt med eigarskapskartet: destinasjon, leverande eining, filtrerande eining, inngangen til laboratoriet og lyttar. Det kartet gjer neste gjennomgang av portvideresending liten, og det autentiserer ingenting om sjølve VPN-en.